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

From: Andrew Allen <[email-masked]>
Date: Thu, 3 Jan 2013 17:24:51 +0000

I also support 2)

I really don't think it helps much to describe what other codecs are out there that you might want to think about implementing if you want to interoperate with certain other non RTCweb deployments. I think anybody who is seriously thinking about developing such a product can easily find this out for themselves - if you want to interoperate with 3GPP devices then take a look at the CURRENT 3GPP Codec specifications!

It should be realized that the codec life cycle tends to be somewhat shorter than that of the signaling technology so the codec information is likely to become out of date long before the signaling specifications become obsolete (possibly already dated by the time the RFC is published) - 3GPP is already working on a new codec for LTE!

As everyone has a favorite codec they would like to see deployed the downside of this is that this will likely become a distraction that generates a lot of discussion and consumes a lot of cycles that would be better spent on addressing the basic interoperability issues facing RTCweb.

So I think the MTI audio codecs already agreed is enough to ensure interoperability.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Thursday, December 27, 2012 11:33 AM
To: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Speaking as an individual:

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

On 12/20/2012 09: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.
>
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]
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.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 4 Jan 2013 10:47:59 +0000

I previously indicate support for 1) but I note the arguments put forward by Adam Roach and agree that normative recommendations for additional codec's are not necessary here.

However I think it would be helpful to have some non normative text describing how the implementation of particular codec's would improve interoperability in specific environments (E.g. mobile) and although this could be left to browser vendors to work out for themselves I don't think that is a good argument for not doing it. We are here to promote interoperability after all.

I also disagree that the MTI codec's already agreed are sufficient to ensure interoperability with non RTCWEB environments which according to the rtcweb charter should be considered.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Allen
> Sent: 03 January 2013 17:25
> To: Harald Alvestrand; [email-masked]
> I really don't think it helps much to describe what other codecs are
> out there that you might want to think about implementing if you want
> to interoperate with certain other non RTCweb deployments. I think
> anybody who is seriously thinking about developing such a product can
> easily find this out for themselves - if you want to interoperate with
> 3GPP devices then take a look at the CURRENT 3GPP Codec specifications!
> 
> It should be realized that the codec life cycle tends to be somewhat
> shorter than that of the signaling technology so the codec information
> is likely to become out of date long before the signaling
> specifications become obsolete (possibly already dated by the time the
> RFC is published) - 3GPP is already working on a new codec for LTE!
> 
> As everyone has a favorite codec they would like to see deployed the
> downside of this is that this will likely become a distraction that
> generates a lot of discussion and consumes a lot of cycles that would
> be better spent on addressing the basic interoperability issues facing
> 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.

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 7 Jan 2013 18:18:02 +0100

My thoughts are in line with the ones from Andrew. Using normative language may be too strong, but we should document the ecosystem to allow interoperability with terminals not implementing 
RTCWeb MTI codecs without introducing too big transcoding needs in RTCWeb gateways in the network. 

E.g., a mobile terminal natively implementing codecs such as AMR-WB anyway could offer them in addition to the MTI codecs in RTCWeb session set-ups. A gateway connecting such a terminal to non-RTCWeb terminals in the mobile network would prefer such a mobile-specific codec over the MTI ones, as this decreases the use of the transcoding resources in the gateway.

Guidelines of that kind could be part of the text to be written, too. 

Kind regards,
Uwe 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hutton, Andrew
Sent: Friday, January 04, 2013 11:48 AM
To: Andrew Allen; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Regards
Andy

> Behalf Of Harald Alvestrand

---

From: <[email-masked]>
Date: Fri, 11 Jan 2013 12:33:02 +0000

It is clear from the discussions on the rtcweb e-mail reflector that the only additional codecs to be considered are limited to the following very small subset of 3 codecs: AMR, AMR-WB and G.722. 
In addition to G.711, these 3 codecs cover almost all legacy devices dedicated to voice services. They are consequently needed and sufficient to be supported by WebRTC to make it an attractive and future proof technology for usage in all environments including mobile and for interoperability use cases with most of all legacy voice terminals.

AMR and AMR-WB are indeed the most widely supported voice codecs in hundreds of millions of legacy mobile devices.
G.722 is royalty free (including a Packet Loss Concealment solution provided in ITU-T Software Tool Library) and is the codec used for HD Voice / DECT-Cat IQ fixed devices

Furthermore, considering that the reason for excluding AMR and AMR-WB from WebRTC was the licensing issue, there is no reason to NOT support AMR-WB and AMR at WebRTC level if these codecs are already implemented on the device.

Therefore I support option 1 and propose the following specification according this:
AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC end-points
AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points on 3GPP mobile devices already implementing AMR and AMR-WB (*)

