[rtcweb] Mandatory-to-Implement Audio Codecs for RTCWeb

John Leslie <john@jlc.net> Mon, 20 August 2012 16:26 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7521F86F2 for <rtcweb@ietfa.amsl.com>; Mon, 20 Aug 2012 09:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.737
X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DfsTl71BJ1cC for <rtcweb@ietfa.amsl.com>; Mon, 20 Aug 2012 09:26:26 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net []) by ietfa.amsl.com (Postfix) with ESMTP id 567D221F86E5 for <rtcweb@ietf.org>; Mon, 20 Aug 2012 09:26:26 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 28A6933C27; Mon, 20 Aug 2012 12:26:26 -0400 (EDT)
Date: Mon, 20 Aug 2012 12:26:26 -0400
From: John Leslie <john@jlc.net>
To: Tim Panton <tim@phonefromhere.com>
Message-ID: <20120820162626.GE85937@verdi>
References: <CAC8DBE4E9704C41BCB290C2F3CC921A162A76AB@nasanexd01h.na.qualcomm.com> <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com>
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "Mandyam, Giridhar" <mandyam@quicinc.com>
Subject: [rtcweb] Mandatory-to-Implement Audio Codecs for RTCWeb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2012 16:26:27 -0000

Tim Panton <tim@phonefromhere.com> wrote:
> On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote:
>> Qualcomm is in favor of G.711 being the only mandatory-to-implement
>> codec for RTCWeb.

   An otherwise valid argument is mortally wounded by this statement.
We participate as individuals in IETF Working Groups; and stating
something as a "position" tends to make others consign you to "the rough".

>> We do not support having both Opus and G.711 as mandatory-to-implement
>> codecs.  We state the following reasons:
>> 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.

   Exactly true!

>> 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.

   The intended situation as RTCWEB matures is that the endpoints will
choose among a number of codecs which both support, taking into account
the characteristics of the link between them.

> 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.

   No, that is not "correctly"!

   It would be unacceptable to mandate the _use_ of a codec giving
sub-standard experience; but it is _exactly_ acceptable to mandate the
_implementation_ of a codec which gives "poorer than necessary
experience" in even a _majority_ of actual conditions.

   We certainly hope there will be better options available for
particular conditions; and we certainly hope that the conditions
available will improve.

> I think what applies for video applies for audio.

   Mostly true; but given a century of experience with audio-only
telephone use, there is perhaps wiggle-room for failure to agree on
a video codec. (What I mean here is that _if_ we can't find any video
codec that all RTCWEB stacks "can" implement, we could theoretically
fall back to a short list of SHOULD implement.)

> Specifically g711 is a poor codec choice in a wide variety of
> network situations - e.g. 3g and edge of wifi.

   True, but that's the wrong consideration. A mandatory-to-implement
codec isn't asked to give "good" results in every case.

> 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. 

   That's a good argument; but it goes beyond the target we're aiming
for as "mandatory-to-implement".

>> 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.

   This is also a good argument; and it is pretty much on-target.

>> 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. 

   This is a weaker argument, but still appropriate IMHO.

> 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. 

   And this is a good counter-argument...

>> 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.

   I find this argument weak. I would expect any RTCWEB device to
need to _start_ on this path.

>> 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.

   That's a valid argument; but it's about a commercial tradeoff,
and I don't see a good reason why we need to optimize for a particular
commercial environment.

> You are confusing mandatory-to-implement and mandatory-to-use.

   A lot of us seem to be suffering from that confusion!

> Just because Opus must be available, you don't have to use it.

   You _might_ have to use it... But it's only required as a last
resort, and it's perfectly reasonable to warn the end-user that
battery life will suffer.

> 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. 
>> 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.

   This is a straw-man. :^(

> Again - making Opus mandatory to implement does not preclude
> supporting or using any other codecs. 
>> 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.

   That's not as true as it used to be. :^(

>> 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.

   This thread is full of good arguments!

   I hope we will contiue it, but hold a little better to what we
mean by "mandatory-to-implement".

John Leslie <john@jlc.net>