Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05)

Harald Alvestrand <harald@alvestrand.no> Sat, 01 March 2014 16:47 UTC

Return-Path: <harald@alvestrand.no>
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 C95591A0214 for <rtcweb@ietfa.amsl.com>; Sat, 1 Mar 2014 08:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Level:
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 EirWpUm_fnQW for <rtcweb@ietfa.amsl.com>; Sat, 1 Mar 2014 08:47:14 -0800 (PST)
Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 823C01A00A6 for <rtcweb@ietf.org>; Sat, 1 Mar 2014 08:47:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id AB06D7C4E75; Sat, 1 Mar 2014 17:47:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvKJXpsRa7-J; Sat, 1 Mar 2014 17:47:10 +0100 (CET)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id E63A87C4E2C; Sat, 1 Mar 2014 17:47:10 +0100 (CET)
Message-ID: <53120F0E.4020703@alvestrand.no>
Date: Sat, 01 Mar 2014 17:47:10 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> <5304F3E0.1020206@alvestrand.no> <530C6F3C.1090709@ericsson.com>
In-Reply-To: <530C6F3C.1090709@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I3O9-fonilpkpr-hXKITiD9Up2E
Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05)
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: Sat, 01 Mar 2014 16:47:17 -0000

On 02/25/2014 11:23 AM, Magnus Westerlund wrote:
> On 2014-02-19 19:11, Harald Alvestrand wrote:
>> On 02/19/2014 09:16 AM, Magnus Westerlund wrote:
>>> On 2014-02-18 23:58, Harald Alvestrand wrote:
>>>> I may be a little simple-minded, but if we have a recommendation that
>>>> receivers MUST be able to receive all packetizations of G.711 and OPUS
>>>> up to 200 ms per packet, and that receivers should signal this by
>>>> sending "a=maxptime:200" in their SDP, what situations exist where
>>>> interoperability is not going to be achieved?
>>> Interoperability is going to be achieve in the direction towards this
>>> endpoint. The question is if we achieve interoperability in the
>>> direction from that endpoint.
>> So, given that there is nothing in the G.711 specification about which
>> sample sizes a G.711 receiver has to support - the right approach seems
>> to be to amend the G.711 MIME registration with this information.
> Yes, it would for the future. But considering the wide-spread deployment
> of this payload format I don't see that having any short term effect on
> the interoperability.
>
> Also, the recommendations are actually context dependent. Thus, it is
> not obvious that a single recommendation is suitable.
>
>> This is not a WebRTC issue; it is an absence of specification for the
>> non-WebRTC devices that use G.711. The RTCWEB specifications can
>> reasonably be expected to point to existing information about this
>> issue; it is not reasonable (in my mind) that the RTCWEB WG decide what
>> these values should be.
>>
> I would argue for this consideration based on that this is done in the
> WebRTC context, not any other context.

For which value of "this" is that true?

All other contexts that use G.711 send packets with a certain ptime 
(which determines the number of samples per packet).

It seems that all other contexts have managed to survive without a 
specification of which ptime it makes sense to send, except for an upper 
bound (maxptime).

When this situation occurs, usually one of two things is happening:

- There's an agreement not captured in the standard, which all 
participants follow.
- The choice doesn't matter for interoperability.

If the second is the case, I think the RTCWEB specification needs to say 
nothing.
If the first is the case, the agreement not captured in the standard 
needs to be captured in a standard. But this is not an RTCWEB standard.

        Harald