Re: [rtcweb] On ptimes and maxptimes
Justin Uberti <juberti@google.com> Thu, 20 March 2014 16:40 UTC
Return-Path: <juberti@google.com>
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 <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietf.org>; Thu, 20 Mar 2014 09:40:18 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id id10so1243548vcb.26 for <rtcweb@ietf.org>; 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: <CAOJ7v-1e+FXQZrvh8Q549kwyhf8JX2BA_0q=+6mjha9+o-Dgpw@mail.gmail.com> <531DE104.2010908@ericsson.com> <CAOJ7v-31-xHGq1ERYYx5mvZuqTor0Seod_ChNT2AhY2BLaJi-Q@mail.gmail.com> <532AC890.7000602@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 20 Mar 2014 09:39:48 -0700
Message-ID: <CAOJ7v-2=p8LBjVK289usieiDFsmf6m3N8rYMNpBFPhDzdb_61Q@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="20cf302d497a1b169504f50c6c87"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cY8AHk7lx9j1n3ksFTm4ONaOSFU
Cc: "rtcweb@ietf.org" <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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 16:40:20 -0000
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 > > <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> > > 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?
- [rtcweb] On ptimes and maxptimes Justin Uberti
- Re: [rtcweb] On ptimes and maxptimes Magnus Westerlund
- Re: [rtcweb] On ptimes and maxptimes Justin Uberti
- Re: [rtcweb] On ptimes and maxptimes Magnus Westerlund
- Re: [rtcweb] On ptimes and maxptimes Justin Uberti
- Re: [rtcweb] On ptimes and maxptimes Magnus Westerlund
- Re: [rtcweb] On ptimes and maxptimes Cullen Jennings
- Re: [rtcweb] On ptimes and maxptimes Randell Jesup
- Re: [rtcweb] On ptimes and maxptimes Magnus Westerlund