(*) note that the way these codecs are supported at RTC Web level is left open to implementors: either by a WebRTC specific software implementation of these codecs or by using APIs to access hardward implementation. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Magnus Westerlund
Envoyé : jeudi 20 décembre 2012 09:30
À : [email-masked]
Objet : [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

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.

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

Regards

Magnus Westerlund

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Paul Coverdale <[email-masked]>
Date: Fri, 11 Jan 2013 10:56:59 -0500

I support Stephane's proposal for option 1. It makes good sense,
particularly for the case where AMR and AMR-WB are already implemented in
mobile devices - there are no additional licensing issues and it simplifies
interoperability.

...Paul

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of [email-masked]
>Sent: Friday, January 11, 2013 7:33 AM
>To: Magnus Westerlund; [email-masked]
>It is clear from the discussions on the rtcweb e-mail reflector that the
>only additional codecs to be considered are limited to the following
>very small subset of 3 codecs: AMR, AMR-WB and G.722.
>In addition to G.711, these 3 codecs cover almost all legacy devices
>dedicated to voice services. They are consequently needed and sufficient
>to be supported by WebRTC to make it an attractive and future proof
>technology for usage in all environments including mobile and for
>interoperability use cases with most of all legacy voice terminals.
>
>AMR and AMR-WB are indeed the most widely supported voice codecs in
>hundreds of millions of legacy mobile devices.
>G.722 is royalty free (including a Packet Loss Concealment solution
>provided in ITU-T Software Tool Library) and is the codec used for HD
>Voice / DECT-Cat IQ fixed devices
>
>Furthermore, considering that the reason for excluding AMR and AMR-WB
>from WebRTC was the licensing issue, there is no reason to NOT support
>AMR-WB and AMR at WebRTC level if these codecs are already implemented
>on the device.
>
>AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points on
>3GPP mobile devices already implementing AMR and AMR-WB (*)
>
>(*) note that the way these codecs are supported at RTC Web level is
>left open to implementors: either by a WebRTC specific software
>implementation of these codecs or by using APIs to access hardward
>implementation.
>
>
>De : [email-masked] [mailto:[email-masked]] De la part
>de Magnus Westerlund Envoyé : jeudi 20 décembre 2012 09:30 À :
>[email-masked] Objet : [rtcweb] Call for Consensus Regarding Selecting
>Recommended Audio Codecs
>
>WG,
>
>________________________________________________________________________
>_________________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>exploites ou copies sans autorisation. Si vous avez recu ce message par
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
>pieces jointes. Les messages electroniques etant susceptibles
>d'alteration, France Telecom - Orange decline toute responsabilite si ce
>message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be
>distributed, used or copied without authorisation.
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>

---

From: Andrew Allen <[email-masked]>
Date: Sat, 12 Jan 2013 18:52:48 +0000

I really still don't see what the value is as part of RTCweb in describing the other codecs that are used by other VoIP and audio over IP and other digital audio systems and the perceived pros and cons of each.

This information is commonly available - just type codecs on wikipedia and you will get a large list of many of the commonly used audio codecs and where they are used and what the perceived royalty situation is. For the real information you will have to go to the organisations that specify the codecs in any case.

I think it should be obvious that if the device is a 3GPP mobile device then it will also support the 3GPP codecs and IETF doesn't need to tell RTCweb implementors that. It should also be obvious that if you want to interoperate without transcoding with 3GPP devices then you should take a look at the 3GPP codec specifications.

I don't think IETF and certainly not RTCweb should embark on duplicating information that is available elsewhere from the organisations that own and have the expertise on those codecs. Any information documented in IETF on this even if accurate to begin with is likely to become rapidly out dated as new codecs are developed and as patents expire. 

Also I doubt very much this will end up being limited to just AMR-NB, AMR-WB and G.722. Once we go down the path of saying RTCweb is going to document the other codecs that implementations should consider supporting for optimal interoperability I expect many more wil be added to the list as most of the codecs still in use have legacy terminals in some deployment somewhere that someone will think it is a good idea to interoperate with. I think this will get out of hand and either will become a long list of codecs or become a huge discussion about which are important and which are not. 

I think this is a waste of time and a distraction from solving the real interoperability issues like agreeing a common video codec and making sure JSEP and SIP/SDP interoperate well together.

I think its enough in RTCweb just to state that for best interoperability also supporting additional codecs commonly used in other deployments that there is a desire to interoperate with is a good thing in order to avoid the issues of transcoding. 

Then let implementors and the market decide which other codecs are important to implement.

Andrew

----- Original Message -----
From: Hutton, Andrew [mailto:[email-masked]]
Sent: Friday, January 04, 2013 04:47 AM Central Standard Time
To: Andrew Allen; Harald Alvestrand <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Regards
Andy

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 12 Jan 2013 12:24:12 -0800

> I really still don't see what the value is as part of RTCweb in describing the other codecs that are used by other VoIP and audio over IP and other digital audio systems and the perceived pros and…

[BA] I agree. 

> I think this is a waste of time and a distraction from solving the real interoperability issues like agreeing a common video codec and making sure JSEP and SIP/SDP interoperate well together.

[BA] Also agree that the WG can better spend its time on other things. 

Onn reviewing the RFC 2119 definition and previous uses, I agree with Adam that the threshold for SHOULD is not met here: 

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.Since we have already mandated support for G.711 and OPUS,  other audio codecs such as G.722 are more "might be useful in some circumstances" category rather than the "full implications must be understood" if not implementing.  That's not a SHOULD, it's a MAY.  If we are only talking about a MAY there is little point in devoting time to the issue, since every codec other than G.711 and OPUS would fall into that category.  I especially would not want to delay publication of documents while we haggle about the text to be associated with various  codecs. 

Count me in favor of Option 2.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 13 Jan 2013 08:57:05 +0000

Hi,

I agree with Bernard's position here. Describing other codecs than the mandatory ones with their pros and cons will not progress implementations or adoption of RTCWeb. This will just confuse and complicate codec negotiation (codec order etc) and will slow down the adoption of the mandatory codecs which already reached the WG consensus.

I support option 2.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Saturday, January 12, 2013 10:24 PM
To: Andrew Allen; [email-masked]; [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

[BA] I agree.

   carefully weighed before choosing a different course.
Since we have already mandated support for G.711 and OPUS,  other audio codecs such as G.722 are more "might be useful in some circumstances" category rather than the "full implications must be understood" if not implementing.  That's not a SHOULD, it's a MAY.  If we are only talking about a MAY there is little point in devoting time to the issue, since every codec other than G.711 and OPUS would fall into that category.  I especially would not want to delay publication of documents while we haggle about the text to be associated with various  codecs.

---

From: Shida Schubert <[email-masked]>
Date: Sun, 13 Jan 2013 11:34:36 -1000

+1

---

From: <[email-masked]>
Date: Mon, 14 Jan 2013 09:21:13 +0100

I also support Stephane's proposal.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Shida Schubert
> Gesendet: Sonntag, 13. Januar 2013 22:35
> An: Paul Coverdale
> Cc: [email-masked]
> Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting
> Recommended Audio Codecs
>
>
> +1
>
> > particularly for the case where AMR and AMR-WB are already
> implemented
> > in mobile devices - there are no additional licensing issues and it
> > simplifies interoperability.
> >
> > ...Paul
> >
> >> Behalf Of [email-masked]
> >> It is clear from the discussions on the rtcweb e-mail
> reflector that
> >> the only additional codecs to be considered are limited to the
> >> following very small subset of 3 codecs: AMR, AMR-WB and G.722.
> >> dedicated to voice services. They are consequently needed and
> >> sufficient to be supported by WebRTC to make it an attractive and
> >> future proof technology for usage in all environments including
> >> mobile and for interoperability use cases with most of all
> legacy voice terminals.
> >>
> >> from WebRTC was the licensing issue, there is no reason to NOT
> >> support AMR-WB and AMR at WebRTC level if these codecs are already
> >> implemented on the device.
> >>
> >> Therefore I support option 1 and propose the following
> specification
> >> according this:
> >> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC
> >> end-points AMR and AMR-WB MUST BE supported at WebRTC
> level by WebRTC
> >> end-points on 3GPP mobile devices already implementing AMR
> and AMR-WB
> >> (*)
> >>
> >> De : [email-masked]
> [mailto:[email-masked]] De la
> >> part de Magnus Westerlund Envoyé : jeudi 20 décembre 2012 09:30 À :
> >> [email-masked] Objet : [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.
> >>
> >> audio/speech codecs that would be RECOMMNEDED to implement by a
> >> WebRTC end-points
> >>
> >> - Multimedia Technologies, Ericsson Research EAB/TVM
> >>
> _____________________________________________________________________
> >> ___ _________________________________________________
> >>
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender
> >> and delete this message and its attachments.

---

From: Tim Panton <[email-masked]>
Date: Mon, 14 Jan 2013 11:22:44 +0000

> (*) note that the way these codecs are supported at RTC Web level is left open to implementors: either by a WebRTC specific software implementation of these codecs or by using APIs to access hardwa…

I'm against this sort of statement in general, it only serves to fragment the webRTC landscape.

If we do end up making this sort of statement it needs to say:

"AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points on 3GPP mobile devices already implementing AMR and AMR-WB provided no additional license or agreements are needed for their use in this way."

The point being that just because the codec is in the silicon, it does not mean it is licensed for just any use, the license may be limited by channel count or direction. (I've seen phones where AMR decode is permitted but not encode).

I strongly encourage anyone who wants to mandate g722 to make a call over 722 from their laptop in starbucks before dragging rtcWEB back a decade or two.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 06:29:31 -0500

On Mon, Jan 14, 2013 at 6:22 AM, Tim Panton <[email-masked]> wrote:

> I strongly encourage anyone who wants to mandate g722 to make a call over
> 722 from their laptop in starbucks before dragging rtcWEB back a decade or
> two.

I am doing this regularly. With good jitter buffer and PLC implementation
it sounds great.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jan 2013 06:34:34 -0800

Stephane said:

"In addition to G.711, these 3 codecs cover almost all legacy devices dedicated to voice services. They are consequently needed and sufficient to be supported by WebRTC to make it an attractive and future proof technology"

[BA] The use of the terms "legacy" and "future proof" here is puzzling.   "Future proof" would seem to imply the ability to adapt to future developments, whereas "legacy" relates to compatibility with what has gone before.   Unless the "past" is the same as the "future" (which implies no progress at all), those two objectives are distinct (and possibly conflicting).

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2013 09:00:39 -0600

This thread has been going on for quite some time now, and I wouldn't be 
surprised if there is some pressure for the chairs to call consensus in 
the next week or two.

I know it's tempting to think they might simply grab the relevant 
messages and tally the support for each position, calling the issue for 
those with the larger number of proponents. In short, simple majority 
voting. Many bodies work this way -- governments, corporations, and 
other SDOs, just to name a few.

We don't.

As Dave Crocker[1] is fond of pointing out, it is possible to have 99 
people in support of a position and one standing against, and still fail 
to meet the IETF's standard for "rough consensus." All it takes is the 
failure of those 99 people to engage the arguments put forth by the one 
outlier. Correspondingly, you can have 50 people on one side of an 
issue, 50 on the other, and still have a clear consensus if one side is 
merely stating a position, while the other is offering up unanswered 
arguments.

To be clear, I'm not saying that "+1" is never a valid response when 
attempting to reach consensus. However, it does not, in and of itself, 
comprise a counter-argument to points raised by supporters of the 
opposing position.

To the issue at hand: roughly grouping those proponents of option 1 into 
one voice (A), and those boosting option 2 in to another (B), the 
conversation so far can be roughly summarized as:

A: We'd like to see SHOULD-level support for codecs x, y, and/or z 
because gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
A: *crickets*

[time passes]

A: We'd like to see SHOULD-level support for codecs x, y, and/or z 
because gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
A: *crickets*

That's the _exact_ kind of failure to engage that I would expect would 
cause experienced chairs to call clear consensus for supporters of option 2.

This isn't a vote, it's a discussion, and discussions need to go beyond 
blindly repeating your opening arguments. If you have any interest in 
option 1 being considered further, you need to listen and respond to the 
opposing position.

/a

[1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, 
I call your attention to the date and attendee list on the following 
proceedings: http://www.ietf.org/proceedings/04.pdf

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 10:21:09 -0500

I know that I would sound like I am repeating myself, but my initial
argument was that in order to interoperate with majority of legacy HD Audio
deployments without transcoding WebRTC implementations SHOULD support
G.722. The main argument that I heard against this was that
interoperability with legacy is not a justification enough for a SHOULD.
Other arguments, such as that OPUS is better sounding and more resilient to
packet loss then G.722 are irrelevant since it was never argued this way.
The fact that the list of supported codecs in 5-10 years will change
drastically is also not very relevant, since the specification can be
updated to reflect this in the future. So the only thing that we have to
discuss here is if interop deserves a SHOULD or should we just assume that
implementers will do the right thing. To be honest all I've heard so far
(and unfortunately I realize that this applies to some degree to my own
argument) was that people feel one way or the other, which is not very
helpful in reaching consensus.
_____________
Roman Shpount

On Mon, Jan 14, 2013 at 10:00 AM, Adam Roach <[email-masked]> wrote:

> surprised if there is some pressure for the chairs to call consensus in the
> next week or two.
>
> I know it's tempting to think they might simply grab the relevant messages
> and tally the support for each position, calling the issue for those with
> the larger number of proponents. In short, simple majority voting. Many
> bodies work this way -- governments, corporations, and other SDOs, just to
> name a few.
>
> We don't.
>
> people in support of a position and one standing against, and still fail to
> meet the IETF's standard for "rough consensus." All it takes is the failure
> of those 99 people to engage the arguments put forth by the one outlier.
> Correspondingly, you can have 50 people on one side of an issue, 50 on the
> other, and still have a clear consensus if one side is merely stating a
> position, while the other is offering up unanswered arguments.
>
> comprise a counter-argument to points raised by supporters of the opposing
> position.
>
> A: We'd like to see SHOULD-level support for codecs x, y, and/or z because
> gee, wouldn't it be nice?
> A: We'd like to see SHOULD-level support for codecs x, y, and/or z because
> gee, wouldn't it be nice?
> [1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, I
> call your attention to the date and attendee list on the following
> proceedings: http://www.ietf.org/**proceedings/04.pdf<http://www.ietf.org/proceedings/04.pdf>
>
>
>>> Von: [email-masked] [mailto:rtcweb-bounces@ietf.**org<[email-masked]>
>>> ]
>>>>> From: [email-masked] [mailto:rtcweb-bounces@ietf.**org<[email-masked]>]
>>>>> On
>>>>> In addition to G.711, these 3 codecs cover almost all
>>>>>
>>>> legacy devices
>>>
>>>> AMR and AMR-WB are indeed the most widely supported voice
>>>>>
>>>> codecs in
>>>
>>>>> G.722 is royalty free (including a Packet Loss Concealment
>>>>>
>>>> solution
>>>
>>>> provided in ITU-T Software Tool Library) and is the codec
>>>>>
>>>> used for HD
>>>
>>>>> Furthermore, considering that the reason for excluding AMR
>>>>>
>>>> and AMR-WB
>>>
>>>>> (*) note that the way these codecs are supported at RTC
>>>>>
>>>> Web level is
>>>
>>>> [mailto:rtcweb-bounces@ietf.**org <[email-masked]>] De la
>>>
>>>>> As an outcome of the Vancouver IETF meeting codec
>>>>>
>>>> discussions we did
>>>
>>>>> Audio codecs be the only audio codecs mentioned in the
>>>>>
>>>> WebRTC specification.
>>>
>>>>>  ------------------------------**------------------------------**
>>> ---------
>>>
>>>>>  ------------------------------**------------------------------**
>>> ----------
>>>
>>>>>  ------------------------------**------------------------------**
>>> ---------
>>>
>>>> -
>>>>>
>>>>> ______________________________**_________________
>>>>> rtcweb mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>>
>>>>>
>>>>>  ______________________________**______________________________**
>>> _________
>>>
>>>> ___ ______________________________**___________________
>>>>>
>>>>> confidentielles ou privilegiees et ne doivent donc pas
>>>>>
>>>> etre diffuses,
>>>
>>>>> As emails may be altered, France Telecom - Orange is not
>>>>>
>>>> liable for
>>>
>>>>> ______________________________**_________________
>>>>> rtcweb mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>>
>>>> ______________________________**_________________
>>>> rtcweb mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>
>>> ______________________________**_________________
>>> rtcweb mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>
>>>  ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Tim Panton <[email-masked]>
Date: Mon, 14 Jan 2013 15:54:54 +0000

On 14 Jan 2013, at 15:21, Roman Shpount wrote:

> I know that I would sound like I am repeating myself, but my initial argument was that in order to interoperate with majority of legacy HD Audio deployments without transcoding WebRTC implementations SHOULD support G.722. The main argument that I heard against this was that interoperability with legacy is not a justification enough for a SHOULD. 

It's slightly more nuanced than that. More like:  "the additional ease of interoperability with legacy is not a justification enough for a SHOULD" .

Even without 722 we can interop with legacy HD , just not as easily - is that added convenience enough to justify the SHOULD? Conversely 
having 722 doesn't solve the whole interop problem, which further reduces the 'win' from adding it.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 11:07:28 -0500

On Mon, Jan 14, 2013 at 10:54 AM, Tim Panton <[email-masked]> wrote:

> It's slightly more nuanced than that. More like:  "the additional ease of
> interoperability with legacy is not a justification enough for a SHOULD" .
>
> Even without 722 we can interop with legacy HD , just not as easily - is
> that added convenience enough to justify the SHOULD? Conversely

To follow this more nuanced approach, would cost of transcoding from OPUS
to G.722 (or other codecs) justify a SHOULD? G.722 is very cheap to
transcode to/from. I know that I can build a gateway that handles SRTP
encryption and responds to all the ICE messages with density of few
thousand channels per modern server CPU. I am not sure I can do this in
combination with OPUS to G.722 transcoding.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Mon, 14 Jan 2013 16:26:15 +0000

On 14 Jan 2013, at 16:07, Roman Shpount wrote:

> To follow this more nuanced approach, would cost of transcoding from OPUS to G.722 (or other codecs) justify a SHOULD? G.722 is very cheap to transcode to/from. I know that I can build a gateway that handles SRTP encryption and responds to all the ICE messages with density of few thousand channels per modern server CPU. I am not sure I can do this in combination with OPUS to G.722 transcoding.

Probably not. Is it worth a SHOULD ? I suppose that depends on how important we collectively feel that use-case to be.

I could live with a SHOULD on 722 - provided that it MUST  include a PLC (assuming a royalty free one exists)
and MUST be offered at a lower priority than Opus. 

T.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 11:31:46 -0500

> and MUST be offered at a lower priority than Opus.

I would agree with this as well, except that I would suggest that all
supported audio codecs SHOULD include PLC.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2013 11:05:14 -0600

On 1/14/13 09:21, Roman Shpount wrote:
> argument was that in order to interoperate with majority of legacy HD 
> Audio deployments without transcoding WebRTC implementations SHOULD 
> support G.722. The main argument that I heard against this was that 

And I think that's what this question turns on.

> So the only thing that we have to discuss here is if interop deserves 
> a SHOULD or should we just assume that implementers will do the right 
> thing.

I make no assumptions. I propose guidance.

> To be honest all I've heard so far (and unfortunately I realize that 
> this applies to some degree to my own argument) was that people feel 
> one way or the other, which is not very helpful in reaching consensus.

What has been directly posed is the following form: given the RFC 2119 
definition of "SHOULD" below, do you earnestly believe that support of 
G.722 actually warrants this level of specification:

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

So far, no one has come forth and said anything equivalent to "yes, I 
believe that the severity implied by the RFC 2119 definition of 'SHOULD' 
is appropriate for G.722 (or AMR/AMR-WB) support."

I suspect the reason is that anyone who follows the passage I quote 
above with such a claim realizes that they'll look a little out of touch 
with reality by doing so.

/a

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 14 Jan 2013 12:05:20 -0500

On 01/14/2013 11:31 AM, Roman Shpount wrote:
> I would agree with this as well, except that I would suggest that
> all supported audio codecs SHOULD include PLC.

"SHOULD include a PLC" only makes sense if you specify minimum quality
requirements. Otherwise "repeat previous packet" or "fill with zeros"
all count as PLC. Personally, I really don't feel like getting into a
PLC quality spec.

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 13:00:54 -0500

> G.722 actually warrants this level of specification:

I actually believe that G.722 warrants an RFC 2119 MUST, but this was voted
against with the main reason (at least from my point of view) being desire
to promote OPUS. I do agree that webrtc should express its preference for
OPUS, but I do not see what valid reasons or circumstances can exist that
will prevent G.722 implementation. I think that interoperability is a valid
enough reason that G.722 support should be required.

_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2013 12:14:08 -0600

On 1/14/13 12:00, Roman Shpount wrote:
> I think that interoperability is a valid enough reason that G.722 
> support should be required.

Interoperability with G.722 is not just possible without such a 
requirement; it's already implemented:

http://code.google.com/p/webrtc2sip/#Media_Coder

You vastly overstate your case when you claim that G.722 support in 
WebRTC clients is *required* to interwork with some legacy clients. The 
facts on the ground are that such support simply makes it easier. It 
really is a "gee, wouldn't it be nice" feature.

And that is *way* outside what we use "SHOULD" for.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Jan 2013 19:37:13 +0100

On 01/14/2013 04:00 PM, Adam Roach wrote:
> This thread has been going on for quite some time now, and I wouldn't 
> be surprised if there is some pressure for the chairs to call 
> consensus in the next week or two.
>
> messages and tally the support for each position, calling the issue 
> for those with the larger number of proponents. In short, simple 
> majority voting. Many bodies work this way -- governments, 
> corporations, and other SDOs, just to name a few.
>
> We don't.
While agreeing with your general point......
I do like to list (not count; list gives you not only the numbers, but 
the names, which is much more information) the proponents of each side, 
and look at the length of the lists as well as the names on it.

What this often tells me is "there's no way in hell we're ever going to 
come to consensus on A, but there is a chance that we could declare 
rough consensus on B, and people will be living to live with it".

The result is often suspiciously like what happens with vote counting, 
but the logic is slightly different.
But all this is advice to the chairs when their announced period of 
consensus call ends in 2 days.
It's really up to them.

           Harald

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 13:51:45 -0500

On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach <[email-masked]> wrote:

> You vastly overstate your case when you claim that G.722 support in WebRTC
> clients is *required* to interwork with some legacy clients. The facts on
> the ground are that such support simply makes it easier. It really is a
> "gee, wouldn't it be nice" feature.
>

The question is the question of cost of transcoding. It is not
insignificant or not a simple "gee, wouldn't it be nice". As I've mentioned
earlier it is possible to build a media gateway that will handle encryption
and ICE with the density of a few thousand calls per server CPU. It would
not be possible if G.722 to OPUS transcoding is required. So, the argument
to support G.722 is that it removes the need for transcoding (and
subsequently need for jitter buffering, which introduces delays and
requires even more resources on the media gateway). What is the argument
against it?

_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2013 13:50:55 -0600

On 1/14/13 12:51, Roman Shpount wrote:
>
> On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     You vastly overstate your case when you claim that G.722 support
>     in WebRTC clients is *required* to interwork with some legacy
>     clients. The facts on the ground are that such support simply
>     makes it easier. It really is a "gee, wouldn't it be nice" feature.
>
>
> insignificant or not a simple "gee, wouldn't it be nice". As I've 
> mentioned earlier it is possible to build a media gateway that will 
> handle encryption and ICE with the density of a few thousand calls per 
> server CPU. It would not be possible if G.722 to OPUS transcoding is 
> required.

Not only do I agree; I've actually made very similar (and related) 
points: <http://www.ietf.org/mail-archive/web/rtcweb/current/msg06013.html>

> So, the argument to support G.722 is that it removes the need for 
> transcoding (and subsequently need for jitter buffering, which 
> introduces delays and requires even more resources on the media gateway).

I think we agree more than we disagree. The distinction to make is that 
I believe that implementations would benefit from supporting G.722, 
while you think they SHOULD (RFC 2119 term) support G.722.

> What is the argument against it?

I am not making an argument supporting G.722 per se, and I think its 
merits and/or drawbacks are red herrings in this conversation. The 
argument is against *normatively* specifying support of *any* additional 
codecs. I don't think it was a good idea to have 2 MTIs to start with. A 
single MTI gets us interop. Anything beyond that rises to the level of 
"MAY," and no higher.

I would be making the exact same set of arguments if G.722 were MTI, and 
the ongoing discussion were on whether Opus "SHOULD be supported."

/a

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2013 15:15:00 -0500

On Mon, Jan 14, 2013 at 2:50 PM, Adam Roach <[email-masked]> wrote:

> merits and/or drawbacks are red herrings in this conversation. The argument
> is against *normatively* specifying support of *any* additional codecs. I
> don't think it was a good idea to have 2 MTIs to start with. A single MTI
> gets us interop. Anything beyond that rises to the level of "MAY," and no
> higher.
>

We already have two MTI OPUS and G.711. From my point of view OPUS gets us
all the future end points; G.711 gets us PSTN; and G.722 would get us
legacy HD Audio.

AMR-WB (as well as AMR and GSM) from my point of view deserve some mention
in the specification but do not warrant a SHOULD. AMR-WB would be nice to
have to connect to mobile networks but there are serious IPR related issues
preventing its support. Furthermore, even though AMR-WB is supported by a
significant number mobile phones, AMR-WB network interconnects are
virtually non-existent, so, from practical point of view, support for this
codecs is a lot less critical.
_____________
Roman Shpount

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 15 Jan 2013 15:48:12 +0100

> Please indicate your position by January 16th 2013.

I see the following important reasons for creating a RECOMMENDED category:

1. interoperability without quality degradations due to transcoding with 
large installed legacy and existing services.
   Typical examples are interconnection cases to major mobile or fixed 
communication systems. Clearly interop with 3GPP voice services and HD 
Voice in 3GPP and fixed networks is very important. The option with 
transcoding should be avoided as - besides the equipment costs - it is 
affecting the communication quality in terms of more coding distortions 
and delay.

2. take advantage of deep codec specific integrations/optimizations.
   Typical examples are interconnection cases to major mobile systems 
which bearers are highly optimized for a given codec specified for these 
systems. For these systems operating with their 'native' codecs is 
beneficial not only in terms of system capacity and efficiency but also 
from end-user perspective as it will allow least battery consumption in 
the mobile devices (due to that hardware implementations for the codecs 
are often used) and provide best robustness/coverage. At least interop 
to such native codecs in 3GPP mobile networks is essential. This point 
partly overlaps with the previous but also covers cases where new codecs 
will get a deep system integration. The alternative with transcoding in 
a GW should be avoided for the reasons given above (avoiding extra 
distortions and delay).

3. future-proofness of specifications allowing to recommend new codecs 
that turn out to be better/more efficient than existing mandatory codecs.
   As history has proven, even the best mandatory codec has a 
best-before date. We should foresee the possibility to at least 
recommend such a better codec at some stage when felt appropriate.

At the same time, when creating a RECOMMENDED category, I think that it 
should be strictly limited to very few codecs only. At present I see a 
reasonable limit of 3 recommended codecs related to particular interop 
scenarios. However, this number could be increased if new and better 
codecs are deemed would in the future enter this category.

So, my vote goes for option 1.

Stefan

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Jan 2013 18:40:10 +0100

From: [email-masked] on behalf of ext Roman Shpount

>	I am not making an argument supporting G.722 per se, and I think
its merits and/or drawbacks are red herrings in this conversation. The
argument is against *normatively* specifying support of *any* additional
codecs. I don't think it was a good idea to have 2 MTIs to start with. A
single MTI gets us interop. Anything beyond that rises to the level of
"MAY," and no higher.
>	
>	I would be making the exact same set of arguments if G.722 were
MTI, and the ongoing discussion were on whether Opus "SHOULD be
supported."
>
>
> We already have two MTI OPUS and G.711. From my point of view OPUS
gets us all the future end points; G.711 gets us PSTN; and G.722 would
get us legacy HD Audio.
>
> AMR-WB (as well as AMR and GSM) from my point of view deserve some
mention in the specification but do not warrant a SHOULD. AMR-WB would
be nice to have to connect to mobile networks but there are serious IPR
related issues preventing its support. Furthermore, even though AMR-WB
is supported by a significant number mobile phones, AMR-WB network
interconnects are virtually non-existent, so, from practical point of
view, support for this codecs is a lot less critical.

I do see AMR / AMR-WB at the same level as G.722 - to support
interoperability with legacy networks without the need for transcoding.
I believe saving transcoding cycles is important for the success of
RTCWeb, as it allows building bridges to the legacy world of real-time
communications (i.e. fixed and mobile communication networks) at a
reasonable cost. Hence, I consider it not just "nice to have".

It may be true that the G.711 is most widespread today at NNI interfaces
due to the PSTN legacy and support in the fixed network world, but SIP
NNI interfaces are only now being rolled out, and as codec negotiation
is an integral part of SIP, I do expect that they will support multiple
codecs (at least in the medium term). 

More or less all of today's mobile phones support AMR-WB. If we can
connect to them and support AMR-WB, transcoding won't be needed for
getting HD audio from mobiles. G.722 is not available in mobile phones.
If the WebRTC gateway connects directly to the mobile core network (be
it VoIP-based or circuit switched), then the network interconnects
mentioned above are not even needed, and AMR/AMR-WB audio can be passed
through directly. 

To support the deployment scenarios related to mobile networks, I
propose to include a recommendation for AMR/AMR-WB, i.e. I prefer option
1. 
Details of how to exactly do the recommendation can be worked out in the
process.   

Kind regards,
Uwe Rauschenbach

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 15 Jan 2013 12:55:49 -0500

On 01/15/2013 09:48 AM, Stefan H￥kansson LK wrote:
> 1. interoperability without quality degradations due to transcoding
> with large installed legacy and existing services. Typical examples
> are interconnection cases to major mobile or fixed communication
> systems. Clearly interop with 3GPP voice services and HD Voice in
> 3GPP and fixed networks is very important. The option with 
> transcoding should be avoided as - besides the equipment costs - it
> is affecting the communication quality in terms of more coding
> distortions and delay.

I'm still in favor of Option 2 (no SHOULD), but if we had to pick a
codec for legacy interop, I think Speex would be a good candidate.
It's included in Flash 10 and up, which is currently installed
(according to Adobe) on 500 million machines. This could provide
WebRTC interop for all the users who don't have a WebRTC-capable browser.

	Jean-Marc

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jan 2013 13:00:28 -0600

> Details of how to exactly do the recommendation can be worked out in the

I think what's getting lost here is whether people think these codecs 
should be "recommended" (English word, consult your dictionary) or 
"RECOMMENDED" (unfortunate IETF-specific term of art, consult RFC 2119).

I agree with the former sentiment, but completely disagree with the latter.

Which are you supporting?

/a

---

From: "Flynn, Gerry J" <[email-masked]>
Date: Wed, 16 Jan 2013 12:36:23 -0500

Dear Colleagues

It has been challenging to absorb all the excellent ideas and inputs aiming to reach consensus around one of the two proposed options as there are valid considerations for each.  A degree of compromise is encouraged with recognition of the extensive current and future deployment of AMR and AMR-WB as well as the need for interoperability with new audio codecs and minimization of transcoding.  As such, Verizon endorses the e-mail by Magnus and supports option 1.

Gerry Flynn
Verizon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Håkansson LK
Sent: Tuesday, January 15, 2013 9:48 AM
To: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

1. interoperability without quality degradations due to transcoding with large installed legacy and existing services.
   Typical examples are interconnection cases to major mobile or fixed communication systems. Clearly interop with 3GPP voice services and HD Voice in 3GPP and fixed networks is very important. The option with transcoding should be avoided as - besides the equipment costs - it is affecting the communication quality in terms of more coding distortions and delay.

2. take advantage of deep codec specific integrations/optimizations.
   Typical examples are interconnection cases to major mobile systems which bearers are highly optimized for a given codec specified for these systems. For these systems operating with their 'native' codecs is beneficial not only in terms of system capacity and efficiency but also from end-user perspective as it will allow least battery consumption in the mobile devices (due to that hardware implementations for the codecs are often used) and provide best robustness/coverage. At least interop to such native codecs in 3GPP mobile networks is essential. This point partly overlaps with the previous but also covers cases where new codecs will get a deep system integration. The alternative with transcoding in a GW should be avoided for the reasons given above (avoiding extra distortions and delay).

3. future-proofness of specifications allowing to recommend new codecs that turn out to be better/more efficient than existing mandatory codecs.
   As history has proven, even the best mandatory codec has a best-before date. We should foresee the possibility to at least recommend such a better codec at some stage when felt appropriate.

At the same time, when creating a RECOMMENDED category, I think that it should be strictly limited to very few codecs only. At present I see a reasonable limit of 3 recommended codecs related to particular interop scenarios. However, this number could be increased if new and better codecs are deemed would in the future enter this category.

Stefan

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 16 Jan 2013 22:34:57 +0100

> From: ext Adam Roach [mailto:[email-masked]]
>

I want to make the point that w.r.t. easy interworking with legacy telephony clients, there's value in writing spec text that guides developers w.r.t. additional non-MTI audio codecs.

Being aware that there seem to be concerns regarding the use of RFC 2119 terminology for that, I suggest that we take this in two steps:
        1) get consensus to produce spec text for the inclusion of additional non-MTI audio codecs (such as AMR, AMR-WB, G.722),
        2) subsequently, work out whether we "RECOMMEND" or "recommend" these codecs.

Kind regards,
Uwe

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2013 16:03:38 -0800

On 15 January 2013 11:00, Adam Roach <[email-masked]> wrote:
> what's getting lost here is whether people think these codecs should be
> "recommended" (English word, consult your dictionary) or "RECOMMENDED"
> (unfortunate IETF-specific term of art, consult RFC 2119).

Since Adam is having so much luck, I'd like to get a clearer answer to
this questions from the proponents of the 2119 SHOULD:

If we don't say "webrtc implementations SHOULD implement
G.722/AMR/AMR-WB", what is the failure mode for your application?
Keeping in mind that - because this isn't 2119 MUST - you have to
expect that some non-negligible proportion of clients will not support
this no matter how much extra ink we using in printing large letters,
how much pain does this really cause you?

I expect that the transcoding costs are what this come down to.  Does
anyone care to quantify this?

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 17 Jan 2013 00:24:22 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson

> Since Adam is having so much luck, I'd like to get a clearer answer to this questions from the proponents of the 2119 SHOULD:

> If we don't say "webrtc implementations SHOULD implement G.722/AMR/AMR-WB", what is the failure mode for your application?
> Keeping in mind that - because this isn't 2119 MUST - you have to expect that some non-negligible proportion of clients will not support this no matter how
> much extra ink we using in printing large letters, how much pain does this really cause you?

Actually, as there's only a small finite number of browser vendors, all of them with their own constraints about which codecs they can/will include, and several of them will ship before the spec is anywhere near final either here or in W3C, it wouldn't matter even if it *was* a 2119 MUST, would it?

Matthew Kaufman

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 17 Jan 2013 01:27:13 +0100

I do not think transcoding is the only issue.

If you refer back to the earlier mail from Stephane, there was also the point, which I agree with, that if you have a licensed version of any codec on your device, ideally you want your browser to support that codec. You don't want to be told that you cannot talk to another user who only has codec B, when you have already paid the license fee to use codec B, just because your browser vendor decides it is not its favourite codec.

There are an awful lot of licensed AMR codecs out there that people still want to use.

Regards

Keith

> Of Martin Thomson
> Sent: 17 January 2013 00:04
> To: Adam Roach
> Cc: [email-masked]
> Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
> Regarding Selecting Recommended Audio Codecs)
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2013 16:38:54 -0800

On 16 January 2013 16:27, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> there was also the point, which I agree with, that if you have a licensed version of any codec on your device, ideally you want your browser to support that codec

I think that misses the point of my question.  I asked about what
specifically do you consider to be the cost of this particular
failure?  However much we might want these things to not happen, I
want to know what the consequences are.

As Matthew observes, even MUST might be insufficient to convince an
implementation to support a codec because the most effective (and
perhaps only) way to convince someone to implement something is to
show that it increases ROI.

So, I want to know the cost that you incur if this is not SHOULD.
Ideally, what fails to interoperate in this scenario?

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Jan 2013 20:27:58 -0600

> If you refer back to the earlier mail from Stephane, there was also the point, which I agree with, that if you have a licensed version of any codec on your device, ideally you want your browser to…

That's not an argument for "implementations SHOULD implement codec X," 
which is the question at hand (where X is a set of one or more specific, 
named codecs).

What you're putting forth is a vaguely related argument for 
"implementations SHOULD make use of all codecs provided by the 
underlying platform on which they are deployed." But that's a very 
different question.

And, to be clear, if the other device that you're talking to "only has 
codec B," where B is not "the set of both G.711 and Opus," then we're 
already wandering off into the realm of fully non-compliant implementations.

/a

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Jan 2013 05:31:44 -0500

> anyone care to quantify this?

If common codecs are not implemented in the browser this would mean
transcoding will need to be performed on some sort of server-side media
gateway. There are three distinct issues we need to take into account when
dealing with transcoding. I would list them in what, at least from my point
of view, is the order of importance:

1. If you need to do trancoding, you will need to implement a jitter buffer
on the transcoding media gateway. ICE processing and SRTP en/decoding can
be performed on out of order packets as they are received. You cannot
transcode out of order audio. This means audio packets would need to be
delayed by the jitter buffer size. In cases of good internet connection
this means 40 ms jitter buffer delay. In cases of consumer internet in US
(somebody sitting on a DSL connection at home behind a WiFi router) you are
typically looking at 60-80 ms jitter buffer delay. If you are dealing with
international internet connections jitter of 150 ms to 200 ms is not
unheard of. This means an additional delay due to jitter buffering of 40 ms
(best case) to 200 ms. This is in addition to any other delays that are
already present on the audio path. Adding an extra 100 ms of delay can make
audio conversions very awkward or unusable. On the other hand, if the
gateway were performing just ICE and SRTP, it would introduce 1-2 ms of
delay at most (In this case I am talking about a software based
implementation running on generic server hardware. A dedicated DSP solution
would probably be even faster).

2. Audio artifacts due to transcoding. Apart from usual audio degradation
due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or
AMR), we would also deal with double packet loss concealment. Media gateway
will conceal lost packets when transcoding. Client will conceal lost packet
received from the gateway. This would actually sound worse then PLC
performed in one place.

3. Scalability of the transcoding gateway. Gateway which just deals with
ICE processing and SRTP en/decoding can handle from 2000 to 10000
concurrent call when running on a generic server CPU (different scalability
is due to differences in CPU performance and presence of AES specific
instructions). Gateway that would do G.722 to OPUS transcoding would most
likely handle from 500 to 1000 concurrent calls. We are looking at 10x
difference in performance. If we need to transcode AMR to OPUS the
difference would be even higher. This translates in 10x difference in
hardware, data center, power, and operations costs.
_____________
Roman Shpount

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Thu, 17 Jan 2013 12:13:50 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Hi, all:

A good assessment - thanks to Roman. 

So, the transcoding cost is enormous from both performance and HW/SW
implementation point of view.

In the end it may so appear that we are not hearing each other.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roman Shpount
Sent: Thursday, January 17, 2013 5:32 AM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs)

On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <[email-masked]>
wrote:

	If we don't say "webrtc implementations SHOULD implement
	G.722/AMR/AMR-WB", what is the failure mode for your application?
	Keeping in mind that - because this isn't 2119 MUST - you have to
	expect that some non-negligible proportion of clients will not
support
	this no matter how much extra ink we using in printing large
letters,
	how much pain does this really cause you?
	
	I expect that the transcoding costs are what this come down to.
Does
	anyone care to quantify this?

1. If you need to do trancoding, you will need to implement a jitter buffer
on the transcoding media gateway. ICE processing and SRTP en/decoding can be
performed on out of order packets as they are received. You cannot transcode
out of order audio. This means audio packets would need to be delayed by the
jitter buffer size. In cases of good internet connection this means 40 ms
jitter buffer delay. In cases of consumer internet in US (somebody sitting
on a DSL connection at home behind a WiFi router) you are typically looking
at 60-80 ms jitter buffer delay. If you are dealing with international
internet connections jitter of 150 ms to 200 ms is not unheard of. This
means an additional delay due to jitter buffering of 40 ms (best case) to
200 ms. This is in addition to any other delays that are already present on
the audio path. Adding an extra 100 ms of delay can make audio conversions
very awkward or unusable. On the other hand, if the gateway were performing
just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case
I am talking about a software based implementation running on generic server
hardware. A dedicated DSP solution would probably be even faster).

