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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Dec 2012 09:29:30 +0100

WG,

As an outcome of the Vancouver IETF meeting codec discussions we did
promise to run a call for consensus regarding if the WG was interested
in specifying a small set of recommended audio codecs. We are sorry this
has been delayed until now.

The question for the call of consensus is between two options.

1) Run a process in the WG to select and specify a small set of
audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC
end-points

2) Do nothing and let the already specified Mandatory to Implement Audio
codecs be the only audio codecs mentioned in the WebRTC specification.

Please indicate your position by January 16th 2013.

Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 20 Dec 2012 11:23:49 +0000

Hi,

I think we should make an attempt at 1), i.e. to at least find out if there is a consensus on such as small set of recommended codecs. I don't know what is small, but I would say no more than 1-3. And there has to be a convincing case for each why they add value over G.711 AND Opus.

My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is that those codecs are widely supported in mobile devices and in Circuit Switched and IMS/LTE based VoIP telephony. So they are helpful for transcode-free interoperability with the current and future :-) legacy systems, and in that dimension they would add value to G.711 and Opus. It is not a relevant use case for all WebRTC services, but to a large enough set I believe. Quite many people even proposed AMR/AMR-WB as mandatory for WebRTC. The main reason it was not acceptable was the IPR situation, which quite a few saw inhibitive. That has not changed, but I think the deliberations in that regard are different for "recommended" than "mandatory".

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Magnus Westerlund
>Sent: 20 December, 2012 10:30
>To: [email-masked]
>Subject: [rtcweb] Call for Consensus Regarding Selecting Recommended
>Audio Codecs
>
>WG,
>
>promise to run a call for consensus regarding if the WG was interested in
>specifying a small set of recommended audio codecs. We are sorry this has
>been delayed until now.
>
>1) Run a process in the WG to select and specify a small set of audio/speech
>codecs that would be RECOMMNEDED to implement by a WebRTC end-points
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 20 Dec 2012 14:15:36 -0500

+1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. That
would cover interoperability with existing enterprise SIP PBX systems and
the VoLTE deployments that are rolling out now and will gather market
momentum in 2014. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, December 20, 2012 6:24 AM
To: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended
Audio Codecs

Hi,

I think we should make an attempt at 1), i.e. to at least find out if there
is a consensus on such as small set of recommended codecs. I don't know what
is small, but I would say no more than 1-3. And there has to be a convincing
case for each why they add value over G.711 AND Opus.

My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is
that those codecs are widely supported in mobile devices and in Circuit
Switched and IMS/LTE based VoIP telephony. So they are helpful for
transcode-free interoperability with the current and future :-) legacy
systems, and in that dimension they would add value to G.711 and Opus. It is
not a relevant use case for all WebRTC services, but to a large enough set I
believe. Quite many people even proposed AMR/AMR-WB as mandatory for WebRTC.
The main reason it was not acceptable was the IPR situation, which quite a
few saw inhibitive. That has not changed, but I think the deliberations in
that regard are different for "recommended" than "mandatory".

Markus

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Magnus Westerlund
>in specifying a small set of recommended audio codecs. We are sorry 
>this has been delayed until now.
>
>2) Do nothing and let the already specified Mandatory to Implement 
>Audio codecs be the only audio codecs mentioned in the WebRTC
specification.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Dec 2012 14:22:02 -0500

I would also vote for G.722, AMR, and AMR-WB.
_____________
Roman Shpount

On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey <[email-masked]> wrote:

> Of

---

From: James Rafferty <[email-masked]>
Date: Thu, 20 Dec 2012 14:32:55 -0500

+ 1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Thursday, December 20, 2012 2:22 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:
+1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. That
would cover interoperability with existing enterprise SIP PBX systems and
the VoLTE deployments that are rolling out now and will gather market
momentum in 2014.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
[email-masked]<mailto:[email-masked]>
Sent: Thursday, December 20, 2012 6:24 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended
Audio Codecs

Hi,

