Re: [rtcweb] On ptimes and maxptimes

[Magnus Westerlund <[e-mail]>]

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

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