Subject: [rtcweb] On ptimes and maxptimes

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 16:26:56 +0000

>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).
   - 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.
      - Since maxptime spans all codecs, this means that some modes (e.g.
      Opus 120ms) will be unavailable, unless only Opus is offered.
   - 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?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 16:57:56 +0100

Hi,

(As individual)

On 2014-03-05 17:26, Justin Uberti wrote:
>   * We will add recommendations on the frame sizes to use for PCMU/A to

The above applies to sending payloads

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

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

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

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 17:27:29 -0700

> The above applies to sending payloads

Right, thanks for pointing that out.

> receiving 200 ms of a-law and Opus, then you would need to say 120 ms as

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?

> network then the gateway might indicate a maxptime that is less, more

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

Yes.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2014 11:53:04 +0100

On 2014-03-20 01:27, Justin Uberti wrote:
> 
> 
> 
> On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
>     (As individual)
> 
> 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.

> 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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 09:39:48 -0700

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Mar 2014 09:19:00 +0100

On 2014-03-20 17:39, Justin Uberti wrote:
> 
> 
> 
> On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund
>     > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     > wrote:
>     >
>     >     Hi,
>     >
>     >     (As individual)
>     >
>     >     >     "minimum maxptime" of all the offered codecs. That is,
>     if both
>     >     Opus
>     >     >         (e.g. Opus 120ms) will be unavailable, unless only
>     Opus is
>     >     offered.
>     >
>     >     >     so the specified value may not be viable for all codecs
>     (e.g.
>     >     30 ms
>     >     > change based on which codecs are offered), is there a clear
>     upside
>     >     here?
>     >
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Mar 2014 12:39:23 -0600

> payload types for that m= section, then one should skip it.

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.

---

From: Randell Jesup <[email-masked]>
Date: Sun, 23 Mar 2014 02:12:23 -0400

On 3/22/2014 2:39 PM, Cullen Jennings wrote:
> 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.

maxptime - yes, MUST
ptime - since it's merely a preference, it's not a MUST understand.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Mar 2014 15:19:27 +0100

> ptime - since it's merely a preference, it's not a MUST understand.

Yes, but I think it SHOULD be understood and followed.

Cheers

Magnus Westerlund