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

Harald Alvestrand <> Sat, 01 March 2014 16:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C95591A0214 for <>; Sat, 1 Mar 2014 08:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.344
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EirWpUm_fnQW for <>; Sat, 1 Mar 2014 08:47:14 -0800 (PST)
Received: from (unknown [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 823C01A00A6 for <>; Sat, 1 Mar 2014 08:47:14 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB06D7C4E75; Sat, 1 Mar 2014 17:47:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LvKJXpsRa7-J; Sat, 1 Mar 2014 17:47:10 +0100 (CET)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id E63A87C4E2C; Sat, 1 Mar 2014 17:47:10 +0100 (CET)
Message-ID: <>
Date: Sat, 01 Mar 2014 17:47:10 +0100
From: Harald Alvestrand <>
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 <>,
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
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.