Re: [rtcweb] On ptimes and maxptimes

[Magnus Westerlund <[e-mail]>]

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]>>
> 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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------