3. Scalability of the transcoding gateway. Gateway which just deals with ICE
processing and SRTP en/decoding can handle from 2000 to 10000 concurrent
call when running on a generic server CPU (different scalability is due to
differences in CPU performance and presence of AES specific instructions).
Gateway that would do G.722 to OPUS transcoding would most likely handle
from 500 to 1000 concurrent calls. We are looking at 10x difference in
performance. If we need to transcode AMR to OPUS the difference would be
even higher. This translates in 10x difference in hardware, data center,
power, and operations costs.

_____________
Roman Shpount

Classification: UNCLASSIFIED
Caveats: NONE

---

From: Andrew Allen <[email-masked]>
Date: Thu, 17 Jan 2013 12:54:03 +0000

As I recall during the MTI discussion it was claimed that OPUS was intended for interoperability between RTCweb endoints and G.711 for interoperability with legacy. That's why we selected 2 MTI Codecs.

Transcoding between G.711 and something else like G.722 will not have anything like the transcoding cost as between OPUS and G.722 - basically the complexity of a media gateway.  Of course you will not get the full fidelity of either OPUS or G.722 but basic audio communications will work fine which is all I think we can guarantee with legacy.

If platforms already have other codecs (such as AMR on mobile devices) that are usable by the browser then it makes perfect sense that they be included in the offer but I don't think IETF should start recommending other codecs to implement other than the 2 MTI. This should be left as product decisions based on commercial needs and not recommendations made by IETF the driver for which I suspect has more to do with the interests of some legacy products/deployments than those of RTCweb. 

Since almost every computing platform has a browser (including most mobile phones) within a few years every computing platform will have RTCweb and OPUS so the need for high fidelity legacy codec interoperability will I think become a mute point.

I think the inteoperability concerns should be more focussed on the video issue where we seem to have a real problem.

Andrew

----- Original Message -----
From: Roy, Radhika R CIV USARMY (US) [mailto:[email-masked]]
Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time
To: Roman Shpount <[email-masked]>; Martin Thomson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

Hi, all:

BR/Radhika

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

	

_____________
Roman Shpount

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 17 Jan 2013 14:14:08 +0100

On 2013-01-17 11:31, Roman Shpount wrote:
>
> On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> gateway. There are three distinct issues we need to take into account
> when dealing with transcoding. I would list them in what, at least from
> my point of view, is the order of importance:
>
> 1. If you need to do trancoding, you will need to implement a jitter
> buffer on the transcoding media gateway. ICE processing and SRTP
> en/decoding can be performed on out of order packets as they are
> received. You cannot transcode out of order audio. This means audio
> packets would need to be delayed by the jitter buffer size. In cases of
> good internet connection this means 40 ms jitter buffer delay. In cases
> of consumer internet in US (somebody sitting on a DSL connection at home
> behind a WiFi router) you are typically looking at 60-80 ms jitter
> buffer delay. If you are dealing with international internet connections
> jitter of 150 ms to 200 ms is not unheard of. This means an additional
> delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in
> addition to any other delays that are already present on the audio path.
> Adding an extra 100 ms of delay can make audio conversions very awkward
> or unusable. On the other hand, if the gateway were performing just ICE
> and SRTP, it would introduce 1-2 ms of delay at most (In this case I am
> talking about a software based implementation running on generic server
> 2. Audio artifacts due to transcoding. Apart from usual audio
> degradation due to transcoding (OPUS transcoded to AMR would sound worse
> then OPUS or AMR), we would also deal with double packet loss
> concealment. Media gateway will conceal lost packets when transcoding.
> Client will conceal lost packet received from the gateway. This would
> actually sound worse then PLC performed in one place.
>
> concurrent call when running on a generic server CPU (different
> scalability is due to differences in CPU performance and presence of AES
> specific instructions). Gateway that would do G.722 to OPUS transcoding
> would most likely handle from 500 to 1000 concurrent calls. We are
> looking at 10x difference in performance. If we need to transcode AMR to
> OPUS the difference would be even higher. This translates in 10x
> difference in hardware, data center, power, and operations costs.

This was a good summary. I'm mostly concerned with the quality 
degradations experienced by the end user and less about the cost (on the 
other hand, I guess this would in the end hit the end users as well).

I think having a 'SHOULD' for a few additional codecs would reduce the 
number of end users impacted by the degradations (and cost) mentioned, 
and I think that would make a lot of sense.

Stefan

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Jan 2013 14:16:49 +0100

> Behalf Of ext Andrew Allen
> 
> Since almost every computing platform has a browser (including most
> mobile phones) within a few years every computing platform will have
> RTCweb and OPUS so the need for high fidelity legacy codec
> interoperability will I think become a mute point.
> 
This is not the point. The use case is to enable a user of an RTCWeb
service to reach another user via the legacy telephone network, be it
mobile or fixed. The fact whether or not the browser on the mobile phone
is capable of RTCWeb is of no relevance for this use case, because it
may well be that the two call parties use different RTCWeb services with
no interconnection, and the only way to reach each other is via the
telephone network.

Kind regards,
Uwe

> Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)
> 
> Behalf Of
> <[email-masked]>
> wrote:
> 
> 
> when
> buffer
> degradation
> call when running on a generic server CPU (different scalability is
due
> to

---

From: Burger Eric <[email-masked]>
Date: Thu, 17 Jan 2013 08:17:29 -0500

So the argument here is the cost to the user is USD 0.0000001/call instead of USD 0.00000001/call?

On Jan 17, 2013, at 8:14 AM, Stefan Håkansson LK <[email-masked]> wrote:

> This was a good summary. I'm mostly concerned with the quality degradations experienced by the end user and less about the cost (on the other hand, I guess this would in the end hit the end users as well).
> 
> I think having a 'SHOULD' for a few additional codecs would reduce the number of end users impacted by the degradations (and cost) mentioned, and I think that would make a lot of sense.
> 
> Stefan
> 
>> _____________
>> Roman Shpount
>> 
>>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 17 Jan 2013 14:24:46 +0100

> instead of USD 0.00000001/call?

I explicitly said my concern was the quality experienced by the end 
user, not the cost. At least that is what I wanted to say, and I don't 
think I was unclear.

>
> On Jan 17, 2013, at 8:14 AM, Stefan Håkansson LK
> <[email-masked]> wrote:
>
>>> G.722/AMR/AMR-WB", what is the failure mode for your
>>> application? Keeping in mind that - because this isn't 2119 MUST
>>> - you have to expect that some non-negligible proportion of
>>> clients will not support this no matter how much extra ink we
>>> using in printing large letters, how much pain does this really
>>> cause you?
>>>
>>> Does anyone care to quantify this?
>>>
>>>
>>> If common codecs are not implemented in the browser this would
>>> mean transcoding will need to be performed on some sort of
>>> server-side media gateway. There are three distinct issues we
>>> need to take into account when dealing with transcoding. I would
>>> list them in what, at least from my point of view, is the order
>>> of importance:
>>>
>>> 1. If you need to do trancoding, you will need to implement a
>>> jitter buffer on the transcoding media gateway. ICE processing
>>> and SRTP en/decoding can be performed on out of order packets as
>>> they are received. You cannot transcode out of order audio. This
>>> means audio packets would need to be delayed by the jitter buffer
>>> size. In cases of good internet connection this means 40 ms
>>> jitter buffer delay. In cases of consumer internet in US
>>> (somebody sitting on a DSL connection at home behind a WiFi
>>> router) you are typically looking at 60-80 ms jitter buffer
>>> delay. If you are dealing with international internet
>>> connections jitter of 150 ms to 200 ms is not unheard of. This
>>> means an additional delay due to jitter buffering of 40 ms (best
>>> case) to 200 ms. This is in addition to any other delays that are
>>> already present on the audio path. Adding an extra 100 ms of
>>> delay can make audio conversions very awkward or unusable. On the
>>> other hand, if the gateway were performing just ICE and SRTP, it
>>> would introduce 1-2 ms of delay at most (In this case I am
>>> talking about a software based implementation running on generic
>>> server hardware. A dedicated DSP solution would probably be even
>>> faster).
>>>
>>> degradation due to transcoding (OPUS transcoded to AMR would
>>> sound worse then OPUS or AMR), we would also deal with double
>>> packet loss concealment. Media gateway will conceal lost packets
>>> when transcoding. Client will conceal lost packet received from
>>> the gateway. This would actually sound worse then PLC performed
>>> in one place.
>>>
>>> 3. Scalability of the transcoding gateway. Gateway which just
>>> deals with ICE processing and SRTP en/decoding can handle from
>>> 2000 to 10000 concurrent call when running on a generic server
>>> CPU (different scalability is due to differences in CPU
>>> performance and presence of AES specific instructions). Gateway
>>> that would do G.722 to OPUS transcoding would most likely handle
>>> from 500 to 1000 concurrent calls. We are looking at 10x
>>> difference in performance. If we need to transcode AMR to OPUS
>>> the difference would be even higher. This translates in 10x
>> degradations experienced by the end user and less about the cost
>> (on the other hand, I guess this would in the end hit the end users
>> as well).
>>
>> I think having a 'SHOULD' for a few additional codecs would reduce
>> the number of end users impacted by the degradations (and cost)
>> mentioned, and I think that would make a lot of sense.
>>
>> Stefan
>>
>>> _____________ Roman Shpount
>>>
>>>
>>> _______________________________________________ rtcweb mailing
>>> list [email-masked]
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Burger Eric <[email-masked]>
Date: Thu, 17 Jan 2013 08:31:54 -0500

People, let's be real:
I get the impression that people think that if their favorite codec does not become mandatory to implement or at least implement-under-threat-of-SHOULD, then no one will implement their favorite codec.

Let us look at the real world. All of those mobile phones with AMR-WB? They are statistically likely to be calling other mobile phones with AMR-WB. Unless I missed something, RTCweb still lets the offer include AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will still get used, and you can leverage all of the silicon and pre-paid IPR licenses. What about all of those Flash implementations with speex? They are statistically likely to be calling other implementations with speex. I am again only just guessing that the offer will contain speed and the answer will contain speex.

What about the poor slob on a mobile with AMR-WB that wants to call that Flash buddy with speex? Last I looked, the specification has a MTI of opus. They will connect with opus. If the client is RTCweb compliant, THERE WILL BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING.

Now, what about the really poor slob on a non-RTCweb device? Well, they are, ahem, on a non-RTCweb device. That is way out of scope. But wait, you will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no RTCweb? Well, first off, the mobile-based RTCweb device will almost certainly have AMR-WB. While some folks like to pick on mobile phone manufacturers, I doubt some product manager is going to say, "Gee, the IETF specification does not even mention AMR-WB, so I suppose I will not enable the silicon I already paid for or use the license I already paid for, and I will spend my engineering budget to take out AMR-WB." Duh - AMR-WB will be there already, no transcoding, life is good. What about fixed-line or broadband interoperability with some wireless user, when they only have G.722? Well, while we are not making the situation any better, THE SITUATION IS NO WORSE. Transcoding would happen ANYWAY. It happens TODAY. So get with the program.

Let us fill in the rat-hole and just move on. Two MTI codecs and a SEPARATE implementation guide listing why you MIGHT want to implement your favorite codec.

[Hmmmm. "MIGHT".  Perhaps a new 2119 term, meaning "You might consider this, and if you don't do it, may may get cooties."]

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Thu, 17 Jan 2013 14:11:23 +0000

Folks:

If transcoding is happening today in real-life situations and people are
happy with the quality (assuming transcoding cost is negligible), we should
not even need negotiations for the codec. Life will be simpler (if not
simplest).

Let us explore the audio codec options as stated below.

If people want negotiations as far as practicable for a common codec before
going for transcoding, then the question comes as follows:

"At what point of negotiations, people will decide that we have to go for
transcoding?"

It appears that we should not go both ways (negotiations + transcoding).

On the other hand, we can mandate two audio codecs: one for wired network
and another for mobile wireless network.

In this way, transcoding may occur only once for the calls that go between
the wired and the wireless (mobile) network.

If we want only one codec without any transcoding for both wireless (mobile)
and wired network, we need to go for a single codec whose quality is
reasonably acceptable for both wired and wireless (mobile) network.

If we make more than two (wired + wireless) codecs mandatory, we can do so
if the implementation cost is negligible.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Burger Eric
Sent: Thursday, January 17, 2013 8:32 AM
To: [email-masked]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

People, let's be real:
I get the impression that people think that if their favorite codec does not
become mandatory to implement or at least implement-under-threat-of-SHOULD,
then no one will implement their favorite codec.

Let us look at the real world. All of those mobile phones with AMR-WB? They
are statistically likely to be calling other mobile phones with AMR-WB.
Unless I missed something, RTCweb still lets the offer include AMR-WB and
the answer select AMR-WB. Your precious AMR-WB codec will still get used,
and you can leverage all of the silicon and pre-paid IPR licenses. What
about all of those Flash implementations with speex? They are statistically
likely to be calling other implementations with speex. I am again only just
guessing that the offer will contain speed and the answer will contain
speex.

What about the poor slob on a mobile with AMR-WB that wants to call that
Flash buddy with speex? Last I looked, the specification has a MTI of opus.
They will connect with opus. If the client is RTCweb compliant, THERE WILL
BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING.

Now, what about the really poor slob on a non-RTCweb device? Well, they are,
ahem, on a non-RTCweb device. That is way out of scope. But wait, you will
say -- what about the 1.1 billion 3G subscribers with AMR-WB but no RTCweb?
Well, first off, the mobile-based RTCweb device will almost certainly have
AMR-WB. While some folks like to pick on mobile phone manufacturers, I doubt
some product manager is going to say, "Gee, the IETF specification does not
even mention AMR-WB, so I suppose I will not enable the silicon I already
paid for or use the license I already paid for, and I will spend my
engineering budget to take out AMR-WB." Duh - AMR-WB will be there already,
no transcoding, life is good. What about fixed-line or broadband
interoperability with some wireless user, when they only have G.722? Well,
while we are not making the situation any better, THE SITUATION IS NO WORSE.
Transcoding would happen ANYWAY. It happens TODAY. So get with the program.

Let us fill in the rat-hole and just move on. Two MTI codecs and a SEPARATE
implementation guide listing why you MIGHT want to implement your favorite
codec.

[Hmmmm. "MIGHT".  Perhaps a new 2119 term, meaning "You might consider this,
and if you don't do it, may may get cooties."]

On Jan 17, 2013, at 7:54 AM, Andrew Allen <[email-masked]> wrote:

> 
> As I recall during the MTI discussion it was claimed that OPUS was
intended for interoperability between RTCweb endoints and G.711 for
interoperability with legacy. That's why we selected 2 MTI Codecs.
> 
> Transcoding between G.711 and something else like G.722 will not have
anything like the transcoding cost as between OPUS and G.722 - basically the
complexity of a media gateway.  Of course you will not get the full fidelity
of either OPUS or G.722 but basic audio communications will work fine which
is all I think we can guarantee with legacy.
> 
> If platforms already have other codecs (such as AMR on mobile devices)
that are usable by the browser then it makes perfect sense that they be
included in the offer but I don't think IETF should start recommending other
codecs to implement other than the 2 MTI. This should be left as product
decisions based on commercial needs and not recommendations made by IETF the
driver for which I suspect has more to do with the interests of some legacy
products/deployments than those of RTCweb. 
> 
> Since almost every computing platform has a browser (including most mobile
phones) within a few years every computing platform will have RTCweb and
OPUS so the need for high fidelity legacy codec interoperability will I
think become a mute point.
> 
> I think the inteoperability concerns should be more focussed on the video
issue where we seem to have a real problem.

---

From: Tim Panton <[email-masked]>
Date: Thu, 17 Jan 2013 14:16:12 +0000

On 17 Jan 2013, at 10:31, Roman Shpount wrote:

> 
> On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <[email-masked]> wrote:
> If common codecs are not implemented in the browser this would mean transcoding will need to be performed on some sort of server-side media gateway. There are three distinct issues we need to take into account when dealing with transcoding. I would list them in what, at least from my point of view, is the order of importance:
> 
> 1. If you need to do trancoding, you will need to implement a jitter buffer on the transcoding media gateway. ICE processing and SRTP en/decoding can be performed on out of order packets as they are received. You cannot transcode out of order audio. This means audio packets would need to be delayed by the jitter buffer size. In cases of good internet connection this means 40 ms jitter buffer delay. In cases of consumer internet in US (somebody sitting on a DSL connection at home behind a WiFi router) you are typically looking at 60-80 ms jitter buffer delay. If you are dealing with international internet connections jitter of 150 ms to 200 ms is not unheard of. This means an additional delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in addition to any other delays that are already present on the audio path. Adding an extra 100 ms of delay can make audio conversions very awkward or unusable. On the other hand, if the gateway were performing just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case I am talking about a software based implementation running on generic server hardware. A dedicated DSP solution would probably be even faster).

Wait, you run the risk of double counting (at least to some extent). The overall jitter from Alice to Bob isn't changed by transcoding. 
I think you are implying that because we transcode in the middle, there will be 2 jitterbuffers and the sum of the depth of these jitterbuffers will
exceed the depth of the single jitterbuffer that would be needed if there was no transcoding. I agree, but I dispute that the sum of these 2 jitterbuffers would be more than 20ms greater than the individual jitterbuffer that Bob would run anyway. 

If you look at the typical deployment scenario for 722 - Bob is either a conference mixer engine or using a desktop phone on a wire to a reliable low loss company network. Most of the packet jitter (and loss) occurs in the first couple of hops from Alice's browser through the wifi and the cafe's DSL, 
so the jitterbuffer in the middle is probably the right place to put it.
 
> 
> 2. Audio artifacts due to transcoding. Apart from usual audio degradation due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or AMR), we would also deal with double packet loss concealment. Media gateway will conceal lost packets when transcoding. Client will conceal lost packet received from the gateway. This would actually sound worse then PLC performed in one place.

