Subject: [AVT] Test - please ignore

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2005 12:33:42 -0600

There were problems with the mailing list archive - this message is to 
test that they have been resolved.
Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: 09 Mar 2005 16:39:41 -0500

RFC 3952 (RTP format for iLBC) is somewhat vague on what the default
packetization period used is (20 or 30ms).  There are sentences that imply
it's 30ms, but it is not stated.  Also, it's never stated what mode is
selected if the offer says mode=20 and the answer doesn't specify a mode
(or vice versa).

>From the RFC (somewhat unclearly worded):

   If 20 ms frame size mode is used, remote iLBC encoder SHALL receive
   "mode" parameter in the SDP "a=fmtp" attribute by copying them
   directly from the MIME media type string as a semicolon separated
   with parameter=value, where parameter is "mode", and values can be 0
   and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame
   size).  An example of the media representation in SDP for describing
   iLBC when 20 ms frame size mode is used might be:

      m=audio 49120 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      a=fmtp:97 mode=20

This implies that the default is 30ms but doesn't state it.  (The rest
of the RFC is agnostic either way.)

   It is important to emphasize the bi-directional character of the
   "mode" parameter - both sides of a bi-directional session MUST use
   the same "mode" value.

   The offer contains the preferred mode of the offerer.  The answerer
   may agree to that mode by including the same mode in the answer, or
   may include a different mode.  The resulting mode used by both
   parties SHALL be the lower of the bandwidth modes in the offer and
   answer.

   That is, an offer of "mode=20" receiving an answer of "mode=30" will
   result in "mode=30" being used by both participants.  Similarly, an
   offer of "mode=30" and an answer of "mode=20" will result in
   "mode=30" being used by both participants.

What if there is no mode in the response?  What if there is no mode in the
request?  What if there is no mode in either?

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: 09 Mar 2005 21:12:40 -0500

Alan Duric <[email-masked]> writes:
>see answers inline (if anything more needed or left unclear let me know).
>Sorry for the confusion. Descriptions in the RFC most of the other
>implementors  found  straight forward.

        Thanks.  As I said, it's implied by the spec, but it never comes
out and says "30ms is the default", and it never says "lack of a mode line
means 30ms".  The first paragraph I quoted is particularly awkwardly
worded, leading to potential confusion as to what was meant.

        Also, the RFC says that the answerer can agree by including the mode, or
put a different mode in.  This _might_ be interpreted as a response without
a mode line (to an offer with a mode line) is invalid, though that wasn't
what was meant.

        Thanks for the confirmation.

>> What if there is no mode in the response?
>
>Then only 30 ms mode is supported on the far end (it is MUST to use "mode"
>in order to have 20 ms frames in the established call, if someone does not
>use it, it implies it does not support it) and thus 30 ms will be selected.
>
>>   What if there is no mode in the
>> request?
>
>That means that originating side does not support 20 ms mode, thus 30 ms
>mode will be selected.
>>
>
>> What if there is no mode in either?
>
>Same as previous answer.
>
>Best regards,
>Alan
>
>
>>

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Alan Duric <[email-masked]>
Date: Thu, 10 Mar 2005 02:06:29 +0100

Hey Randell,

see answers inline (if anything more needed or left unclear let me 
know).
Sorry for the confusion. Descriptions in the RFC most of the other 
implementors  found  straight forward.

> What if there is no mode in the response?

Then only 30 ms mode is supported on the far end (it is MUST to use 
"mode" in order to have 20 ms frames in the established call, if 
someone does not use it, it implies it does not support it) and thus 30 
ms will be selected.

>   What if there is no mode in the

That means that originating side does not support 20 ms mode, thus 30 
ms mode will be selected.

Same as previous answer.

Best regards,
Alan

---

From: Randell Jesup <[email-masked]>
Date: 10 Mar 2005 15:16:36 -0500

>see answers inline (if anything more needed or left unclear let me know).

        Thinking about it, there's another issue with the a=fmtp:NN mode=YY
stuff to watch out for in implementation within SIP:

1) SIP INVITE:
   ...
   m=audio 12345/1 RTP/AVP 97
   a=rtpmap:97 iLBC/8000
   a=ftmp:97 mode=20

2) SIP 200 OK:
   ...
   m=audio 54321/1 RTP/AVP 97
   a=rtpmap:97 iLBC/8000
   a=ftmp:97 mode=30

Ok, by the spec bidirectionally both sides should use 30ms.  Fine.

However, also according the SIP the caller needs to be able and ready to
receive audio on 12345 as soon as they send the invite (assuming the stream
isn't inactive).  The 200 OK can be delayed or lost and considerable
traffic exchanged before then.

So, how is the initiator supposed to know what packetization to assume on
reception?  I assume the initiator must be prepared to receive and play
either and if need be "sniff" the data within the packets to determine if
they're 20ms or 30ms.  The initiator won't send data until it sees 200 OK
(of course).  The initiator can't use the size alone since an RTP packet
might contain 2 frames of 30ms or 3 of 20ms.  Or the initiator could
ignore incoming packets until it sees an OK (which of course is non-optimal).

This is the sort of thing it would be good to warn implementors about.

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 10 Mar 2005 21:54:38 +0100

In SDP, the endpoint describes its receive capabilities/requirements, 
so if the INVITE contains a=ftmp:97 mode=30, it is telling the remote 
end that it will accept frames of 30ms.

Regards,
Hisham

On Mar 10, 2005, at 9:16 PM, Randell Jesup wrote:

>> "mode"

---

From: Randell Jesup <[email-masked]>
Date: 10 Mar 2005 20:20:10 -0500

Hisham Khartabil <[email-masked]> writes:
>In SDP, the endpoint describes its receive capabilities/requirements, so if
>the INVITE contains a=ftmp:97 mode=30, it is telling the remote end that it
>will accept frames of 30ms.

        Yes.  But RFC 3952 says that the handling of mode=NN is
bidirectional - if either says mode=30, then they use mode=30.  That's
fine for sending (and you can't send until you see the response).  But
for receiving, I was noting that even though the invite says mode=20,
you must be ready to receive 30ms audio without having seen the response.

        It's not a bug per se, just a "watch out, this may not be obvious"
item.  Many implementations may not care if the data is 20ms or 30ms;
the codec would handle that, but it's possible jitter buffers or
error concealment code might.

>>         Thinking about it, there's another issue with the a=fmtp:NN
>> mode=YY stuff to watch out for in implementation within SIP:
>>
>> 1) SIP INVITE:
>>    ...