[AVT] Re: RFC 3952 (iLBC) - default packetization time?

[Randell Jesup <rjesup at wgate.com>]

Alan Duric <alan.duric at telio.no> 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.

>> 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?
>
>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
rjesup at wgate.com
"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)


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