Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3134D1A07AA for ; Thu, 20 Mar 2014 09:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34r6VzkpZFPh for ; Thu, 20 Mar 2014 09:40:18 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3555E1A07A8 for ; Thu, 20 Mar 2014 09:40:18 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so1243548vcb.26 for ; Thu, 20 Mar 2014 09:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CFI7jg6jLy/3RDMIBnDJRJlFEv5/iDDaiak4NBbSZM0=; b=W8VH6R51eCVV4QX1tHjgPD05WixN+Jii9vFNiue8UCFp4ARSK+ffd49ilszE8K0eLT 4xeEwFdOTo9iGEHFKP6V44Azspzo7b7jJvKPtakn+jWNIwRTlS8kmZ/To6NfQc8pCR69 GMLZBJL9Q/E8wrthwdh4vnl2xXVp2BoRGEKjt9kb/KFfgGPa8CuXrqygREiiY/Ts7dWd bPkhpKNicWd/9NoEC64iNzTne0WB6QeqoJi+vQ00tdcR9S5O8y1qF/+X4hGgH4V5pDfw P8h0JhSRMH7bIOHKRmD1M35OC1U3UjpDwF+ugcRRf5txiwfke/nBlNapYfsjmG24wWEF e9VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CFI7jg6jLy/3RDMIBnDJRJlFEv5/iDDaiak4NBbSZM0=; b=J0QCzf3Cm6eoL2s2CoF4JkO4MXaPk7gpFYDF4K3ZcwP2/y8q6FdcqUjjDpQ0L0nCwV rifVcxSCFGzh47BFO1Xh72CJHrsvfQcpUvTEI9b04xlI8VRcFjFyDVB51QxKspSW3Vh3 Si4HqQIlPwRRTiBs49OBJq4Ya7B834ir7+7/QCl5f4Zx/FuqV22kZ53OZ1pA1AOWOLoT GYIGyGyYixeR7BXwPV4ZQkeSncXSZINI5caZjWG3hOS+bR1TYOd6sxr9dUvsUaJeGBNn Pm0gY8sPlQQDmXTU89FLjNEzMdkzu3v0vCz45zHEArMaOQnZ4xDvEXUBSjQVZmzq1rz0 VNkg== X-Gm-Message-State: ALoCoQm1cKwCAPefUo0u+q0nzoXSt4N5y4wyWCriNhHKeUYa+BFZSO/C5J1TCHVx3F3MdHkwvmByvx8QGSU9s9PUqYDwZBaZj8lOOwDTqhFDbF4hk7/r+E9NRNkrHGYYxLR0mSFUKF8auZdjqOq8NOuMfBvr9oZx3Quz22N3Se69lVGhWLT1Ams6hYodzj+XCo+ms2GtzwDO X-Received: by 10.52.8.225 with SMTP id u1mr882798vda.64.1395333608958; Thu, 20 Mar 2014 09:40:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:39:48 -0700 (PDT) In-Reply-To: <532AC890.7000602@ericsson.com> References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> From: Justin Uberti Date: Thu, 20 Mar 2014 09:39:48 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf302d497a1b169504f50c6c87 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cY8AHk7lx9j1n3ksFTm4ONaOSFU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 16:40:20 -0000 --20cf302d497a1b169504f50c6c87 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-20 01:27, Justin Uberti wrote: > > > > > > > > On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund > > > > > 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? --20cf302d497a1b169504f50c6c87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-20 01:27, Justin = Uberti wrote:
>
>
>
> On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund
> <magnus.wes= terlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> wrote:
>
> =C2=A0 =C2=A0 Hi,
>
> =C2=A0 =C2=A0 (As individual)
>
> =C2=A0 =C2=A0 On 2014-03-05 17:26, Justin Uberti wrote:
> =C2=A0 =C2=A0 > From the session this morning, I recall this consen= sus:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > =C2=A0 * We will add recommendations on the frame s= izes to use for
> =C2=A0 =C2=A0 PCMU/A to
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 the rtcweb audio codec I-D (20, 30, 6= 0 ms frames).
>
> =C2=A0 =C2=A0 The above applies to sending payloads
>
>
> Right, thanks for pointing that out.
>
>
> =C2=A0 =C2=A0 Yes, but that was given that a receiver will be capable = of receiving any
> =C2=A0 =C2=A0 valid number of frames, or samples within a reasonable p= acketization,
> =C2=A0 =C2=A0 and I think that should be 120 ms.
>
> =C2=A0 =C2=A0 > =C2=A0 * We will consider adding an a=3Dmaxptime at= tribute that
> =C2=A0 =C2=A0 represents the
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "minimum maxptime" of all t= he offered codecs. That is, if both
> =C2=A0 =C2=A0 Opus
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 (maxptime of 120ms) and PCMU (maxptim= e of 60) are offered, a
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 maxptime=3D60 SHOULD be included.
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 o Since maxptime spans all cod= ecs, this means that some modes
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g. Opus 120ms) will = be unavailable, unless only Opus is
> =C2=A0 =C2=A0 offered.
>
> =C2=A0 =C2=A0 I think you base the assumption on maxptime based on the= sending
> =C2=A0 =C2=A0 recommendations, not what is capable of receiving. If on= e is capable of
> =C2=A0 =C2=A0 receiving 200 ms of a-law and Opus, then you would need = to say 120 ms as
> =C2=A0 =C2=A0 Opus will limit you.
>
>
> I agree that Opus' maxptime is 120, but should that prevent sendin= g PCMU
> with 200 ms? That is, since sending Opus with 200 ms is not legal, is<= br> > 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=3D line scope.

>
>
>
> =C2=A0 =C2=A0 > =C2=A0 * We will consider adding an a=3Dptime attri= bute, set to the
> =C2=A0 =C2=A0 receiver's
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 preferred frame size to receive. Agai= n, this value spans all
> =C2=A0 =C2=A0 codecs,
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 so the specified value may not be via= ble for all codecs (e.g.
> =C2=A0 =C2=A0 30 ms
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 works for PCMU but not for Opus)
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > After thinking about this some, I'm not sure th= e maxptime/ptime values
> =C2=A0 =C2=A0 > will lead to any different behavior than if they we= re not specified.
> =C2=A0 =C2=A0 > Since there is a complexity cost (especially if the= values need to
> =C2=A0 =C2=A0 > change based on which codecs are offered), is there= a clear upside
> =C2=A0 =C2=A0 here?
>
> =C2=A0 =C2=A0 The maxptime values may in some cases be limited downwar= ds for
> =C2=A0 =C2=A0 interoperability, for example if one like to gateway AMR= into a CS
> =C2=A0 =C2=A0 network then the gateway might indicate a maxptime that = is less, more
> =C2=A0 =C2=A0 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 wha= t
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.

<= br>
Just to be sure I understand, your position is that WebRTC im= pls SHOULD include an a=3Dmaxptime attribute indicating the "minimum m= aximum" frame size they can receive, across all codecs?

Do you think anything needs to be included regarding a= =3Dptime?
--20cf302d497a1b169504f50c6c87--