Re: [rtcweb] On ptimes and maxptimes

Justin Uberti <juberti@google.com> Thu, 20 March 2014 00:27 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 DFAE21A0853 for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 17:27:59 -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 C7pAj-s7z7u2 for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 17:27:58 -0700 (PDT)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 613261A0447 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 17:27:58 -0700 (PDT)
Received: by mail-ve0-f182.google.com with SMTP id jw12so108448veb.41 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 17:27:49 -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=i3QNX0wiis3BIA8B7dueLTY829JMMl8M0kC1OuffWF8=; b=KB2wQboCwGdTQP3jWzDBlZ8Wq771OyjcR+2i5KYJNTYlHD6iDVKmQG8OosnWV+O8G9 gDLGIvB9tlXVU9dDL2xzyNugoZ2CAQYZ7L32pVz9MStOT2WMTxbA5J55zKLyYrqv3Yrh VOfOy5JgqjN0AsG1wtDsHUpmxXAYcdZpTlFliYV7Lf9u3Gu4Aipi6Za98DxvrA+R16YU 0iMYpwz3jCInS+9A4TUOMYpIi2aBV94+CwXgIvcnMKXjxeiX7VoXysYNJ4aF7zLqFWIW GFf+JZp8mphPpLOIZe5YM1r718yHdm7Xa2aB3eq7wVIi95lTe3aDnNfaZyKOFiillDtd nThA==
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=i3QNX0wiis3BIA8B7dueLTY829JMMl8M0kC1OuffWF8=; b=GGthWh9hdhh7ZpWDoaL2bYtzMhUG5qQq/dN09l2SjI92KFgkCuDWPmpuf+Z7aOpEL3 rtmgv2jg+ekL2cy7mYbP9azWNQNj0hg9eOQPvbIsixB7IGNrJ4OawT0d29iflgJ+tbx7 AeAO+k3ImTofjrw9MTat7IWpgsHl17W4EQN3ObMonzKTpLnDityiX+ifc1OylQBCSqjr hDnSU3myr3ctry6vcEY9NJ3ocV9CDa9g4jfs9KFUzjnlJh2JD3pQeB+WB/dFnzPSaIH5 CucMrndY2a2XwZhSrE076Js1KT4HzxE3wVcUkaWf8vkGMZCQ8m6ayO34BQWFjKTWd4go TZjg==
X-Gm-Message-State: ALoCoQkpImajmz1qefZyqyGkfeNPutiGpJDhKidE9I/b2YbYTiC2x6FUeYEYHTht6pfpcyIZF42fDXftzoMulnggYRBEzshoNZ4vXabh02dIHuy+ipoDqoGmBjASwsig6wxU52/Tom5NMunH3YY0U5udSw2aPV0PoDvXjbImTVh6t+7P4cFmLrKJJLxEKuT3vPKA9X7tq+nW
X-Received: by 10.221.37.1 with SMTP id tc1mr2324943vcb.32.1395275269434; Wed, 19 Mar 2014 17:27:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 17:27:29 -0700 (PDT)
In-Reply-To: <531DE104.2010908@ericsson.com>
References: <CAOJ7v-1e+FXQZrvh8Q549kwyhf8JX2BA_0q=+6mjha9+o-Dgpw@mail.gmail.com> <531DE104.2010908@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Mar 2014 17:27:29 -0700
Message-ID: <CAOJ7v-31-xHGq1ERYYx5mvZuqTor0Seod_ChNT2AhY2BLaJi-Q@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11334c38cc8e4004f4fed6d4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/80nK9T7szYkeUL99iRUPYQBBPao
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 00:28:00 -0000

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


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

>
>