Markus

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>To: [email-masked]<mailto:[email-masked]>
specification.
>Ericsson AB                | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
>Färögatan 6                | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
>SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Fri, 21 Dec 2012 10:12:27 +0800

+1

发件人: [email-masked] [mailto:[email-masked]] 代表 James Rafferty
发送时间: 2012年12月21日 3:33
收件人: Roman Shpount; Richard Shockey
抄送: [email-masked]
主题: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

+ 1

_____________
Roman Shpount

-----Original Message-----

[email-masked]

Hi,

Markus

specification.
>Ericsson AB                | Phone  +46 10 7148287 <tel:%2B46%2010%207148287> 
>Färögatan 6                | Mobile +46 73 0949079 <tel:%2B46%2073%200949079>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 20 Dec 2012 20:21:19 -0800

> My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is

I don't think we should list a set of RECOMMENDED codecs. If we were 
talking just G.722, iLBC, etc., I might be persuaded. But this is a 2119 
RECOMMENDED, which is a bit stronger than "Gee, it would be nice," and 
given the aforementioned IPR situation, Mozilla is not likely to be 
deploying any of the AMR family anytime soon.

If the goal is interoperability with deployed systems, you're going to 
implement what you need to implement to achieve that, and nothing we 
write down in an RFC will change what that needs to be.

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Dec 2012 10:27:04 -0600

On 12/20/12 22:21, Timothy B. Terriberry wrote:
> talking just G.722, iLBC, etc., I might be persuaded. But this is a 
> 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be 
> nice," and given the aforementioned IPR situation, Mozilla is not 
> likely to be deploying any of the AMR family anytime soon.
>

I'm going to have to agree with Tim -- very little would be served by 
having normative SHOULD-strength requirements here.

What I think would be beneficial would be a section documenting codecs 
in widespread use today, where they're used, and what is gained by 
including them in WebRTC implementations (mostly transcoder-free interop 
with those other implementations). Documenting that AMR is used in 3GPP 
VoIP networks would allow implementors to make an educated decision 
about the benefit of including that codec. A similar mention that many 
modern VoIP phones support G.722 and/or AAC-LD would provide similar 
guidance.

But I don't think there's much to be gained by readying the scarlet 
letter of "conditionally compliant" that would result from a 
SHOULD-strength normative statement about royalty-bearing codecs.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 21 Dec 2012 16:14:32 -0500

I'm really trying to understand the tortured logic here.  The presumption
was that you wanted to have some limited MTI's here in order to guarantee a
minimum level of interoperability.

Its clear there will be virtually no consensus on Video Codec's not very
much agreement on how text will be supported and now a sustained whine for
either SHOULD/RECOMMENDED ( whatever) for the most practical advanced
codec's that are or will be in use in the public SIP networks.

So instead of providing any minimum guidance to implementers why don't you
basically say "Well there is no consensus on anything and we've collectively
decided to drive off the protocol cliff and see what happens".   

Cliff diving is very popular in the US these days. 

Eliminate all MTI's and just say here is Video menu A, Audio menu B, Text
menu C and Dessert menu D good luck folks! 

That seems to be where you seem to be going.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: Friday, December 21, 2012 11:27 AM
To: Timothy B. Terriberry
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended
Audio Codecs

> write down in an RFC will change what that needs to be.

I'm going to have to agree with Tim -- very little would be served by having
normative SHOULD-strength requirements here.

What I think would be beneficial would be a section documenting codecs in
widespread use today, where they're used, and what is gained by including
them in WebRTC implementations (mostly transcoder-free interop with those
other implementations). Documenting that AMR is used in 3GPP VoIP networks
would allow implementors to make an educated decision about the benefit of
including that codec. A similar mention that many modern VoIP phones support
G.722 and/or AAC-LD would provide similar guidance.

But I don't think there's much to be gained by readying the scarlet letter
of "conditionally compliant" that would result from a SHOULD-strength
normative statement about royalty-bearing codecs.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Dec 2012 15:21:36 -0600

On 12/21/12 15:14, Richard Shockey wrote:
> So instead of providing any minimum guidance to implementers...

