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?