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

Mark,

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.

Andrew

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

On Thu, Jan 17, 2013 at 10:16 AM,  <stephane.proust@orange.com> 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

Sincerely,
Mark Rejhon
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

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