Meeting in Atlanta

A reminder that the cutoff for internet-drafts is 9:00am EST (GMT -05:00)
on Monday. Those wanting agenda time should contact the working group
chairs; submitting a draft does not automatically provide agenda time. 

Colin

>------- Forwarded Message
>>The AVT working group is scheduled for two slots at the 55th IETF meeting
>>in Atlanta. On the tentative agenda, these are 9:00 to 11:30am on Tuesday
>>19th November, and 1:00 to 3:00pm on Wednesday 20th November. These dates
>>are subject to change - do not use them to plan travel.
>>
>>Those wanting agenda time at the meeting should contact the working group
>>chairs by 4th November. Submitting a draft does not automatically provide
>>agenda time. 
>>
>>You are reminded that the cut-off date for -00 Internet Draft submissions
>>is Monday, 28th October at 9:00am EST (GMT -05:00). Unless you have prior
>>approval from the chairs, -00 submissions should have filenames with the
>>format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts
>>received after 28th October will not be accepted. 
>>
>>All other Internet-Draft submissions must be made by Monday, 4th November
>>at 9:00am EST.
>>
>>Drafts which are submitted late and do not make the cutoff date will not be
>>discussed at the meeting.
>>
>>Colin
>------- End of Forwarded Message

Re: RFC 2833 SDP Parameters

It's just another audio payload type, so any SDP parameters apply. 
However, it's not quite clear how useful this is. This would limit "The 
maximum amount of media which can be encapsulated in each
     packet, expressed as time in milliseconds." Given that packets 
represent the whole event, this would, read literally, restrict the 
duration of events.

Lubbs, Stephen wrote:

> Hi Folks,
> Another quick question, if you don't mind. Is it permissible to use SDP
> parameters that are not listed in RFC 2833 when describing the payload?
> Specifically, I'm interested in using maxptime in conjunction with RFC
> 2833 named events to limit the packet interval that will be received.
>
> Regards,
> Steve Lubbs
>

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

FW: draft-ietf-avt-rtp-jpeg2000-02.txt

Greetings,

Attached is the latest JP2/RTP Internet-Draft.  We believe we have addressed
the comments from the last meeting.

Please refer to section 1.2 for details on additions/changes and the
disposition of comments on the previous draft.

Any comments will be welcome via the reflector.  After addressing any
editorial comments we would like to go to Last-Call.

Best regards,

Eric

INTERNET-DRAFT                                               Eric Edwards
draft-ietf-avt-rtp-jpeg2000-02.txt		          Satoshi Futemma
                                                         Eisaburo Itakura
							 Nobuyoshi Tomita
							     Andrew Leung
                                                        Takahiro Fukuhara
                                                         Sony Corporation
                                                         November 4, 2002
                                                      Expires: May 3 2003

              RTP Payload Format for JPEG 2000 Video Streams

Status of this Memo

Comments on draft-ietf-avt-rtp-h264-00.txt

Hi Stephan,

I have some comments on the draft:

1. I can't quite understand how the STAP and MTAP are going to be used. 
How are the fields arranged? It could also be clearer that STAP and MTAP 
are NALU headers them self with some fields of there own. My can guess 
of how STAP packet would look like:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NSI|STAP=0x18| 16 bit length field of NALU #1| NAL Header #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAL Data ...                                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | 16-bit Length Field NALU #2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NAL Header 2   | NAL DATA ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then it looks similar for MTAP with the only difference that each NAL 
would be prefixed with a offset field equal in size to the MTAP used. 
This would make it look like:

Draft agenda for Atlanta

Folks,

The internet-draft submission deadline has now passed. Our draft agenda
is as follows:

Tuesday, 19 November at 09:00-11:30
===================================

Introduction and status update                          (Casner/Perkins)
        draft-kreuter-avt-rtp-clearmode-00.txt 

The MIDI Wire Protocol Packetization (MWPP)             (Perkins)
        draft-ietf-avt-mwpp-midi-rtp-05.txt
        draft-lazzaro-avt-mwpp-coding-guidelines-00.txt

RTP Payload for DTMF Digits, Tones and Signals          (Schulzrinne)   
        draft-ietf-avt-rfc2833bis-01.txt

RTP Payload Format for iLBC                             (Duric)  
        draft-ietf-avt-rtp-ilbc-00.txt
        draft-ietf-avt-ilbc-codec-00.txt

RTP Payload Format for ATRAC-X                          (Romaine)
        draft-hatanaka-avt-rtp-atracx-00.txt

Wednesday, 20 November at 13:00-15:00
=====================================

MIME Type Registration for MPEG-4                       (Lim)
        draft-lim-mpeg4-mime-01.txt     

Re: 2833bis

>
>     "Since all implementations MUST be able to receive events 0 through
>    15, listing these events in the a=fmtp line is OPTIONAL.
>
> There was some discussion about how appropriate this really was, and I 
> believe
> it was generally agreed, that mandating that all implementations of 
> RFC 2833
> support DTMF was not the right thing to do. For example, if I only want to
> convey V.25/V.8 ANS and ANSam, then why not ? Thus, the following 
> implementation
> note was added at http://www.cs.columbia.edu/~hgs/rtp/payload_audio.html:
>
>     "Implementations can support events 0 through 15 (DTMF) by simply 
> ignoring
> the packets, but MUST declare all event numbers that are meaningful to 
> it in the
> fmtp parameter, including 0 through 15."
>
> Taking a look at Section 3.9 in 2833bis, I see the offending text is 
> no longer
> there. If it doesn't say anything else about mandatory and implied 
> DTMF support
> anywhere else, then I'm happy.

If somebody finds a reference to something suggesting that this be 
mandatory, let me know. I don't know if this is a problem, but since 
listing 0-15 was OPTIONAL in 2833, we could stipulate that fmtp is 
mandatory now. In the spirit of limiting options and being explicit 

Re: RFC 2833 questions: Intervals, durations, and lost pack ets.

Lubbs, Stephen wrote:

> Hi Henning,
> Thanks for the answers. The latest draft has addressed some of my 
> question.
>
> Looking at the latest 2833bis draft, the statements I thought were 
> some what
> contradictory were the 2nd and third sentences of section 3.2:
>
> "In the first approach, it sends events and encoded audio packets (e.g.,
> PCMU) for the same time instant. In that mode, events are treated as
> redundant encodings for the encoded audio stream."
>
> And the next to the last sentence of section 3.2:
>
> "It is RECOMMENDED that gateways only render the encoded tone since the
> audio may contain spurious tones introduced by the audio compression
> algorithm. "
>
> The first example seems to imply that when both events and audio are
> available the audio should take precedence. The second example seems to
> indicate that when both are present the event should take precedence. 
> Hence
> my confusion.

I'm not sure that the notion of 'precedence' makes a lot of sense in 
practice. For entering a calling card code, a receiver would likely use 
the named events; for just relaying, a system might use the audio unless 

Re: Suggested changes to RFC 2833 re: fax/modem tones

> *Change #1: I have changed the definition of the volume field in Section
> 3.5. You has rightly added Volume? columns to the event tables. However,
> the text in Section 3.5 was wrong in that it said volume was pertinent
> to DTMF only. Volume is important for modem and fax events, and some
> other categories of events. The new text is as follows:
>
> *volume: For DTMF digits and other events representable as tones,
>              this field describes the power level of the tone, expressed
>              in dBm0 after dropping the sign. Power levels range from 0
>              to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0
>              (must accept); lower than -55 dBm0 must be rejected (TR-
>              TSY-000181, ITU-T Q.24A). Thus, larger values denote lower
>              volume. If this field is not defined for an event,
>
>      it is set to zero by the sender and is
>
>              ignored by the receiver. If a zero volume is indicated for
>                  an event for which the volume field is defined, then
> the receiver
>
>      may reconstruct the volume from interpolation. This allows
>      backwards compatibility with RFC 2833, where the volume field
>     was specified as undefined for non-DTMF events.

I have ad(o|a)pted these changes. Since interpolation didn't seem clear, 
it now says that this refers to surrounding non-event audio. Also, the 
text allows the receiver to pick a default value. I believe that the ITU 
specs for all standardized tones specify such a nominal value. Requiring 
interpolation seems asking a bit much and is probably prone to error.

Re: Suggested changes to RFC 2833 re: fax/modem tones

I've incorporated your text on ANS and related tones, with minor tweaks. 
Since I missed the -0x cut-off, a revised version of the I-D won't 
appear until after IETF55, but

http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-02.txt
http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-02.pdf

has a preview.

> These definitions of the ANS, /ANS, ANSam and /ANSam tones refer to the
> entire signal. Unlike ITU Recommendation V.25 [8], they do not refer to
> individual 450 ms cycles.
>
> An ANS or ANSam event packet should not be sent until it is possible to
> discriminate between an ANS and ANSam event. It is however, permissible
> to send an ANS or ANSam event packet before phase reversals can be
> detected. Phase reversals, if any, occur at intervals of 450 +/- 25 ms.
> If a phase reversal is detected after an ANS or ANSam event packet is
> sent, it must be followed by the transmission of an /ANS or /ANSam event
> packet.
>
> *Change #3: I have added a new ANS event, ANS2225. I have done so per an
> action item from ITU SG16 to request you for this event. This event is
> used in equipment for the disabled and it must not be confused with the
> other ANS events. Of course, a new number needs to be allocated to this
> event. I have not done that. The new event is defined as follows:
>
> *        ANS2225: This  2225 Hz answer tone is described in ITU
> Recommendation
>

Re: Draft agenda for Atlanta

> Colin Perkins <csp <at> csperkins.org> writes:
>
> The MIDI Wire Protocol Packetization (MWPP)             (Perkins)
>         draft-ietf-avt-mwpp-midi-rtp-05.txt
>         draft-lazzaro-avt-mwpp-coding-guidelines-00.txt

Yes, draft-ietf-avt-mwpp-midi-rtp-05.txt will be the version
for Atlanta, I was hoping to submit an -06.txt, but the 
version that was ready on Sunday had too few changes from 
-05.txt to be worthy of a new release.

> RTP Payload Format for ATRAC-X                          (Romaine)
>         draft-hatanaka-avt-rtp-atracx-00.txt

This announcement didn't seem to make it onto AVT,
I had one question for the authors -- is the codec
specification for ATRAC-X publically available? The
I-D mentions an ATRAC-X specification, but does not
reference that mention with a document, so I couldn't
tell ... 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt