Re: [rtcweb] Confirmation of consensus on audio codecs

Randell Jesup <> Tue, 21 August 2012 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9844921F84A5 for <>; Tue, 21 Aug 2012 08:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_20=-0.74, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id omc2X4IY0Iim for <>; Tue, 21 Aug 2012 08:02:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACE3F21F8491 for <>; Tue, 21 Aug 2012 08:02:42 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1T3pyb-0007RO-Ql for; Tue, 21 Aug 2012 10:02:41 -0500
Message-ID: <>
Date: Tue, 21 Aug 2012 11:02:23 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
References: <> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup>
In-Reply-To: <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs
X-Mailman-Version: 2.1.12
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, 21 Aug 2012 15:02:43 -0000

On 8/21/2012 3:57 AM, wrote:
> For voice and multimedia communication services as targeted by WebRTC, two codecs, G.711 and G.722, are fully fitting the conditions to get a mandatory to implement status: a fully ensured unencumbered status, a wide implementation in devices and legacy networks and a low complexity that ensures they can be supported on any types of plate-forms and terminals.
> So we support both G.711 and G.722 to be specified as "mandatory to implement" codecs since G.722 will guarantee a much higher voice quality at same bit rate and almost no additional cost. At a minimum G.722 should be (strongly) recommended.

I agree G.722 should be a "SHOULD".

Note I said "I".  While in reality corporations and organizations that 
IETF contributors are associated with have opinions on IETF activities, 
officially IETF recognizes individuals as contributors.

> With respect to OPUS, it has currently no footprint on the market, its implementation complexity and resulting costs are unknown, including with respect to IPRs issues, and some performance aspects are still to be more deeply assessed, like for instance quality with packet losses and jitter which is a key issue for usage over internet.

Opus was designed within the IETF specifically to handle usage over the 
Internet better than existing codecs.

> In addition, we believe that two additional requirements are necessary to make WebRTC a future proof technology and suitable for a wide range of applications and environments:
> Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB.

The spec does not restrict what codecs can be supported beyond the MTI 
codecs.  You can offer any codecs you support.

> Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser.

This is an implementation detail for browsers and not part of the spec; 
a browser is free to offer any codecs supported by the platform if it 

Randell Jesup