[rtcweb] Some thoughts on optional audio codecs

Bo Burman <bo.burman@ericsson.com> Mon, 15 July 2013 15:15 UTC

Return-Path: <bo.burman@ericsson.com>
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 BB6A221E8088 for <rtcweb@ietfa.amsl.com>; Mon, 15 Jul 2013 08:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.032
X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=2.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TcM-SBqeXhAO for <rtcweb@ietfa.amsl.com>; Mon, 15 Jul 2013 08:15:22 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6E21E804D for <rtcweb@ietf.org>; Mon, 15 Jul 2013 08:15:21 -0700 (PDT)
X-AuditID: c1b4fb30-b7ef76d000004bbc-67-51e41208d836
Received: from ESESSHC001.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CD.6F.19388.80214E15; Mon, 15 Jul 2013 17:15:20 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([]) by ESESSHC001.ericsson.se ([]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 17:15:19 +0200
From: Bo Burman <bo.burman@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Some thoughts on optional audio codecs
Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3A==
Date: Mon, 15 Jul 2013 15:15:19 +0000
Message-ID: <BBE9739C2C302046BD34B42713A1E2A22DEE3029@ESESSMB105.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrS6H0JNAgzcHNC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoqj19gLpkhUvG09wtzAeFm4i5GDQ0LARGLabtYuRk4gU0zi wr31bF2MXBxCAocZJWaf2s4E4SxhlLh9bwITSBWbgIbE/B13GUFsEQF1icsPL7CD2MIC+hKP Lsxkg4ibSByb8BvK1pO4dWs62AYWAVWJC7evgsV5BXwljnVuYwGxGQVkJe5/vwdmMwuIS9x6 Mp8J4iIBiSV7zjND2KISLx//Y4U4WlFieb8cRLmexI2pU9ggbG2JZQtfM0OMF5Q4OfMJywRG 4VlIps5C0jILScssJC0LGFlWMbLnJmbmpJebb2IEBvHBLb8NdjBuui92iFGag0VJnHez3plA IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwLvV9+mvmt5fjzF0WJF1+1Zp7OObg2+Wr8/Hff GB7cTvqVM+ns9MNfDpX9miH5s/tke9HJrPzPS2d8LVRmtL5qf+v1pjsyOru8tyXOf6SZJdB6 yTtvPaPi9z1zRXYHv61c9uj/9hX3PlQzWzxf/+CDdFZwd1bq2xe7/qbscOTar6cbZDyj9v8P GSWW4oxEQy3mouJEAGQIMrMwAgAA
Subject: [rtcweb] Some thoughts on optional audio codecs
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, 15 Jul 2013 15:15:26 -0000

Regarding the previous discussion on optional audio codecs in the (currently expired) draft on RTCWEB audio codecs (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/):

I think most parties involved in WebRTC work, myself included, hope and believe that it will be ubiquitous and easy to include real-time media conversation functionality in nearly any web context. Since it will be that easy, it can be expected that most web developers need not be, and thus will not be, media specialists or very knowledgeable about codecs.

The definition of RTCWEB MTI codecs ensures that communication is possible since at least one codec will always be found, but it is not possible to claim the resulting communication to be optimum for every possible context.

Even if WebRTC will be close to ubiquitous, there will for quite some time likely be a desire to reach real-time media domains and devices that were not originally designed for and thus are not optimized for use with WebRTC. A communication device that is not designed solely for WebRTC use will likely include functionality and codecs also for its "native" domain.

Any added cost of not being able to use existing "native" codecs will vary both in amount and where the cost has to be taken. Eliminating it is indeed an optimization, but the total cost savings may still be significant.

With the current design and to my understanding, it will be the browser vendor's choice to add optional codecs, including any "native" domain codecs.  The choice may possibly be delegated to individual web developers making use of WebRTC functionality. A browser vendor will arguably have to know each target platform to some extent, but it can hardly be assumed that a web developer knows the capabilities of all devices that will use the WebRTC-enabled site unless the browser can provide the needed information. There is a risk that "native" codecs in devices are not well handled, unless the motivations and methods to make use of them are better specified.

While any audio codecs besides the MTI ones are clearly optional, I believe the suggested text addition on optional audio codecs to the RTCWEB audio draft in Ticket #12 (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) to be too brief considering the above.

In that draft, I would prefer something more in line with:

"If other suitable audio codecs are available to the browser to use, it is recommended that they are also included in the offer in order to maximize the possibility to establish the session without the need for audio transcoding".

Assuming that the browser vendor (or web developer) is sufficiently concerned with codecs to read the audio codecs draft (or the corresponding RFC to-be), the above text may, as a start, give some added guidance why non-MTI codecs may be desirable to consider in addition to the MTI ones.


Multimedia Technologies
Ericsson Research
Färögatan 6
SE-164 80, Kista, Sweden