Re: [rtcweb] On ptimes and maxptimes

Cullen Jennings <fluffy@iii.ca> Sun, 23 March 2014 01:39 UTC

Return-Path: <fluffy@iii.ca>
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 2F9711A092A for <rtcweb@ietfa.amsl.com>; Sat, 22 Mar 2014 18:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.842
X-Spam-Level: **
X-Spam-Status: No, score=2.842 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 5sfbww2YM1ox for <rtcweb@ietfa.amsl.com>; Sat, 22 Mar 2014 18:39:35 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB321A0762 for <rtcweb@ietf.org>; Sat, 22 Mar 2014 18:39:35 -0700 (PDT)
Received: from [10.21.74.45] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8EDFC22E255; Sat, 22 Mar 2014 21:39:31 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <532BF5F4.90901@ericsson.com>
Date: Sat, 22 Mar 2014 12:39:23 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ED6AAC7-5D6F-48C1-BCAE-EA161C6BC0CF@iii.ca>
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> <CAOJ7v-2=p8LBjVK289usieiDFsmf6m3N8rYMNpBFPhDzdb_61Q@mail.gmail.com> <532BF5F4.90901@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BHkqb3_gYAKq53kACyGL0fDin84
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: Sun, 23 Mar 2014 01:39:37 -0000

On Mar 21, 2014, at 2:19 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

> On 2014-03-20 17:39, Justin Uberti wrote:
>> 
>> 
>> 
>> On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund
>> <magnus.westerlund@ericsson.com <mailto: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>
>>    <mailto: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?
> 
> Yes, as long as we lack payload type specific, I think that is the best
> we can do.
>> 
>> Do you think anything needs to be included regarding a=ptime?
> 
> I think it MAY be included to indicate an initial preference for
> packetization interval. In cases that is not common across the set of
> payload types for that m= section, then one should skip it.
> 
> Cheers
> 
> Magnus Westerlund


It seems like from interoperability point of view, we also need,  if a browser receives a maxptime or prime, it MUST be able to understand that.