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

[Steve Sokol <[e-mail]>]

Trying to summarize the arguments an perhaps to offer a reasonable compromise so that we can move forward... 

We essentially have four primary use cases to manage: 

[Browser] === [Browser] (Use Opus - theoretically no IPRs) 
[Browser] === [PSTN] (use G.711 - no IPRs) 
[Browser] === [IP PBX] (use G.722 - theoretically no IPRs with possible exception of PLC) 
[Browser] === [Mobile] (AMR / AMR-WB - known IPRs or GSM 6.10 (FR) - no IPRs) 

These have an impact on: 

- Browser manufacturers (of which there are essentially five), who would have to implement all codecs or risk the wrath of SHOULD. 
- Gateway manufacturers, who would need to implement all of the codecs that fit into their use cases. 
- Platform manufacturers, who may chose to include hardware implementations of the various codecs. 

By far the most heavily impacted in this are the browser manufacturers, since the onus is on them to build to the standard. 

The arguments seem to focus on: 

- Cost of licensing IP for patent encumbered codecs 
- Viability / quality of codecs in an Internet environment 

Cost of licensing can be qualified as a major concern. Browsers are generally free (often both libre and gratis) and therefore cannot impose an cost to their manufacturers. The viability / quality issues strikes me as less important. In the best of all possible worlds, everything would include Opus, preferably in silicon. We don't live in that world. We live with the compromises and issues of the other codecs every day. Perhaps poor quality of calls over those codecs will push more people into using "pure-play" WebRTC. ;-) 

The current standard states that Opus and G.711 are both mandatory to implement. That leaves us with G.722, AMR, AMR-WB and possibly GSM 6.10 as potential recommended. 

While it is not an optimal "internet codec", it costs nothing to to include G.722, so perhaps we can all agree that it should be included unless there is some reason not to do so. 

The same hold true for GSM 6.10. (I don't know if modern mobile devices still support FR. Anybody know?) It takes very little power and, while it's not great, it provides acceptable level of quality for basic communication. So let's add it to the "SHOULD" pile. 

That leaves us with the AMR codecs. I don't know where things stand today, but last time we looked at offering AMR licenses for Asterisk, the price was prohibitive. You can argue that the codec is already in silicon on most mobiles, but that means nothing if it is not exposed to developers via the audio framework. To me, the expense on the browser side and the lack of availability on the application side rule this out, especially if we can solve the mobile use case with GSM 6.10. 

If you agree with all of the above, that leaves us with two SHOULD codecs: G.722 and GSM 6.10. 

That would leave our browser-building friends with two free codecs to add and would appear to cover all of the primary use cases. 

Steve Sokol 
Strategic Programs Director | Digium, Inc. 
408 Camelot Drive, Liberty, MO 64068 
Direct: [phone] 
Mobile: [phone] 

Ask me about Asterisk 
----- Original Message -----

> Agreed

> The fact that the platform supports it does not mean that a browser
> has an API to enable it. That is dependent on the phone
> architecture.

> Andrew

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tim Panton
> Sent: Thursday, January 17, 2013 11:24 AM
> To: Mark Rejhon
> Cc: [e-mail]
> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting
> Recommended Audio Codecs

> On 17 Jan 2013, at 15:59, Mark Rejhon wrote:
> > . For example, a mobile phone implementation would likely have easy
> > access to AMR codecs, and therefore SHOULD implement these codecs
> > on
> > this platform.

> You might think so, but last I looked, neither iOS nor android expose
> the amr-wb encoder.
> I'd be delighted to be shown I'm wrong.

> T.

> _______________________________________________
> rtcweb mailing list
> [e-mail]
> 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.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb