Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb

Tim Panton <> Thu, 16 August 2012 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 118D421F861F for <>; Thu, 16 Aug 2012 02:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3r3dY36JnA7e for <>; Thu, 16 Aug 2012 02:41:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 47A1321F84FD for <>; Thu, 16 Aug 2012 02:41:08 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id BEE2237A905; Thu, 16 Aug 2012 10:49:53 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459"
From: Tim Panton <>
In-Reply-To: <>
Date: Thu, 16 Aug 2012 10:40:53 +0100
Message-Id: <>
References: <>
To: "Mandyam, Giridhar" <>
X-Mailer: Apple Mail (2.1278)
Cc: "" <>
Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb
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: Thu, 16 Aug 2012 09:41:13 -0000

On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote:

> Hello All,
> Qualcomm is in favor of G.711 being the only mandatory-to-implement codec for RTCWeb.  We do not support having both Opus and G.711 as mandatory-to-implement codecs.  We state the following reasons:
> a)      There is no technical need to have an audio codec besides G.711 be designated as mandatory to implement.  Because RTCWeb uses SDP to negotiate the codecs, the only reason to have anything as mandatory is to make sure there is always at least one codec that both sides can use, a lowest common denominator.  This allows the market to decide which codecs to support, rather than edict from a standards body.  Implementations can base their choice of which codec to support based on what they are trying to optimize.  For example, better performance for the environment at the time of the session, such as cell phone or desktop.

I made exactly the same argument about H261 and was told (correctly) that it was unacceptable to mandate a codec that would give users a
poorer than necessary experience. I think what applies for video applies for audio.

Specifically g711 is a poor codec choice in a wide variety of network situations - e.g. 3g and edge of wifi. In my experience a lower bandwidth
codec which supports wideband, dynamically variable bitrates and error correction / packet loss concealment is required to give these users audio
that is acceptable to use in the  coffee-shop / airport scenario. 

> b)      G.711 is universal, unencumbered, and widely implemented.    In addition, note that codec implementation and testing is quite costly for chip and device manufacturers, and that cost is ultimately reflected in the cost of the end-user device.  The computational simplicity of G.711 and its long-time availability on a broad range of platforms means that the implementation is available on low/entry-tier devices and testing costs have already been amortized over many years, thereby enabling its use in low cost end-user devices.  If we want to see widespread use of RTCWeb for voice, than we will reach a much broader population if the minimum requirements do not prohibit low-cost devices. 

There are many codecs which that can be said for. We happily run speex on low end smartphones. - Heck we even use the java implementation in
applets and get acceptable performance. g722 has recently dropped out of patent, uses the same bandwidth as 711 and gives significantly better audio.
Any device capable of running SRTP is capable of running either 722 or speex in my experience. 

> c)       A mandate for Opus will limit initial RTCWeb clients to use software-based  codecs (on general purpose processors) where Opus can be implemented and tested easily until it is available on a variety of DSPs.  Even then, it will likely start on high-cost platforms.  This may in turn mean that RTCWeb clients could consume significantly more battery power than DSP-based codecs used in many traditional (circuit-switched) voice services, further inhibiting the end-user from choosing RTCWeb over those services.

You are confusing mandatory-to-implement and mandatory-to-use. Just because Opus must be available , you don't have to use it. The devices you 
mention almost all have AMR in DSP - but unfortunately that is encumbered so isn't ideal as a mandatory-to-implememnt codec but may well be 
used when it is available. 

> d)      We do not believe Opus is more versatile than other standardized codecs, because any measure of versatility should take into account quality at a given bitrate.  If Opus is not able to deliver superior quality at all supported bitrates when compared to other codecs, then it cannot be deemed as being more versatile simply because it supports more bitrates when compared to other standardized codecs.

Again - making Opus mandatory to implement does not preclude supporting or using any other codecs. 

By the way point d) applies to any codec you choose to name - so you are probably arguing for no mandatory-to-implement codec - which would be
a mistake I think. It certainly applies to g711 - in spades!

> In conclusion - the IETF has a strong tradition of starting work with the least amount of complexity and specification possible, gaining operational experience, and then refining things with revisions or extensions.  So, the least amount of complexity would be G.711 as the sole audio codec.

RTCweb is never going to be a _least_possible_complexity_ project. The requirements mean we need  SRTP (DTLS?), a video modern codec, Echo cancellation, AGC, etc. Adding a good audio codec will not significantly extend the complexity.

> _______________________________________________
> rtcweb mailing list