I see you didn't make it all the way to the second paragraph of my 
response where I propose providing guidance to implementors. I highly 
recommend it as a riveting sequel to the first paragraph.

/a

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Dec 2012 16:43:13 -0500

On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <[email-masked]> wrote:

> including that codec. A similar mention that many modern VoIP phones
> support G.722 and/or AAC-LD would provide similar guidance.

In reality very few phones support AAC-LD.

For me the major concern is support for G.722. There is no reason not to
support it. None. It is free, it is efficient, and it sounds better then
G.711 any day of the week. It was not made an MTI for political reasons to
promote OPUS. I think it deserves a SHOULD in the standard.

As far  as AMR and AMR-WB are concerned, they should be implemented if your
platform provides it. I, personally, would never pay a license fee for
these codecs, but if implementing a browser on a cell phone where these
codecs are present, I would make an extra effort to support them. So, these
codecs probably do not deserve a SHOULD, but some guidance to implementers
is probably required.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Dec 2012 16:40:09 -0600

On 12/21/12 15:43, Roman Shpount wrote:
>
> On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     What I think would be beneficial would be a section documenting
>     codecs in widespread use today, where they're used, and what is
>     gained by including them in WebRTC implementations (mostly
>     transcoder-free interop with those other implementations).
>     Documenting that AMR is used in 3GPP VoIP networks would allow
>     implementors to make an educated decision about the benefit of
>     including that codec. A similar mention that many modern VoIP
>     phones support G.722 and/or AAC-LD would provide similar guidance.
>
>
> For me the major concern is support for G.722. There is no reason not 
> to support it. None. It is free, it is efficient, and it sounds better 
> then G.711 any day of the week. It was not made an MTI for political 
> reasons to promote OPUS. I think it deserves a SHOULD in the standard.
>
> As far  as AMR and AMR-WB are concerned, they should be implemented if 
> your platform provides it. I, personally, would never pay a license 
> fee for these codecs, but if implementing a browser on a cell phone 
> where these codecs are present, I would make an extra effort to 
> support them. So, these codecs probably do not deserve a SHOULD, but 
> some guidance to implementers is probably required.

I can live with this proposal if need be, but think it's somewhat 
outside the spirit of RFC 2119:

>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions) For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

With an MTI, we have guaranteed interoperability already. The currently 
proposed RECOMMENDED/SHOULD language seems to be the exact kind of thing 
2119 was trying to stave off in the last sentence I cite above.

/a

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 21 Dec 2012 20:00:01 -0500

- From RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

As Tim pointer out, this is a pretty strong recommendation. I would
prefer something weaker like application-dependent guidelines. For
example, something along the lines of "for compatibility with mobile
phones you MAY support AMR, for ISDN you MAY support G.722" and so on.
If all you care about is communication between two browsers, I don't
think there's any codec that needs a SHOULD. Overall, I think there's
about a dozen codecs that can be useful for some applications, but I
don't see any that's really useful for most people.

Cheers,

	Jean-Marc

On 12/20/2012 03:29 AM, Magnus Westerlund wrote:
> WG,
> 
> As an outcome of the Vancouver IETF meeting codec discussions we
> did promise to run a call for consensus regarding if the WG was
> interested in specifying a small set of recommended audio codecs.
> We are sorry this has been delayed until now.
> 
> audio/speech codecs that would be RECOMMNEDED to implement by a
> WebRTC end-points
> 
> Färögatan 6                | Mobile +46 73 0949079 SE-164 80
> Stockholm, Sweden| mailto: [email-masked] 
>  _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 22 Dec 2012 13:17:18 +0000

I agree with Roman's comments below.

So +1 for providing some recommendations on additional audio codec's for RTCWEB.

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 21 December 2012 21:43
To: Adam Roach
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance.

For me the major concern is support for G.722. There is no reason not to support it. None. It is free, it is efficient, and it sounds better then G.711 any day of the week. It was not made an MTI for political reasons to promote OPUS. I think it deserves a SHOULD in the standard.