This is true, but I'd need to hear examples to be convinced it is significant. My informal experiments calling 722 endpoints from opus sound pretty good.
People live with gsm610 transcoded to g729 all the time and that sounds horrible.

> 
> 3. Scalability of the transcoding gateway. Gateway which just deals with ICE processing and SRTP en/decoding can handle from 2000 to 10000 concurrent call when running on a generic server CPU (different scalability is due to differences in CPU performance and presence of AES specific instructions). Gateway that would do G.722 to OPUS transcoding would most likely handle from 500 to 1000 concurrent calls. We are looking at 10x difference in performance. If we need to transcode AMR to OPUS the difference would be even higher. This translates in 10x difference in hardware, data center, power, and operations costs.

This is fair comment, but I'm afraid it isn't enough to convince me we SHOULD RECOMMEND G722.

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jan 2013 08:18:46 -0600

> no interconnection, and the only way to reach each other is via the

If you're using the existing PSTN as your lowest-common-denominator 
interconnect, then the call *is* going to be G.711 at some point in its 
life. And given that the WebRTC endpoints can talk G.711 to the PSTN 
gateway -- G.711 being MTI -- this use case is already addressed.

/a

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Jan 2013 15:24:22 +0100

> gateway -- G.711 being MTI -- this use case is already addressed.

I subsume under "legacy telephone network" both the fixed network
(G.711) and the mobile network (AMR-WB).
 
Uwe

---

From: Tim Panton <[email-masked]>
Date: Thu, 17 Jan 2013 14:24:32 +0000

> the wired and the wireless (mobile) network.

You seem to be assuming there are 2 separate networks with separate use cases.

If I use my android device over wifi to a base station that is connected over DSL
to talk to my office, am I a wireless user or a wired one? What if I continue the session 
as I walk out of the house and the device switches to 3g ?

Tim.

---

From: Tim Panton <[email-masked]>
Date: Thu, 17 Jan 2013 14:27:43 +0000

> (G.711) and the mobile network (AMR-WB).

I guess that more calls are made with GSM.610 than AMR-WB

AMR-WB is 'future legacy' ;-)

T.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Jan 2013 09:31:16 -0500

On Thu, Jan 17, 2013 at 9:16 AM, Tim Panton <[email-masked]> wrote:

>
> Wait, you run the risk of double counting (at least to some extent). The
> overall jitter from Alice to Bob isn't changed by transcoding.
> I think you are implying that because we transcode in the middle, there
> will be 2 jitterbuffers and the sum of the depth of these jitterbuffers will
> exceed the depth of the single jitterbuffer that would be needed if there
> was no transcoding. I agree, but I dispute that the sum of these 2
> jitterbuffers would be more than 20ms greater than the individual
> jitterbuffer that Bob would run anyway.
>
> If you look at the typical deployment scenario for 722 - Bob is either a
> conference mixer engine or using a desktop phone on a wire to a reliable
> low loss company network. Most of the packet jitter (and loss) occurs in
> the first couple of hops from Alice's browser through the wifi and the
> cafe's DSL,

Well not exactly double counting. If jitter on both calls legs are
independently normally distributed and if we have jitter of X from webrtc
client to transcoder, and jitter Y from transcoder to the end client, then
in case of jitter buffer in the middle the total delay is X+Y, in case of
end-to-end transmission it is sqrt(X^2 + Y^2). So in case of two 100 ms
jitters the difference is 200 ms of overall delay vs 141 ms of overall
delay.

Regarding the deployment scenarios, you are correct in some cases where
transcoder is sitting on the edge of well configured VoIP network. In such
cases your penalty is essentially equal to jitter within the VoIP network.
Unfortunately, there is still a use case when both end points are on
consumer IP connections, for instance, when you add webrtc client to a
hosted PBX service. Your legacy phones are located at homes or small
offices and your WebRTC clients are on similar connections. You would see
significant jitter on both.
_____________
Roman Shpount

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Thu, 17 Jan 2013 14:33:51 +0000

It does not matter whether you are in wired or wireless network.

Devices will have at least two codecs and people can choose anyone without
being afraid of quality and the calls will not fail.

RRR
-----Original Message-----
From: Tim Panton [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 9:25 AM
To: Roy, Radhika R CIV USARMY (US)
Cc: Burger Eric; [email-masked]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus

	On the other hand, we can mandate two audio codecs: one for wired
network
	and another for mobile wireless network.
	
	In this way, transcoding may occur only once for the calls that go
between
	the wired and the wireless (mobile) network.

You seem to be assuming there are 2 separate networks with separate use
cases.

If I use my android device over wifi to a base station that is connected
over DSL to talk to my office, am I a wireless user or a wired one? What if
I continue the session as I walk out of the house and the device switches to
3g ?

Tim.

---

From: Andrew Allen <[email-masked]>
Date: Thu, 17 Jan 2013 14:37:38 +0000

Since 3GPP is already working on a future codec for LTE AMR-WB may be a quite near future legacy.

That's part of my reasoning - things move quite fast with Codec development and whatever we think are the important codecs will likely be outdated very soon.

RTCweb should just ensure that it has good inteoperability between RTCweb endpoints (achieved with OPUS) and the ability through gateways to achieve basic interoperability with everything else (achieved with G.711). Job done!

Everything else IMHO is a rat hole of my codec is better than yours or this is what you need to support where - a situation which is very far from static.

Andrew

From: Tim Panton [mailto:[email-masked]]
Sent: Thursday, January 17, 2013 08:27 AM Central Standard Time
To: Rauschenbach, Uwe (NSN - DE/Munich) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

T.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Jan 2013 06:38:26 -0800

Sent from ipv6-only Android
> People, let's be real:

+1.  Seriously,  this is a candidate for the longest  rat hole I have seen
on the ietf ever.

I normally just delete this thread unread since it is so unproductive.

> I get the impression that people think that if their favorite codec does
not become mandatory to implement or at least
implement-under-threat-of-SHOULD, then no one will implement their favorite
codec.
>
> Let us look at the real world. All of those mobile phones with AMR-WB?
They are statistically likely to be calling other mobile phones with
AMR-WB. Unless I missed something, RTCweb still lets the offer include
AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will still
get used, and you can leverage all of the silicon and pre-paid IPR
licenses. What about all of those Flash implementations with speex? They
are statistically likely to be calling other implementations with speex. I
am again only just guessing that the offer will contain speed and the
answer will contain speex.
>
> Now, what about the really poor slob on a non-RTCweb device? Well, they
are, ahem, on a non-RTCweb device. That is way out of scope. But wait, you
will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no
RTCweb? Well, first off, the mobile-based RTCweb device will almost
certainly have AMR-WB. While some folks like to pick on mobile phone
manufacturers, I doubt some product manager is going to say, "Gee, the IETF
specification does not even mention AMR-WB, so I suppose I will not enable
the silicon I already paid for or use the license I already paid for, and I
will spend my engineering budget to take out AMR-WB." Duh - AMR-WB will be
there already, no transcoding, life is good. What about fixed-line or
broadband interoperability with some wireless user, when they only have
G.722? Well, while we are not making the situation any better, THE
SITUATION IS NO WORSE. Transcoding would happen ANYWAY. It happens TODAY.
So get with the program.
>
> Let us fill in the rat-hole and just move on. Two MTI codecs and a
SEPARATE implementation guide listing why you MIGHT want to implement your
favorite codec.

Yep.  Seems we decided this months ago but certain people don't want to
hear it.

CB

> [Hmmmm. "MIGHT".  Perhaps a new 2119 term, meaning "You might consider
this, and if you don't do it, may may get cooties."]
> > Transcoding between G.711 and something else like G.722 will not have
anything like the transcoding cost as between OPUS and G.722 - basically
the complexity of a media gateway.  Of course you will not get the full
fidelity of either OPUS or G.722 but basic audio communications will work
fine which is all I think we can guarantee with legacy.
that are usable by the browser then it makes perfect sense that they be
included in the offer but I don't think IETF should start recommending
other codecs to implement other than the 2 MTI. This should be left as
product decisions based on commercial needs and not recommendations made by
IETF the driver for which I suspect has more to do with the interests of
some legacy products/deployments than those of RTCweb.
> > Since almost every computing platform has a browser (including most
mobile phones) within a few years every computing platform will have RTCweb
and OPUS so the need for high fidelity legacy codec interoperability will I
think become a mute point.
> >
> > I think the inteoperability concerns should be more focussed on the
video issue where we seem to have a real problem.
Behalf Of
when
buffer
degradation
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.

---

From: Xavier Marjou <[email-masked]>
Date: Thu, 17 Jan 2013 15:41:00 +0100

Regarding audio codecs, it is a common misconception that existing
voice networks only support G.711. For the sake of clarity, let's say
that there is the PSTN (circuit switched networks) and the "PSTN" (a
set of networks made of the PSTN, PLMN but also H.323 and SIP based
networks...). In the "PSTN", there is sometimes the real need to use a
codec of lower-bandwidth than G.711, and sometimes the opportunity to
use WB codecs. WebRTC must interoperate with the "PSTN", not only the
PSTN.

Cheers,
Xavier

On Thu, Jan 17, 2013 at 3:18 PM, Adam Roach <[email-masked]> wrote:
> life. And given that the WebRTC endpoints can talk G.711 to the PSTN gateway
> -- G.711 being MTI -- this use case is already addressed.
>

---

From: <[email-masked]>
Date: Thu, 17 Jan 2013 14:41:17 +0000

> AMR-WB is 'future legacy' ;-)

It seems we already live in the future: Currently HD voice with AMR-WB is launched in more than 50 mobile networks all over the world (more than 35 countries) with more than 130 WB-AMR enabled mobile devices

Probably at present time a little bit more AMR-WB codecs deployed than OPUS codecs.

Just check on the GSA Web site

http://www.gsacom.com/news/gsa_358.php

Stephane

De : [email-masked] [mailto:[email-masked]] De la part de Tim Panton
Envoyé : jeudi 17 janvier 2013 15:28
À : Rauschenbach, Uwe (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

T.

---

From: Tim Panton <[email-masked]>
Date: Thu, 17 Jan 2013 14:48:00 +0000

> http://www.gsacom.com/news/gsa_358.php

At the risk of worsening the rat hole, I will bet you that more wideband minutes are carried over opus on Mumble
than AMR-WB over the entire GSMA. 

I'll also bet that there are more chrome users (with opus enabled) than Gsm handsets with AMR-WB enabled.

T.

---

From: <[email-masked]>
Date: Thu, 17 Jan 2013 14:53:48 +0000

Please consider that the AMR-WB codec is the mandatory codec for HD Voice VoLTE terminals and that first VoLTE deployments in the world from Korean Telcos (SKT and LGU) are HD Voice with AMR-WB (And with respect to your past/future categories, I think we can say that VoLTE is more on future side that "past")

But AMR-WB is also already deployed in the 2G and 3G networks of more than 50 Mobile Network Operators

So I agree that interop. with legacy are two objectives distinct and fortunately, supporting AMR-WB is sufficient to reach both in the same time !

De : Bernard Aboba [mailto:[email-masked]] 
Envoyé : lundi 14 janvier 2013 15:35
À : PROUST Stephane OLNC/OLPS
Cc : [email-masked]
Objet : RE: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Stephane said:

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Jan 2013 07:11:45 -0800

Sent from ipv6-only Android
On Jan 17, 2013 6:54 AM, <[email-masked]> wrote:
>
> Please consider that the AMR-WB codec is the mandatory codec for HD Voice
VoLTE terminals and that first VoLTE deployments in the world from Korean
Telcos (SKT and LGU) are HD Voice with AMR-WB (And with respect to your
past/future categories, I think we can say that VoLTE is more on future
side that "past")
> So I agree that interop. with legacy are two objectives distinct and
fortunately, supporting AMR-WB is sufficient to reach both in the same time
!

Please accept that the ipr terms of amr-wb pose a huge barrier for the
ietf. I really believe you are wasting your time. Please focus your efforts
on ensuring your offer/answer supports the codec you want you want in your
implementation.

Your efforts would be better spent getting the 3gpp to accept Opus as their
default,  it is royalty free and mti for all web browsers.

Br,

CB

> "In addition to G.711, these 3 codecs cover almost all legacy devices
dedicated to voice services. They are consequently needed and sufficient to
be supported by WebRTC to make it an attractive and future proof technology"
>
> [BA] The use of the terms "legacy" and "future proof" here is puzzling.
"Future proof" would seem to imply the ability to adapt to future
developments, whereas "legacy" relates to compatibility with what has gone
before.   Unless the "past" is the same as the "future" (which implies no
progress at all), those two objectives are distinct (and possibly
conflicting).
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
information that may be protected by law;

---

From: <[email-masked]>
Date: Thu, 17 Jan 2013 15:16:03 +0000

Hello all

Considering all the discussions on the list, it is clear that a way must be found to address from codec perspective both the interoperability issue and the license cost issues with a good compromise spirit

Ensuring interoperability of Web RTC technology across various types of environment and devices (e.g. fixed/PC, mobile, tablets..) is a must.

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. 
 
The lack of support & use of AMR and AMR-WB codecs  in Web-RTC will then require transcoding and degrade the user experience: lower end to end voice quality and increased latency. The lack of support of these codecs would also increase the costs on network side to implement codec transcoding functions.
 
Hence, it is needed to also consider the support & use of these additional codecs (AMR, AMR-WB) by Web-RTC.
 
It is recognized however that the support of these additional codecs by WebRTC would add some costs on browsers, part of these costs coming from codec license fees. However, from technical perspective, browser implementation of these codecs is not needed, when these codecs are already natively implemented by the hardware platform (e.g. by mobile phone).
 
Considering this very reduced set of additional codecs which has to be taken into account and considering, in addition, that these codecs are already supported by many devices, a way forward can surely be found like by ensuring that RTC Web give access to these codecs at reasonable costs whenever possible. And this could be especially the case when these codecs are already implemented on the devices.
 
Such way forward would require however more than just e-mail discussion between different options. We think that some more detailed inputs for next meeting would be needed to address properly this interoperability topic by considering priority use cases and compromise ways forward like proposed in this e-mail.

We intent to provide a draft on this issue at next meeting.

-----Message d'origine-----
De : PROUST Stephane OLNC/OLPS 
Envoyé : vendredi 11 janvier 2013 13:33
À : 'Magnus Westerlund'; [email-masked]
Objet : RE: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

-----Message d'origine-----

WG,

Regards

Magnus Westerlund

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Jan 2013 10:27:40 -0500

I guess I will continue to contribute to hole digging...

This question is to web browser implementers which are present on the list:
Can you tell us if you are planning to include G.722 in the WebRTC browser
releases? If not, then for what reason?

Regards,
_____________
Roman Shpount

---

From: Mark Rejhon <[email-masked]>
Date: Thu, 17 Jan 2013 10:59:25 -0500

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

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

---

From: Mark Rejhon <[email-masked]>
Date: Thu, 17 Jan 2013 11:13:34 -0500

> (not final wording, but you get the spirit)

Precedent: Mozilla's support of H.264 on platforms that have hardware
H.264 built in.
-- We remember how Mozilla is famously  against IPR-encumbered codecs,
but they've managed to find a way to support it while satisfying most
of the issues.  It is not a 100% solution, but lessons from the HTML5
<video> applies here, and I would need my very own brain checked if I
ignored such lessons.  We're lucky in that we have probably less
disagreement over required codecs (as imperfect as it is) than big
players had with HTML5 <video>.

Mark Rejhon

---

From: Tim Panton <[email-masked]>
Date: Thu, 17 Jan 2013 16:24:10 +0000

On 17 Jan 2013, at 15:59, Mark Rejhon wrote:
> .  For example, a mobile phone implementation would likely have easy
> 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.

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jan 2013 11:05:36 -0600

> Precedent: Mozilla's support of H.264 on platforms that have hardware

You might benefit from re-reading the announcement of that support; in 
particular the second-to-last paragraph:

https://brendaneich.com/2012/10/html5-video-update/

/a

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 17 Jan 2013 17:07:29 +0000

A great reminder that we should have just had an in-person call for consensus for video codec immediately after Google withdrew their alternative from consideration.

Matthew Kaufman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Thursday, January 17, 2013 9:06 AM
To: Mark Rejhon
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

> Precedent: Mozilla's support of H.264 on platforms that have hardware

You might benefit from re-reading the announcement of that support; in particular the second-to-last paragraph:

/a

---

From: Andrew Allen <[email-masked]>
Date: Thu, 17 Jan 2013 17:43:33 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Panton
Sent: Thursday, January 17, 2013 11:24 AM
To: Mark Rejhon
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

T.

---

From: Andrew Allen <[email-masked]>
Date: Thu, 17 Jan 2013 17:59:57 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Rejhon
Sent: Thursday, January 17, 2013 10:59 AM
To: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

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

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

---

From: Steve Sokol <[email-masked]>
Date: Thu, 17 Jan 2013 12:00:44 -0600 (CST)

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: +1 256 428 6101 
Mobile: +1 816 806 8844 

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

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

> Behalf Of Tim Panton

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

---

From: Andrew Allen <[email-masked]>
Date: Thu, 17 Jan 2013 18:16:48 +0000

G.711 allows interoperability with the PSTN.

----- Original Message -----
From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, January 17, 2013 07:16 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

Kind regards,
Uwe

> 	G.722/AMR/AMR-WB", what is the failure mode for your
application?
due

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jan 2013 13:07:13 -0600

On 1/17/13 12:00, Steve Sokol wrote:
>
> 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.
>

By which you mean it adds nothing to the licensing cost. Integration, 
testing, and perpetual maintenance are not free.

/a

---

From: Steve Sokol <[email-masked]>
Date: Thu, 17 Jan 2013 13:23:05 -0600 (CST)

> /a

Agreed.

---

From: Eric Burger <[email-masked]>
Date: Thu, 17 Jan 2013 19:06:24 -0500

So this says that hundreds of millions of mobile telephones do not support SIP, either. Therefore, should we care if we do not support this proprietary network? I don't.

---

From: Burger Eric <[email-masked]>
Date: Thu, 17 Jan 2013 19:07:20 -0500

Note that "Agreed" can cost way more than the IPR from the vendor's perspective. Just about a non-starter for anyone selling systems with support.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 18 Jan 2013 01:11:47 +0100

Integration, testing, and perpetual maintenance have absolutely nothing to do with the IPR question. I don't see any mention of any of Integration, 
testing, and perpetual maintenance in any of the statements about WG responsibilities in IPR.

You are adopting the policy of saying everything you input is relevant to the argument and everything anybody else says in irrelevant.

Regards

Keith

> Of Adam Roach
> Sent: 17 January 2013 19:07
> To: Steve Sokol
> Cc: [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jan 2013 16:25:04 -0800

On 17 January 2013 16:11, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> Integration, testing, and perpetual maintenance have absolutely nothing to do with the IPR question.

I wasn't aware that this was a decision that relied solely on IPR
concerns, only that IPR concerns were relevant (even if they are less
relevant for SHOULD/should than for MUST).

> You are adopting the policy of saying everything you input is relevant to the argument and everything anybody else says in irrelevant.

So what?  That seems to be fairly common in this forum.

In fairness, I don't think that Adam is making such a blanket
statement, only that certain key points are irrelevant.  For instance,
the the cost of transcoding (in quality and $$) seems relevant.
However, given that it doesn't result in interoperability failure, the
argument Adam puts forward is that this line of argument and all other
"wouldn't it be nice" arguments aren't especially convincing.  That
doesn't invalidate other lines of argument based on cost to
implementers.

---

From: Andrew Allen <[email-masked]>
Date: Fri, 18 Jan 2013 00:32:46 +0000

Keith

I think Adam is just saying there is no free lunch - everything has a cost.

Some people have suggested that these codecs are FREE - nothing is for free.

Once we achieve basic interoperability additional nice to have features (even if they are perceived to be an improvement) that will involve costs to implement should be determined by implementers based on their commercial merits.

In my view G.711 is enough to ensure basic  interoperability with legacy codecs - it's at least as good as interoperability between the PSTN and these legacy systems.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, January 17, 2013 7:12 PM
To: Adam Roach; Steve Sokol
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Integration, testing, and perpetual maintenance have absolutely nothing to do with the IPR question. I don't see any mention of any of Integration, testing, and perpetual maintenance in any of the statements about WG responsibilities in IPR.

Regards

Keith

> Behalf Of Adam Roach
> > include G.722, so perhaps we can all agree that it should be 
> > included unless there is some reason not to do so.
> >
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jan 2013 22:11:34 -0600

Keith:

I've written and discarded three rather long missives in response to 
your goading, but found none of them to be as concise and lucid as 
Martin and Andrew's responses. I'm going to let their messages stand in 
for my clarification, as they both get it right.

/a

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 18 Jan 2013 11:31:23 +0000

On 17 January 2013 18:00 Andrew Allen wrote:
> 
> 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"
> 

I think this is a very sensible proposal as we need to say something that indicates that just implementing the mandatory codec's is not the best solution and it seems that mentioning particular codec's is going to be take us down another rat hole.

Andy

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 18 Jan 2013 13:25:30 +0100

> I think this is a very sensible proposal as we need to say something that indicates that just implementing the mandatory codec's is not the best solution and it seems that mentioning particular cod…

Agree fully. Not having G.722 as a mandatory codec for SIP hasn't stopped the usage of it.

/O

---

From: Tim Panton <[email-masked]>
Date: Fri, 18 Jan 2013 16:43:38 +0000

> I think this is a very sensible proposal as we need to say something that indicates that just implementing the mandatory codec's is not the best solution and it seems that mentioning particular cod…

Just for clarity, lets make that 
"If other suitable audio codecs are available to the browser to use it
is beneficial that they are also included in the offer but at a lower priority than the MTI codecs
in order to maximize the possibility to establish the session without the need for
audio transcoding"

Tim.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 18 Jan 2013 21:39:12 +0100

As stated that says that any additional wideband codec should have a lower priority than the mandatory to implement G.711.

I'd also suggest that that amendment if included in no way overrides an explicit statement by the user of their preferences.

Regard

Keith

> Of Tim Panton
> Sent: 18 January 2013 16:44
> To: Hutton, Andrew
> Cc: [email-masked]
> > I think this is a very sensible proposal as we need to say something
> that indicates that just implementing the mandatory codec's is not the
> best solution and it seems that mentioning particular codec's is going to
> be take us down another rat hole.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Jan 2013 13:13:42 -0800

> As stated that says that any additional wideband codec should have a lower priority than the mandatory to implement G.711.

Yes.  Let the implementation (or the user) make any decisions on
priority.  We don't need to force the negotiation of Opus, its quality
should ensure that happens.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 19 Jan 2013 15:31:35 +0900

First, for the chairs: Please, please close this Call for Consensus, to 
avoid further email avalanches on this topic. I'd expect the chairs to 
potentially follow up with a more narrow call (e.g. centering on wording 
as below), but that's their decision of course.

> in order to maximize the possibility to establish the session without the need for

I was thinking about the priority issue a few days ago, and came to the 
conclusion that this may be too specific. Assume that I have a mobile 
phone with MTI codec in software and another codec in hardware, and the 
later is significantly more power efficient. Assume I'm talking with 
another user on a similar phone. Then given these assumptions, I guess 
we both would prefer to use our hardware codecs, but that doesn't happen 
if the MTI codecs have priority.

So I'd leave out the priority issue, and just keep the rest of the text.

Regards,   Martin.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 19 Jan 2013 20:09:03 +0000

> in order to maximize the possibility to establish the session without the need for

Umm... but then two endpoints both implementing a better non-MTI codec would pick the MTI one instead of the better one.

Generally you don't need to muck with the order to get transcoder-free operation - as long as both sides support at least one common one, they'll pick it if they follow the preference rules in RFC 3264.  That's because the gateway in the middle will usually add the additional codecs it can transcode for, later in the SDP m-line preference order (ie, make them lower preference in the offer).[1]

-hadriel
[1] I say "usually" because of course this is not always the case, because sometimes they change the pref order for other reasons; nor is it the case that gateways in the middle always add codecs for transcoding, but rather sometimes they let the INVITE fail first and then re-send it with additional codecs (though that's a far less common model).

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 29 Jan 2013 15:14:03 +0000

On Jan 18, 2013, at 11:31 PM, Martin J. Dürst <[email-masked]> wrote:

> Please, please close this Call for Consensus, to avoid further email avalanches on this topic. 

It was closed and the conclusion was "no consensus".

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 29 Jan 2013 18:00:28 +0000

> all count as PLC. Personally, I really don't feel like getting into a

Oh, the irony of we are fine with saying SHOULD do AEC (already in a WG draft) but we are not fine with saying SHOULD do PLC.

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 29 Jan 2013 13:42:24 -0500

On 01/29/2013 01:00 PM, Cullen Jennings (fluffy) wrote:
>> "SHOULD include a PLC" only makes sense if you specify minimum 
>> quality requirements. Otherwise "repeat previous packet" or
>> "fill with zeros" all count as PLC. Personally, I really don't
>> feel like getting into a PLC quality spec.
> 
> Oh, the irony of we are fine with saying SHOULD do AEC (already in
> a WG draft) but we are not fine with saying SHOULD do PLC.

I mean I'm fine with "SHOULD do PLC", but unless you specify the
minimum performance, it becomes meaningless. As for AEC, it's not
clearly stated in the current version draft, but as far as I'm
concerned, the minimum performance is "keep return gain below unity".
Of course, it's still nice to be better than that...

	Jean-Marc