Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Andrew Allen <> Thu, 17 January 2013 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9F7121F8778 for <>; Thu, 17 Jan 2013 10:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.083
X-Spam-Status: No, score=-5.083 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a0MpInA5aj75 for <>; Thu, 17 Jan 2013 10:00:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9669521F8794 for <>; Thu, 17 Jan 2013 10:00:00 -0800 (PST)
X-AuditID: 0a412830-b7f646d0000038d1-d5-50f83c1f79f2
Received: from ( []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id 1F.96.14545.F1C38F05; Thu, 17 Jan 2013 12:00:00 -0600 (CST)
Received: from ([fe80::2494:a63d:e3:723b]) by ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 11:59:58 -0600
From: Andrew Allen <>
To: Mark Rejhon <>, "" <>
Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs
Thread-Index: AQHN9MuurLbfXCCKTkues+O2TLjeQZhNzHbQ
Date: Thu, 17 Jan 2013 17:59:57 +0000
Message-ID: <>
References: <> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5Zyvratg8yPAYPo6VotZG6+zWKz9187u wOSxc9Zddo8lS34yBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejLXX7zEV3JKqeHZxKlsD40PRLkZODgkBE4lVV6cz QthiEhfurWcDsYUE2pgkWvfHdTFyAdmbGSX2HJjMBJJgE1CWWP57BliDiICnxPxJJ8BsYYFw ifsv1zNDxCMkDp6aBmUbSfz/2MUCYrMIqErMmbQHbA6vgIfEk+1TmCAWvGOUeH7tONBmDg5O gUCJlpYUkBpGAVmJ3Wevg9UzC4hL3HoynwniUAGJJXvOM0PYohIvH/9jhbAVJWbsmc8KUa8j sWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjIK5GcUGZobJecl6 RZm5enmpJZsYQenAUcNgB+P79xaHGAU4GJV4eJvMfwQIsSaWFVfmHmKU4GBWEuF9xQIU4k1J rKxKLcqPLyrNSS0+xOgKDJWJzFLcyfnAVJVXEm9sYICboyTOK9l7OUBIIB2YfLJTUwtSi2Dm MHFwguzhkhIpBqaQ1KLE0pKMeFCiiy8GpjqpBkZF1QkHrH8xPODUWMw3/26H9YUOfhV1BbZD fdWvPdte8Uivnqim8DlR0Jy3bqf3vLzflTFXDSOlZ5vU6RxzW81w4O++dQeyIxT61m3of/SA L8dm9oIE3auX/5mrTPlea7fmTEa0reuRGKHH09+zCvUdn/XnoYv4w3URcVv1clbcenxlPVPX 7t9KLMUZiYZazEXFiQALb6wiSAMAAA==
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Thu, 17 Jan 2013 18:00:05 -0000


I think our positions are close but I think your text still goes too far as a codec may be supported by the platform but not be available to the browser and I also do not think that IETF should say anything about additional codecs with a SHOULD strength.

I would propose:	:

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

This is enough to make implementers think about the transcoding issue.


-----Original Message-----
From: [] On Behalf Of Mark Rejhon
Sent: Thursday, January 17, 2013 10:59 AM
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

On Thu, Jan 17, 2013 at 10:16 AM,  <> wrote:
> Strictly sticking to the current situation with only OPUS and G.711 will not solve properly the issue especially because this would mean to fail to address correctly the biggest market of hundreds of millions of mobiles terminals that currently support neither G.711 nor OPUS.

I have a suggestion, from the perspective of an outsider (mainly due to real-time text).
There's a way to call AMR "OPTIONAL", while automatically making it almost "REQUIRED"!!!
This is accomplished by using "SHOULD" from a different perspective.
-- This is a better direction for IPR solution
-- This is a better direction for long term (codecs become obsolete, new codecs become available).

***** STAGE 1 *****

"Implementors SHOULD include codecs (that are otherwise OPTIONAL) if they are already provided on the platform that the implementation runs on.  For example, a mobile phone implementation would likely have easy access to AMR codecs, and therefore SHOULD implement these codecs on this platform.  This also anticipate that available codecs are always evolving, including future codecs not yet developed at this time of writing."
(not final wording, but you get the spirit)

***** STAGE 2 *****

Now that mobile WebKit browsers would tend to standardize WebRTC on including access to the device's own built-in AMR codecs.  These mobile Webkit implementations start calling everybody else who has WebRTC.  This can provide incentive for implementers on non-mobile platforms (who wish to maximize interoperability without transcoding issues and degradation concerns) to add AMR -- they now have an economic incentive as a result of the indirect "SHOULD" in STAGE 1.
They can either live with the disadvantages of the standard codecs, or live with the advantages of native AMR support (at least while AMR is still popular, and become obsoleted by other codecs in newer phones, and the cycle starts over again).

***** BOTTOM LINE *****

-- We've effectively mandated a "SHOULD", while dodging the IPR issues.
-- We've effectively future-proofed ourselves
-- We've provided proper incentive
-- We still at least make interop possible to at least say "hello" to someone, making only a couple codecs REQUIRED

Mark Rejhon
rtcweb mailing list

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.