Re: [rtcweb] On ptimes and maxptimes

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 10 March 2014 15:58 UTC

Return-Path: <magnus.westerlund@ericsson.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 685FF1A04A7 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 Yjc3YfZ3kXk1 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:58:04 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 900FB1A0265 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 08:58:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-74-531de10519a4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.82.23809.501ED135; Mon, 10 Mar 2014 16:57:57 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:57:57 +0100
Message-ID: <531DE104.2010908@ericsson.com>
Date: Mon, 10 Mar 2014 16:57:56 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CAOJ7v-1e+FXQZrvh8Q549kwyhf8JX2BA_0q=+6mjha9+o-Dgpw@mail.gmail.com>
In-Reply-To: <CAOJ7v-1e+FXQZrvh8Q549kwyhf8JX2BA_0q=+6mjha9+o-Dgpw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Rpf1oWywwbT9ehZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgy9vTuZys4JFyx6dEqxgbG5fxdjJwcEgImEkf7 t7NC2GISF+6tZ+ti5OIQEjjEKLGl7QsLhLOcUWLRlV/sIFW8AtoSy8+uAbNZBFQlzp1sYwax 2QQsJG7+aGQDsUUFgiV2HvjNCFEvKHFy5hMWEFtEwFui5f0EsLiwgK7EuuV7mLoYOYAWBEis 2xEBEuYUCJS403iNBSQsISAu0dMYBBJmFtCTmHK1hRHClpdo3jobbKsQ0DUNTR2sExgFZyFZ NgtJyywkLQsYmVcxsucmZuaklxttYgQG48Etv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjMn9jtrXnUWZNYw5osKY5ONzvGXT2lkdJGJFTL8kMrrtrJ6c Vl2soqZva3pKpuTDIXbTE89fGGVNm5L96NMRW167KqMzDcx2hjlz7uwx85b6sjH74oU4Bs6o H8s0ec70e/MYKBntPnE68LuGfcextbNZuKof8Oku+/5izoW27wvunha79vShEktxRqKhFnNR cSIAdPftTRQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_My-UyVdBHxKeb4cidwzVzWse7Y
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: Mon, 10 Mar 2014 15:58:05 -0000

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

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.

>   * 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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------