Re: [rtcweb] On ptimes and maxptimes

[Cullen Jennings <[e-mail]>]

On Mar 21, 2014, at 2:19 AM, Magnus Westerlund <[e-mail]> wrote:

> On 2014-03-20 17:39, Justin Uberti wrote:
>> 
>> 
>> 
>> On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>> 
>>    On 2014-03-20 01:27, Justin Uberti wrote:
>>> 
>>> 
>>> 
>>> On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund
>>> <[e-mail]
>>    <mailto:[e-mail]>
>>    <mailto:[e-mail]
>>    <mailto:[e-mail]>>>
>>> wrote:
>>> 
>>>    Hi,
>>> 
>>>    (As individual)
>>> 
>>>    On 2014-03-05 17:26, Justin Uberti wrote:
>>>> From the session this morning, I recall this consensus:
>>>> 
>>>>  * We will add recommendations on the frame sizes to use for
>>>    PCMU/A to
>>>>    the rtcweb audio codec I-D (20, 30, 60 ms frames).
>>> 
>>>    The above applies to sending payloads
>>> 
>>> 
>>> Right, thanks for pointing that out.
>>> 
>>> 
>>>    Yes, but that was given that a receiver will be capable of
>>    receiving any
>>>    valid number of frames, or samples within a reasonable
>>    packetization,
>>>    and I think that should be 120 ms.
>>> 
>>>>  * We will consider adding an a=maxptime attribute that
>>>    represents the
>>>>    "minimum maxptime" of all the offered codecs. That is,
>>    if both
>>>    Opus
>>>>    (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a
>>>>    maxptime=60 SHOULD be included.
>>>>      o Since maxptime spans all codecs, this means that
>>    some modes
>>>>        (e.g. Opus 120ms) will be unavailable, unless only
>>    Opus is
>>>    offered.
>>> 
>>>    I think you base the assumption on maxptime based on the sending
>>>    recommendations, not what is capable of receiving. If one is
>>    capable of
>>>    receiving 200 ms of a-law and Opus, then you would need to say
>>    120 ms as
>>>    Opus will limit you.
>>> 
>>> 
>>> I agree that Opus' maxptime is 120, but should that prevent
>>    sending PCMU
>>> with 200 ms? That is, since sending Opus with 200 ms is not legal, is
>>> there any point in forcing WebRTC impls to indicate this in SDP?
>> 
>>    What I wished we fixed this issue with maxptime a long time ago. This is
>>    a well known problem that it really has PT scope, but are signalled on
>>    m= line scope.
>> 
>>> 
>>> 
>>> 
>>>>  * We will consider adding an a=ptime attribute, set to the
>>>    receiver's
>>>>    preferred frame size to receive. Again, this value spans all
>>>    codecs,
>>>>    so the specified value may not be viable for all codecs
>>    (e.g.
>>>    30 ms
>>>>    works for PCMU but not for Opus)
>>>> 
>>>> After thinking about this some, I'm not sure the
>>    maxptime/ptime values
>>>> will lead to any different behavior than if they were not
>>    specified.
>>>> Since there is a complexity cost (especially if the values
>>    need to
>>>> change based on which codecs are offered), is there a clear
>>    upside
>>>    here?
>>> 
>>>    The maxptime values may in some cases be limited downwards for
>>>    interoperability, for example if one like to gateway AMR into a CS
>>>    network then the gateway might indicate a maxptime that is
>>    less, more
>>>    like 20 or 40 ms.
>>> 
>>> 
>>> Sure - WebRTC impls need to respect any maxptime value that they
>>> receive, but it's not clear to me that they need to include one in the
>>> SDP they send.
>> 
>>    Ok, but then we are back to my previous argument for writing down what
>>    receiver requirement in regards to each payload type one is required to
>>    support in the audio draft for the ones specified there. But what about
>>    the other codecs that aren't included in the audio draft?
>> 
>>    How can a peer know if there are limitations? I wouldn't attempt to
>>    solve the general problem of the scope issue with maxptime. Simply state
>>    that you should include this. It is going to be limited but still
>>    provide information in many cases that is quite useful for the sender.
>> 
>> 
>> Just to be sure I understand, your position is that WebRTC impls SHOULD
>> include an a=maxptime attribute indicating the "minimum maximum" frame
>> size they can receive, across all codecs?
> 
> Yes, as long as we lack payload type specific, I think that is the best
> we can do.
>> 
>> Do you think anything needs to be included regarding a=ptime?
> 
> I think it MAY be included to indicate an initial preference for
> packetization interval. In cases that is not common across the set of
> payload types for that m= section, then one should skip it.
> 
> Cheers
> 
> Magnus Westerlund


It seems like from interoperability point of view, we also need,  if a browser receives a maxptime or prime, it MUST be able to understand that.