Re: [rtcweb] On ptimes and maxptimes

[Justin Uberti <[e-mail]>]

On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund <
[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]>>
> > 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?

Do you think anything needs to be included regarding a=ptime?