As far  as AMR and AMR-WB are concerned, they should be implemented if your platform provides it. I, personally, would never pay a license fee for these codecs, but if implementing a browser on a cell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do not deserve a SHOULD, but some guidance to implementers is probably required.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Sat, 22 Dec 2012 11:12:19 -0600

Recommendations or *normative* recommendations? 

I think the former is a very good idea. The latter,  not so much. 

/a

On Dec 22, 2012, at 7:17, "Hutton, Andrew" <[email-masked]> wrote:

> I agree with Roman’s comments below.
>  
> So +1 for providing some recommendations on additional audio codec’s for RTCWEB.
>  
> Andy
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 Dec 2012 08:46:43 +0100

There is an accessibility side of this as well.

Wide band audio can make it much easier for persons with hearing 
impairments to use voice communication over distance.
Therefore both US and European draft regulation or draft standards for 
support of regulation requires wide band audio wherever you have voice 
communication. And these drafts point at G.722 as the common codec at 
least to assure interoperability with wide-band audio between providers.
These draft regulations aim at public procurement and at marketing of 
electronic communication products and services.

Therefore, it seems logical to include G.722 in a codec recommendation 
document.

Gunnar

On 2012-12-22 18:12, Adam Roach wrote:
> On Dec 22, 2012, at 7:17, "Hutton, Andrew" 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> *From:[email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] *On Behalf Of *Roman Shpount
>> *Sent:* 21 December 2012 21:43
>> *To:* Adam Roach
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting 
>> Recommended Audio Codecs
>>
>>
>> to support it. None. It is free, it is efficient, and it sounds 
>> better then G.711 any day of the week. It was not made an MTI for 
>> political reasons to promote OPUS. I think it deserves a SHOULD in 
>> the standard.
>>
>> As far  as AMR and AMR-WB are concerned, they should be implemented 
>> if your platform provides it. I, personally, would never pay a 
>> license fee for these codecs, but if implementing a browser on a cell 
>> phone where these codecs are present, I would make an extra effort to 
>> [email-masked] <mailto:[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Mon, 24 Dec 2012 10:28:32 +0000

I vote 2 - we have enough codec wars without opening another front - for absolutely zero user benefit.

---

From: Burger Eric <[email-masked]>
Date: Tue, 25 Dec 2012 07:24:01 -0500

I vote 2. Discussion in a separate thread.

---

From: Eric Burger <[email-masked]>
Date: Tue, 25 Dec 2012 07:29:50 -0500

Adam has got it in one.

Listen to the arguments: "We want interop with 3G. No, we want interop with SIP/PSTN. No, we want interop with SIP/WB. No, we want interop with NGN. No, we want interop with Skype. No, we want interop with…."

Each of these networks seem to have their own preferred codec. Most of the arguments on the list are of the form, "I want my favorite codec for my favorite network as a SHOULD or as a RECOMMENDED."

The major gastrointestinal objection I have here is every week we argue, someone will come up with "we want to interop with Future Tech 1."

What I would offer as a way forward is to mandate G.711, because we could not agree to mandate opus, and mandate NOTHING ELSE.

We then either have a nice big section in this present document describing the current state of the art of various networks with various codecs *OR* we have an Informational Implementor's Guide that describes the current state of the art of various networks, as well as the pitfalls of popular but hard codecs, like G.722.

On Dec 21, 2012, at 11:27 AM, Adam Roach <[email-masked]> wrote:

>> I don't think we should list a set of RECOMMENDED codecs. If we were talking just G.722, iLBC, etc., I might be persuaded. But this is a 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be nice," and given the aforementioned IPR situation, Mozilla is not likely to be deploying any of the AMR family anytime soon.
>> 
>> If the goal is interoperability with deployed systems, you're going to implement what you need to implement to achieve that, and nothing we write down in an RFC will change what that needs to be.
> 
> I'm going to have to agree with Tim -- very little would be served by having normative SHOULD-strength requirements here.
> 
> But I don't think there's much to be gained by readying the scarlet letter of "conditionally compliant" that would result from a SHOULD-strength normative statement about royalty-bearing codecs.
> 
> /a

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Dec 2012 17:18:04 +0000

> We then either have a nice big section in this present document describing the current state of the art of various networks with various codecs *OR* we have an Informational Implementor's Guide tha…

Would someone be willing to summarize a list of codecs that at some people have argued strongly in favor of along with the main advantage of thawing that codec. I'm thinking of a list that looks something like

AMR-WB   Gets you interop with existing 3GPP 

Having a list like this would be a handy quick references to discussion.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Dec 2012 21:14:32 +0000

> Having a list like this would be a handy quick references to discussion.

Change  "thawing"  to "having" in above

(Curse you autocorrect)

---

From: Tim Panton <[email-masked]>
Date: Thu, 27 Dec 2012 12:14:23 +0000

> Each of these networks seem to have their own preferred codec. Most of the arguments on the list are of the form, "I want my favorite codec for my favorite network as a SHOULD or as a RECOMMENDED."

When in fact (based on my experience at protothon and elsewhere) the _huge_ _predominant_ usage will be browser to browser, peer-to-peer.
We need to be _very_ sure that nothing we do here for the sake of legacy interop makes that user-experience worse.

> What I would offer as a way forward is to mandate G.711, because we could not agree to mandate opus, and mandate NOTHING ELSE.
I thought the current status was that we had agreed to mandate G.711 and Opus already?

---

From: Tim Panton <[email-masked]>
Date: Thu, 27 Dec 2012 12:21:58 +0000

> AMR-WB   Gets you interop with existing 3GPP 

Haha. As if just having the code was going to allow you to interop with existing 3gpp !
How about: 

AMR-WB   Might slightly help your interop struggles  with 3gpp - will definitely land you with a license bill and a user counting problem.

> Having a list like this would be a handy quick references to discussion.

Have we agreed to have a discussion ? 
I thought this was talks about talks to overthrow an existing decision.

If we are in the mood to throw out existing decisions, I've a few I'd like to revisit .....

T.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 27 Dec 2012 16:16:58 +0000

> Haha. As if just having the code was going to allow you to interop with existing 3gpp !

ok - point take than more that is needed but what I'm look info for is the one line bumper sticker style summary of why people feel they want some given codec. 

> If we are in the mood to throw out existing decisions, I've a few I'd like to revisit .....

Just to be clear, we are not talking about tossing out previous decisions. When we decided to make OPUS MTI, we at the same time agreed to not rule out other codecs in the future. That was part of how we got to consensus on OPUS.  We are in the middle of a consensus call on that topic of looking and other codecs and reading the messages on that consensus call, it's a bit hard to figure out what codecs people might want to talk about and why.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Dec 2012 17:32:48 +0100

Speaking as an individual:

I am putting my name on 2), because I believe RECOMMENDED is too strong 
for secondary codecs.

---

From: Steve Sokol <[email-masked]>
Date: Thu, 27 Dec 2012 11:05:34 -0600 (CST)

Per Cullen's request, here is the very short list of audio codecs that seem to have received some interest and the associated benefit of including them in the standard: 

G.722 - The de facto standard for "HD audio", G.722 has the advantage of wide deployment in both hard and soft endpoints. G.722 has no known IPR issues. It consumes a relatively modest 64 Kbps which covers most use cases (though not Edge). Inclusion of G.722 would arguably simplify interoperability with HD-capable legacy endpoints and gateways. 

AMR, AMR-WB - The official standards for mobile telephony. Adding support for the AMR codecs would arguably simplify the process of interoperation with mobile endpoints. Licenses would be required as both include patented technology. 

None - Several group members have argued that the standard should not include SHOULD or RECOMMENDED codecs for various reasons. 

Speaking for myself, I don't see much reason to include any of these. With mandatory encryption, media stream bundling and various other divergences from the way most legacy endpoints operate, I don't see unmediated legacy interoperability as likely to happen -- you will always need something to act as a gateway. That being the case, why clutter up the standard with "SHOULD" or "RECOMMENDED" directives? 

The best thing about WebRTC is that it is (thus far) not an attempt to re-build the PSTN on yet another IP platform. Keep is simple.

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Dec 2012 12:20:55 -0600

