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

Magnus Westerlund <> Wed, 19 February 2014 08:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D1A81A00AD for <>; Wed, 19 Feb 2014 00:16:11 -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 272lfyMvGLde for <>; Wed, 19 Feb 2014 00:16:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7A3D91A0080 for <>; Wed, 19 Feb 2014 00:16:07 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-54-530468437a1d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D9.57.23809.34864035; Wed, 19 Feb 2014 09:16:03 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Wed, 19 Feb 2014 09:16:02 +0100
Message-ID: <>
Date: Wed, 19 Feb 2014 09:16:02 +0100
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+NgFmpiluLIzCtJLcpLzFFi42KZGfG3Rtc5gyXYYO0yIYtjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBmX/25lK9gjXHFg60W2BsYH/F2MnBwSAiYS 80/dYIOwxSQu3FsPZHNxCAkcYpRYveg3O0hCSGA5o0TjqtAuRg4OXgFtibXHjEHCLAKqEm+2 rGMGsdkELCRu/mgEmyMqECyx88BvRhCbV0BQ4uTMJywgtoiAvcTFOS/BbGGBQokju3pYIcb7 SPTt+g9mcwroSlx8+oARZJWEgLhET2MQSJhZQE9iytUWRghbXqJ562xmiFZtiYamDtYJjIKz kGybhaRlFpKWBYzMqxjZcxMzc9LLjTYxAsPx4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZGeXkf5ghuL4P7M9+JFdlUmQWzO75quMYcED3Z9oVefTvT bu6/t7KZZ1oanJ/opd5RbWyyXoJ/tWF7+/k/OydNY9r1ZjGn/xKlOJeWVr+A7KOzJh+48nSu 9Hr1koC2U1W/V/D27mtz37rifZL0e7cGKe4Lhxc5sups0LDVX77uXH5Y2/v0+41KLMUZiYZa zEXFiQChBnnRFQIAAA==
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: Wed, 19 Feb 2014 08:16:11 -0000

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.

> I mean - if a G.711 receiver is able to handle any packet size thrown at
> it, why do we need to put requirements on the sender (apart from "don't
> send bigger packets than the maxptime")? For interoperability with
> non-WebRTC endpoints?

If the above endpoint would be to send 109 samples in each RTP payload
then I think more than one of the current PCMA receivers would fall on
its back. In an WebRTC to WebRTC case, interoperability would be
achieved. However, if you talk about legacy interoperability (across a
gateway) you want to avoid having to basically insert a jitter buffer
and reconstitute the RTP payloads into something that that system
supports. That is why I suggest that certain common sizes an WebRTC
implementation MUST be capable of producing.

> Of course, I do have a question, now that all the ptime and maxtime
> definitions have been put on the table:
> Is it true that ptime and maxptime only specify the SDP sender's
> declaration of his desires for incoming packet streams? That is, that
> there is nowhere specified what the sender intends to send? I think that
> is true for ptime in RFC 3264 offer/answer, and would assume that the
> same is true for maxptime.

Yes, there are no attribute for its intended send direction unless the
m= block is a sendonly/recvonly O/A exchange where the sendonly
direction can kind of indicate it is preference for what it want/will send.


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: