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

Magnus Westerlund <> Tue, 04 March 2014 18:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 26DDC1A01F1 for <>; Tue, 4 Mar 2014 10:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JWh7BLWcV47t for <>; Tue, 4 Mar 2014 10:28:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AE4AD1A02CE for <>; Tue, 4 Mar 2014 10:28:29 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ac-53161b498e34
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.E1.10875.94B16135; Tue, 4 Mar 2014 19:28:25 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Tue, 4 Mar 2014 19:28:24 +0100
Message-ID: <>
Date: Tue, 04 Mar 2014 18:28:23 +0000
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Harald Alvestrand <>,
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RtdTWizYYMoVM4tjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBkXLixjL9gsWXHw8zmWBsbjIl2MnBwSAiYS lz4sY4awxSQu3FvP1sXIxSEkcIhRYt/amywQzjJGiTlL54JV8QpoSxx9eJQVxGYRUJFY1DAb zGYTsJC4+aORDcQWFQiW2HngNyNEvaDEyZlPWEBsEQF7iYtzXoLZwgKFEkd29YD1CgmcY5S4 fsWoi5GDg1NAV+LHFWMQU0JAXKKnMQikgllAT2LK1RZGCFteonnrbGaITm2JhqYO1gmMgrOQ LJuFpGUWkpYFjMyrGNlzEzNz0ssNNzECA/Lglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBkZNrr1+8v+68mUdMtOOy/qbSVxl9Zohd5aTXy9YhnnT874v OjmyhjL9RnkXdYVPn3N4JJ54zH+6/RrvWyUCCVUPLJ/ZBDcsa1q/2eFBb8PtlSw7j+dsK5l7 e6Hm2SY5pZoVJ7jW+/0Pf+jD5fXf2q/goKiksd6andXKyqEz1t/0q94aXSVTrsRSnJFoqMVc VJwIAGqwU9kWAgAA
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: Tue, 04 Mar 2014 18:28:35 -0000

On 2014-03-01 16:47, Harald Alvestrand wrote:
> 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.

I appear to be in the rough on this. I don't expect any real issues with
this as long as implementations do sane things. (I was tempted to write
"the right thing (TM)".

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: