Re: [rtcweb] On ptimes and maxptimes

[Justin Uberti <[e-mail]>]

On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund <
[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?


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

>
> Please remember that these rules do apply to any codec, not only the MTI
> ones.
>

Yes.

>
>