On 12/27/12 11:05, Steve Sokol wrote:
> I don't see unmediated legacy interoperability as likely to happen

Ugh. I hate repeating this, but there is a radical difference between 
dealing with computationally cheap things like bundling, ICE, SCTP and 
even (from a relative perspective) encryption and dealing with 
re-encoding media.

Transcoding perceptibly increases end-to-end latency. Transcoding 
perceptibly degrades the final audio stream. All other gatewaying 
functions can be done cheaply enough that the user cannot tell a difference.

Which is why I think there is *utility* to listing commonly used codecs 
and explaining where/how they are used. I really do want to see this as 
part of a guidance section for implementors.

However, I don't think any of those reasons rise to the level of an RFC 
2119 "SHOULD" level statement.

/a

---

From: Koen Vos <[email-masked]>
Date: Thu, 27 Dec 2012 18:33:44 +0000

Steve Sokol wrote:
> G.722 has no known IPR issues.

This is inaccurate.

While the basic codec has no such issues, the various Packet Loss Concealment methods that were later added to the standard are patented.  This matters because G.722 uses ADPCM and is unusually sensitive to packet loss.  For instance, without PLC the codec will sometimes generate a full-scale oscillating output after a loss.  Since a traditional PLC doesn't work for this kind of behavior, there was a need to invent a PLC specifically for G.722.

In short: there are IPR issues with the PLC required for using G.722 on the Internet.

koen.

________________________________
From: [email-masked] on behalf of Steve Sokol
Sent: Thursday, December 27, 2012 9:05 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

---

From: <[email-masked]>
Date: Mon, 31 Dec 2012 11:28:40 +0000

Hi,

Actually, I think both Tim and Adam have good points below. RFC 2119 style RECOMMENDED or SHOULD is perhaps too strong. I don't have a problem if we just list the most relevant non-MTI codecs and give guidance why it would be beneficial to support them.

So far a few people have brought up AMR/AMR-WB and G.722 with relatively clear arguments. iLBC and AAC-LD have been mentioned too, but I think their benefits have not been as well clarified so far.

Markus

>Of ext Adam Roach
>Sent: 21 December, 2012 18:27
>other implementations). Documenting that AMR is used in 3GPP VoIP
>networks would allow implementors to make an educated decision about the
>benefit of including that codec. A similar mention that many modern VoIP
>But I don't think there's much to be gained by readying the scarlet letter of
>"conditionally compliant" that would result from a SHOULD-strength

---

From: <[email-masked]>
Date: Mon, 31 Dec 2012 11:33:23 +0000

Hi,

Yes, I agree Adam's proposal would be the best approach. A codec alone will not solve the interop issues with IMS or other external VoIP systems, but as Adam says, transcode-free operation at the (media) gateway would be an important consideration. 

Markus

>Sent: 27 December, 2012 20:21
>To: Steve Sokol
>Cc: Cullen Jennings (fluffy); [email-masked]
>Ugh. I hate repeating this, but there is a radical difference between dealing
>with computationally cheap things like bundling, ICE, SCTP and even (from a
>relative perspective) encryption and dealing with re-encoding media.
>
>perceptibly degrades the final audio stream. All other gatewaying functions
>can be done cheaply enough that the user cannot tell a difference.
>
>Which is why I think there is *utility* to listing commonly used codecs and
>explaining where/how they are used. I really do want to see this as part of a
>guidance section for implementors.
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 31 Dec 2012 11:50:00 -0500

On 12/27/2012 11:32 AM, Harald Alvestrand wrote:
> I am putting my name on 2), because I believe RECOMMENDED is too 
> strong for secondary codecs.

I am also voting for 2) for similar reasons (and in fact I'd probably 
vote against a "SHOULD" also).

-- 
Randell Jesup
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Dec 2012 11:04:49 -0600

> vote against a "SHOULD" also).

FWIW, RFC 2119 defines these terms to mean exactly the same thing:

     3. SHOULD   This word, or the adjective "RECOMMENDED", mean...

/a