Subject: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 4 Mar 2013 22:31:50 +0000

Hello,

I would like to request agenda time for:

draft-marjou-rtcweb-audio-codecs-for-interop-01

The document  presents use-cases underlining why WebRTC needs AMR-WB,  AMR and G.722 as additional relevant voice codecs to satisfactorily ensure interoperability with existing systems.

A 10-minute time slot should be sufficient for presentation and discussion.

Regards

-Espen

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 5 Mar 2013 12:43:02 +0100

On 2013-03-04 23:31, Espen Berger (espeberg) wrote:
> The document  presents use-cases underlining why WebRTC needs AMR-WB,
>   AMR and G.722 as additional relevant voice codecs to satisfactorily
> ensure interoperability with existing systems.

I agree to that we should discuss the subject of additional codecs.

Stefan

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

---

From: <[email-masked]>
Date: Wed, 6 Mar 2013 10:04:10 +0000

Hi,

>I agree to that we should discuss the subject of additional codecs.

This is a controversial topic, but I agree it would deserve some discussion to try to bring it to a closure. 

Markus

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 6 Mar 2013 12:10:23 -0500

Yes, draft-marjou-rtcweb-audio-codecs-for-interop-01 provides a proposal for
additional text to be added to draft-ietf-rtcweb-audio-01, which is an
rtcweb milestone supposed to be already completed. So it's not unreasonable
to have some discussion on the topic.

...Paul

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of [email-masked]
>Sent: Wednesday, March 06, 2013 5:04 AM
>To: [email-masked]; [email-masked]
>Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hi,
>
>Stefan Håkansson wrote:
>>
>This is a controversial topic, but I agree it would deserve some
>discussion to try to bring it to a closure.
>
>Markus

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Mar 2013 08:18:41 -0800

Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted

On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
<[email-masked]> wrote:
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AMR
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 13 Mar 2013 09:14:30 -0400

Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00
presentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually
use one of the following codecs: AMR, AMR-WB or G.722, which will result in
massive transcoding when there will be communications between WebRTC
endpoints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft
(cost issues, intrinsic quality degradation, degraded interactivity,
fallback from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs
in the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG
draft draft-ietf-rtcweb-audio providing incentives for the browser to use
these three codecs: make them mandatory to implement when there is no cost
impact on the browser (e.g. if codec already installed, paid by the device
vendor...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )

On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <[email-masked]> wrote:

>  AMR

---

From: Alex Agranovsky <[email-masked]>
Date: Wed, 13 Mar 2013 09:25:11 -0400

It's hard to imagine a situation in which AMR/AMR-WB will be available 
at no cost to the browser, considering royalties involved.

http://www.voiceage.com/amr_faqs.php#11

And if we limit the requirement only to those who have paid ... it's not 
really 'mandatory'.

- Alex

On 3/13/13 9:14 AM, Xavier Marjou wrote:
>
> Here is a summary of the 
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
> had prepared for yesterday's session:
>
> - The co-authors want to underline that non-WebRTC voice endpoints 
> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
> will result in massive transcoding when there will be communications 
> between WebRTC endpoints and non-WebRTC endpoints.
>
> - On one side, transcoding is bad for many reasons discussed in the 
> draft (cost issues, intrinsic quality degradation, degraded 
> interactivity, fallback from HD to G.711...);
>
> - On the other side, it is recognized that implementing additional 
> codecs in the browsers can generate additional costs.
>
> - In order to reach a compromise, we would like to add some text in 
> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
> browser to use these three codecs: make them mandatory to implement 
> when there is no cost impact on the browser (e.g. if codec already 
> installed, paid by the device vendor...).
>
> Any opinion on that?
>
> Cheers,
>
> Xavier
>
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > Hello,
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 13 Mar 2013 09:31:42 -0400

Mobile devices that run on 3GPP networks will already have AMR/AMR-WB codecs. Browsers should be
able to access those codecs on such devices. Does this make the proposal 'optional mandatory'?

Regards,
Kalyani Bogineni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alex Agranovsky
Sent: Wednesday, March 13, 2013 9:25 AM
To: [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

It's hard to imagine a situation in which AMR/AMR-WB will be available at no cost to the browser, considering royalties involved.

And if we limit the requirement only to those who have paid ... it's not really 'mandatory'.

- Alex

Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually use one of the following codecs: AMR, AMR-WB or G.722, which will result in massive transcoding when there will be communications between WebRTC endpoints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft (cost issues, intrinsic quality degradation, degraded interactivity, fallback from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs in the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG draft draft-ietf-rtcweb-audio providing incentives for the browser to use these three codecs: make them mandatory to implement when there is no cost impact on the browser (e.g. if codec already installed, paid by the device vendor...).

Any opinion on that?

Cheers,

Xavier

On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

regards,

Ted

On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
<[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Mar 2013 15:05:46 +0100

High level thoughts from a browser implementor:

- The first target of WebRTC is the browser to browser case. These 
codecs do not add any capability to the browser to browser case, because 
OPUS is available.

- In the most common browser distribution models, it is an advantage to 
include at least a fallback version of all available features in the 
binary, so that the set of features available to the user is constant. 
This means that the browser either incurs licensing costs or support 
costs (to support the variability of user scenarios).

- The inclusion of royalty-required codecs severely crimps the 
distribution models available for browsers, which makes it even harder 
for new browsers to enter the market than it already is, and the WG 
charter we agreed on says that we "prefer non-encumbered codecs".

We can discuss the cost of transcoding separately, but the cost to the 
browsers of extra codecs, especially royalty-encumbered ones, should not 
be underestimated.

---

From: Ron <[email-masked]>
Date: Thu, 14 Mar 2013 00:57:32 +1030

Hi Xavier,

> endpoints and non-WebRTC endpoints.

"Massive" seems a little overstated here.  Any system providing a gateway
service to or between 'low bandwidth' devices is almost surely going to
support more than just WebRTC, and is going to have to transcode for most
or all of them anyway.  Adding an extra burden to WebRTC, especially one
that would only ever apply to some small subset of users, wouldn't appear
to make a significant difference in the requirements for such a system.

> fallback from HD to G.711...);

Are you aware of the listening tests presented to the CODEC WG?

In particular the ones that show Opus->AMR and AMR->Opus is not significantly
worse than the intrinsic quality degradation suffered by using AMR alone?

Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?

> impact on the browser (e.g. if codec already installed, paid by the device

Since there is never no cost impact to supporting additional features, that
would imply this is never mandatory ...

In which case why bother half-saying otherwise?

I thought it was already quite clear all along, that people who want to or
have their own good reasons to are free to implement any other codecs they
please - and that they already have, and certainly will continue to do so?

> Any opinion on that?

I don't really see much point to handwaving about particular niche codecs
for particular niche uses unless this is going to be some sort of separate
informational document, that is kept up to date with changes in all the
niches that people have an interest in.

That might be useful.  But 'mandating' something that the people who will
do it were going to do it anyway, and the people who were not are still
not going to do, doesn't seem to add any real value here to either users
or implementers.  It won't explain anything to anybody that they don't
already know if it is of any interest to them.

 Cheers,
 Ron

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 14:30:20 +0000

I think this draft is not consistent with the scope stated by the RTCweb chairs in the decision on this topic  back in February

"Additional Relevant Codecs". That can contain a list of codecs which are relevant in specific  contexts, along with a short description of the context for each. Specifically there seems to be interest in understanding the  advantages and costs of G.722, AMR, and AMR-WB. We hope that text would broaden understanding of the WebRTC use case contexts.
The current draft goes way beyond that decision in scope and uses MUST and SHOULD strength normative language instead of focusing on identifying the advantages and costs of the specific codecs and the use case contexts of where they are useful.

I think we should stick to the scope defined by the chairs and remove the normative language and focus on identifying the advantages and costs of the specific codecs and the use case contexts of where they are useful..

Andrew

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Marjou
Sent: Wednesday, March 13, 2013 9:15 AM
To: [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Any opinion on that?

Cheers,

Xavier

regards,

Ted

---------------------------------------------------------------------
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: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 13 Mar 2013 10:20:48 -0400

Section 4.3.1 of  draft-ietf-rtcweb-use-cases-and-requirements-10.txt
has usecases for mobile devices.

Here is the exact wording from the WG charter:

"..The working group cannot explicitly rule out the possibility of adopting encumbered
technologies; however, the working group will try to avoid encumbered
technologies that require royalties or other encumbrances that would
prevent such technologies from being easy to use in web browsers."
So the proposal to include support for AMR/AMR-WB is within the scope of the
current work.

Regards,
Kalyani Bogineni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Wednesday, March 13, 2013 10:06 AM
To: [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

- The first target of WebRTC is the browser to browser case. These codecs do not add any capability to the browser to browser case, because OPUS is available.

- In the most common browser distribution models, it is an advantage to include at least a fallback version of all available features in the binary, so that the set of features available to the user is constant. This means that the browser either incurs licensing costs or support costs (to support the variability of user scenarios).

- The inclusion of royalty-required codecs severely crimps the distribution models available for browsers, which makes it even harder for new browsers to enter the market than it already is, and the WG charter we agreed on says that we "prefer non-encumbered codecs".

We can discuss the cost of transcoding separately, but the cost to the browsers of extra codecs, especially royalty-encumbered ones, should not be underestimated.

Any opinion on that?

Cheers,

Xavier

regards,

Ted

rtcweb mailing list

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Mar 2013 15:37:58 +0100

>> - The co-authors want to underline that non-WebRTC voice endpoints usually use one of the following codecs: AMR, AMR-WB or G.722, which will result in massive transcoding when there will be commun…
I have a large amount of SIP phones on my desk, none which support AMR and/or AMR-WB. I had to pay extra for AMR in a SIP phone for my iPhone.

I don't agree with the standpoint that AMR is implemented on a majority of traditional non-WebRTC endpoints.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Mar 2013 15:40:34 +0100

>> impact on the browser (e.g. if codec already installed, paid by the device
I would like to propose that someone (it's out of scope for this group) make it mandatory
to implement open APIs so that all applications on these devices can use all the
codecs implemented in hardware. That's not the case now. 

/O

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 13 Mar 2013 10:43:34 -0400

---------- Forwarded message ----------
From: Xavier Marjou <[email-masked]>
Date: Wed, Mar 13, 2013 at 10:43 AM
Subject: Re: [rtcweb] Agenda time request for
draft-marjou-rtcweb-audio-codecs-for-interop-01
To: Harald Alvestrand <[email-masked]>

On Wed, Mar 13, 2013 at 10:05 AM, Harald Alvestrand <[email-masked]>wrote:

> - The first target of WebRTC is the browser to browser case. These codecs
> do not add any capability to the browser to browser case, because OPUS is
> available.
>

I agree with that browser to browser communication within a given calling
service is the first target of most players. However, there's the need to
have options for interworking with "legacy" VoIP equipments for players who
also want to open WebRTC communications towards "legacy" devices. Our draft
shows that OPUS and G.711 are really not sufficient for that.

> binary, so that the set of features available to the user is constant. This
> means that the browser either incurs licensing costs or support costs (to
> support the variability of user scenarios).
>
> distribution models available for browsers, which makes it even harder for
> new browsers to enter the market than it already is, and the WG charter we
> agreed on says that we "prefer non-encumbered codecs".
>

Yes, we understand that, and we think the text we propose tries to motivate
all players of the WebRTC ecosystem to open their technologies. I think our
text is really not such a big constraint as I read it as a conditional
statement like "if some conditions are met regarding AMR, or AMR-WB or
G.722, then the browser offers the possibility to use this codec". All
conditions may not be met today for the browser implementor, perhaps only
tomorrow, but at least writing down will provide incentives for all players
to make efforts and go in that direction.

> browsers of extra codecs, especially royalty-encumbered ones, should not be
> underestimated.
>
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 13 Mar 2013 10:37:45 -0400

There are 6.4 billion cellular connections worldwide.

http://www.3gpp.org/3GPP-Family-2012-Statistics

Regards,
Kalyani Bogineni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron
Sent: Wednesday, March 13, 2013 10:28 AM
To: Xavier Marjou; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Xavier,

On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> Here is a summary of the 
> draft-marjou-rtcweb-audio-codecs-for-interop-00

"Massive" seems a little overstated here.  Any system providing a gateway service to or between 'low bandwidth' devices is almost surely going to support more than just WebRTC, and is going to have to transcode for most or all of them anyway.  Adding an extra burden to WebRTC, especially one that would only ever apply to some small subset of users, wouldn't appear to make a significant difference in the requirements for such a system.

In particular the ones that show Opus->AMR and AMR->Opus is not significantly worse than the intrinsic quality degradation suffered by using AMR alone?

> installed, paid by the device vendor...).

Since there is never no cost impact to supporting additional features, that would imply this is never mandatory ...

I thought it was already quite clear all along, that people who want to or have their own good reasons to are free to implement any other codecs they please - and that they already have, and certainly will continue to do so?

> Any opinion on that?

I don't really see much point to handwaving about particular niche codecs for particular niche uses unless this is going to be some sort of separate informational document, that is kept up to date with changes in all the niches that people have an interest in.

That might be useful.  But 'mandating' something that the people who will do it were going to do it anyway, and the people who were not are still not going to do, doesn't seem to add any real value here to either users or implementers.  It won't explain anything to anybody that they don't already know if it is of any interest to them.

 Cheers,
 Ron

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 14:58:19 +0000

I think this would be completely out of scope of IETF.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: Wednesday, March 13, 2013 10:41 AM
To: Ron
Cc: [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

13 mar 2013 kl. 15:27 skrev Ron <[email-masked]>:

>> these three codecs: make them mandatory to implement when there is no 
>> cost impact on the browser (e.g. if codec already installed, paid by 
>> the device vendor...).
I would like to propose that someone (it's out of scope for this group) make it mandatory to implement open APIs so that all applications on these devices can use all the codecs implemented in hardware. That's not the case now. 

/O

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 13 Mar 2013 11:17:44 -0400

WebRTC standard must do the best to avoid transcoding when communications
happen towards "legacy" devices.

Another way to illustrate that is an analogy with human languages: suppose
there are two French native speakers and they have to speak English to talk
with each other: this results in additional efforts, decreased quality of
conversation, additional delays... all these details are significant for
the quality of the communication.

(of course there are some exceptions in my analogy: there exists French
native speakers who can also speak English fluently, in particular some
Quebecois folks on the list ;-)

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Mar 2013 16:17:47 +0100

> I think this would be completely out of scope of IETF.

Agree. So assuming that these codecs are available just because some hardware in a device has
a licensed implementation is not a valid assumption for a codec selection as long as we can't
assume that any application on that device has access to it.

/O

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 15:23:36 +0000

Olle

I agree with you which is why a few months ago I proposed the following text that had the "are available to the browser" caveat

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

Andrew

-----Original Message-----
From: Olle E. Johansson [mailto:[email-masked]] 
Sent: Wednesday, March 13, 2013 11:18 AM
To: Andrew Allen
Cc: Olle E. Johansson; Ron; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

> I think this would be completely out of scope of IETF.

Agree. So assuming that these codecs are available just because some hardware in a device has a licensed implementation is not a valid assumption for a codec selection as long as we can't assume that any application on that device has access to it.

/O
>>> these three codecs: make them mandatory to implement when there is 
>>> no cost impact on the browser (e.g. if codec already installed, paid 
>>> by the device vendor...).

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Mar 2013 16:42:36 +0100

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

Exactly. I don't think everyone gets the that selecting a small subset as mandatory for WebRTC does NOT exclude all other codecs. Feel
free to add everything you got. Have fun. Let the best mutual codec with the best mutual properties win the session.

/O

---

From: 'Ron' <[email-masked]>
Date: Thu, 14 Mar 2013 02:23:42 +1030

> http://www.3gpp.org/3GPP-Family-2012-Statistics

Sure.  And why do you think that someone with one of those devices,
who wanted to call someone on the legacy network that didn't have
a WebRTC service, would want to do it by going via a WebRTC gateway
service, that they would presumably have to pay extra for, and would
suffer extra hops of latency to use (even without transcoding), when
they could just, you know, call them on their cell phone normally ... ?

Trying to optimise for a case that nobody would actually ever really
use, that only guarantees poorer and more expensive results than using
either WebRTC or their phone as it was actually intended, doesn't seem
like a useful thing to focus on at this stage - let alone something we
need to 'mandate' to create an 'incentive' for.

The people who need this don't need a mandate, and the people who can't
use it are going to (have to) ignore it and none of their users will
ever notice.  That doesn't sound like any sort of mandate material to me.

Or like something that hinges on the number of legacy phones at all
for that matter.

  Ron

---

From: Tim Panton <[email-masked]>
Date: Wed, 13 Mar 2013 16:11:08 +0000

> http://www.3gpp.org/3GPP-Family-2012-Statistics

Following that logic we'd mandate GSM.610 since _all_ of those 6B devices support it.

I'd also like to point out that the "massive" transcoding cited already occurs between mobile devices 
that support various codecs (GSM, AMR etc) and the PSTN - (g711, g729) and the sky hasn't fallen yet.

Tim.

---

From: Ron <[email-masked]>
Date: Thu, 14 Mar 2013 02:44:46 +1030

> happen towards "legacy" devices.

That's a pretty general and well known principle that doesn't need mandating
specially for WebRTC or is in any way unique to it.

So maybe the "legacy" devices should just add Opus support then :)

It's not like 4 billion of the 6 billion aren't less than 2 years old, or
are not firmware upgradeable ...

And it's not like (the many) people who are jailbreaking them aren't doing
that for themselves already ...

> Quebecois folks on the list ;-)

Right, and the French and English they speak today isn't the same French
and English they spoke in mediaevil times :)

We could equally consider this an incentive for the legacy device makers
to move forward.  That seems like a much better outcome for everyone
than trying to drag the new format backward would bring.

 Doesn't it?
 Ron

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 17:12:06 +0000

> I'd also like to point out that the "massive" transcoding cited already occurs between mobile devices that support various codecs (GSM, AMR etc) and the PSTN - (g711, g729) and the sky hasn't fallen yet.

But transcoding to G.711 has simply absolutely nothing to do in terms of impact on gateways costs and capacities !
Transcoding to G.711 almost cost nothing.
For your information: complexity of G.711 is around 0,01 WMPOS when AMR-WB is at 40 WMOPS and OPUS still higher... 
So we speak about a factor of more than 1000 in terms  transcoding complexity and related impact on gateways !
And even with respect to AMR, G.722 or AMR-WB, transcoding from/to OPUS will still be more costly

Stéphane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tim Panton
Envoyé : mercredi 13 mars 2013 17:11
À : Bogineni, Kalyani
Cc : [email-masked]; MARJOU Xavier OLNC/OLN
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

I'd also like to point out that the "massive" transcoding cited already occurs between mobile devices that support various codecs (GSM, AMR etc) and the PSTN - (g711, g729) and the sky hasn't fallen yet.

Tim.

_________________________________________________________________________________________________________________________

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: Roman Shpount <[email-masked]>
Date: Wed, 13 Mar 2013 13:12:49 -0400

Normally, when implementing VoIP devices, unless they are intended for some
sort of walled garden, you try to support as many codecs as possible. This
increases your chances of interoperability with other devices and your
product adoption. In case of WebRTC, it would be adopted regardless of what
codecs are supported. The number of enabled devices would be so great that
all the legacy networks will have to adapt. This has some negative
implications to the legacy networks as far as quality and costs are
concerned, but these challenges are not insurmountable. So, taking this
into consideration, I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs
except MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that
would make browser manufacturers to change their mind? After all, this
represents additional cost to them with no direct benefit for the use cases
which are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next
few years, do support a reasonable set of other codecs in addition to MTI,
including G.722, AMR, AMR-WB, and may be Speex, . This would give me an
opportunity to migrate from devices that support legacy codecs to devices
that support Opus. The fact that different browser versions would support
different codec sets (like desktop browsers not supporting AMR) is not a
big issue, at least for me, since we always have G.711 or transcoding to
fall back to. The same goes for browsers fazing some of the legacy codecs
out in the future. The end result would still be better then 100% G.711 or
transcoding.
_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 17:29:33 +0000

If there is a business case for implementers to support other codecs for improved inteoperability with other networks and devices then they are very likely to do so.

From: Roman Shpount [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 12:12 PM Central Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Normally, when implementing VoIP devices, unless they are intended for some sort of walled garden, you try to support as many codecs as possible. This increases your chances of interoperability with other devices and your product adoption. In case of WebRTC, it would be adopted regardless of what codecs are supported. The number of enabled devices would be so great that all the legacy networks will have to adapt. This has some negative implications to the legacy networks as far as quality and costs are concerned, but these challenges are not insurmountable. So, taking this into consideration, I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs except MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that would make browser manufacturers to change their mind? After all, this represents additional cost to them with no direct benefit for the use cases which are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next few years, do support a reasonable set of other codecs in addition to MTI, including G.722, AMR, AMR-WB, and may be Speex, . This would give me an opportunity to migrate from devices that support legacy codecs to devices that support Opus. The fact that different browser versions would support different codec sets (like desktop browsers not supporting AMR) is not a big issue, at least for me, since we always have G.711 or transcoding to fall back to. The same goes for browsers fazing some of the legacy codecs out in the future. The end result would still be better then 100% G.711 or transcoding.
_____________
Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Mar 2013 17:36:57 +0000

The problem is that the business case for the device vendor or end user may not be the business case for the browser vendor.

To be honest this discussion goes round and round in circles, with people trying to say things are out of scope.

What I believe we need is something that encourages creation of APIs for embedded codecs in the devices. Those API's should then be made available within the browser.

This gets even more important when we get to video codecs. I am certainly interested in gateways from RTCWEB endpoints to other SIP based networks. Having to transcode from one video codec to another because of this impasse is a nightmare.

Someone has to break this loop.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 13 March 2013 17:30
To: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 13 Mar 2013 11:14:16 -0400

draft-marjou-rtcweb-audio-codecs-for-interop-01 is based on the recommendation
and clarification from the Chair regarding the conclusion (included below).

Regards,
Kalyani Bogineni

=====================

On Jan 28, 2013, at 1:12 AM, Magnus Westerlund <magnus.westerlund at ericsson.com> wrote:

> Hi,
>
> We chairs was considering inclusion in draft-ietf-webrtc-audio, but we
> didn't have any strong opinions on this. Based on that several WG
> participants thinks this should be an independent document, I thus
> decided that we will start out with an independent document. If the WG
> feels differently later we can always fold the text into the audio codec
> and processing requirements document.
>
> I would recommend that the individuals interested in contributing a
> codec writes an independent submission with focus on the codec
> considerations around the codec(s) they are interested in. Then we can
> merge this into a common WG document.
>
> Cheers
>
> Magnus

================

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: Wednesday, March 13, 2013 10:30 AM
To: Xavier Marjou; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Andrew

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xavier Marjou
Sent: Wednesday, March 13, 2013 9:15 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Any opinion on that?

Cheers,

Xavier

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Mar 2013 13:49:32 -0400

On 3/13/13 11:42, Olle E. Johansson wrote:
> I don't think everyone gets the that selecting a small subset as mandatory for WebRTC does NOT exclude all other codecs. Feel free to add everything you got. Have fun. Let the best mutual codec with the best mutual properties win the session.

Olle hit the nail squarely on the head. This is exactly the purpose of 
offer/answer negotiation: to find the best intersection of endpoint 
capabilities for the desired communication session. I'm bewildered by 
the fairly consistent misinterpretation that having an MTI codec somehow 
implies that every other codec becomes "MNTI".

/a

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Mar 2013 14:01:57 -0400

Let's not pretend that we got 500 different implementations of WebRTC and
that every one is making one. We got 4 or 5 that potentially matter, with 3
of them currently sharing the same code based for audio. All of the
currently available WebRTC implementations support G.711. Opus, and (most
likely deprecated in near future) ISAC. So far, the feedback I got was that
if codec is not MTI, it will not be implemented by the major browsers. For
instance, G.722 is part of current WebRTC code base, but it is disabled in
compile time from being accessible in the browsers.

So, if I, or anyone else, is implementing a web browser, I can add other
codecs, but this would serve no purpose whatsoever and is irrelevant to
this discussion.
_____________
Roman Shpount

On Wed, Mar 13, 2013 at 1:49 PM, Adam Roach <[email-masked]> wrote:

>> I don't think everyone gets the that selecting a small subset as
>> mandatory for WebRTC does NOT exclude all other codecs. Feel free to add
>> everything you got. Have fun. Let the best mutual codec with the best
>> mutual properties win the session.
>>
>
> capabilities for the desired communication session. I'm bewildered by the
> fairly consistent misinterpretation that having an MTI codec somehow
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 18:05:56 +0000

Keith

That is out of scope of IETF. What I think you are suggesting amounts to operating system standardisation.

If you believe in the market then the business case of the browser implementers and the device vendors should align with the interests of the users (I.e their customers) assuming the costs are not prohibitive.

Andrew

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 12:36 PM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

What I believe we need is something that encourages creation of APIs for embedded codecs in the devices. Those API’s should then be made available within the browser.

Keith

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 18:11:37 +0000

+1

It seems clear to me that other codecs will be included by most if not all RTCweb compliant browsers but which ones should be left up to implementers based on commercial decisions and which ones they include may change over time as codecs become obsoleted by new codecs. The MTIs are the ones that will always be supported to ensure interoperability other codecs will be supported when it makes sense.

Andrew 

----- Original Message -----
From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 12:49 PM Central Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01

/a

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Mar 2013 11:17:39 -0700

> http://www.3gpp.org/3GPP-Family-2012-Statistics

Then it will really be transformational for them to support Opus as a
webrtc requirement. I look forward to all these Opus devices

CB

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ron
> In particular the ones that show Opus->AMR and AMR->Opus is not
significantly worse than the intrinsic quality degradation suffered by
using AMR alone?
> Since there is never no cost impact to supporting additional features,
that would imply this is never mandatory ...
> I thought it was already quite clear all along, that people who want to
or have their own good reasons to are free to implement any other codecs
they please - and that they already have, and certainly will continue to do
so?
> That might be useful.  But 'mandating' something that the people who will
do it were going to do it anyway, and the people who were not are still not
going to do, doesn't seem to add any real value here to either users or
implementers.  It won't explain anything to anybody that they don't already
know if it is of any interest to them.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 13 Mar 2013 18:41:57 +0000

Hi All,

I thought the suggested text that came from Andrew Allen a couple of months ago was a good compromise.

I repeat it below.

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"

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

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: 13 March 2013 14:18
To: Bogineni, Kalyani
Cc: Xavier Marjou; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

> http://www.3gpp.org/3GPP-Family-2012-Statistics

Then it will really be transformational for them to support Opus as a webrtc requirement. I look forward to all these Opus devices

CB

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ron
> To: Xavier Marjou; [email-masked]<mailto:[email-masked]>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 13 Mar 2013 15:24:09 -0400

Hi,

I'd really like to understand how the chairs coming to the conclusion
that there was *no consensus* on recommended codecs can result in a
draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
3 new codecs MTI for a range of devices. I understand that it's an
individual draft and you can write whatever you like in there, but it
definitely goes against the result of the WG discussion.

Cheers,

	Jean-Marc

On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> usually use one of the following codecs: AMR, AMR-WB or G.722,
> which will result in massive transcoding when there will be
> communications between WebRTC endpoints and non-WebRTC endpoints.
> 
> - On one side, transcoding is bad for many reasons discussed in
> the draft (cost issues, intrinsic quality degradation, degraded 
> prepare something.  If the discussion of working group last call
> items runs short, we may be able to fit this in at that time or at
> the end of day one if its full agenda his finished.  This is not a
> commitment, however, so please try and get discussion on the list
> on the points from the draft you feel need resolution.
> 
> regards,
> 
> Ted
> 
> 
>> and G.722 as additional relevant voice codecs to satisfactorily
>> _______________________________________________ rtcweb mailing
>> list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ rtcweb mailing
> list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 13 Mar 2013 15:32:10 -0400

On 03/13/2013 12:11 PM, Tim Panton wrote:
>> Regards, Kalyani Bogineni
> 

Actually, the list of useful legacy codecs should also include Speex,
which is shipped in about 1B Flash-enabled browsers that may not have
WebRTC for some time.

Cheers,

	Jean-Marc

---

From: Tim Panton <[email-masked]>
Date: Wed, 13 Mar 2013 19:35:14 +0000

> And even with respect to AMR, G.722 or AMR-WB, transcoding from/to OPUS will still be more costly

When the PSTN <-> mobile network gateways were first set up the cpus were 1000x slower. 
No one seriously considered imposing G711 on the mobile network, because it was unsuitable.

T.

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 19:36:52 +0000

Hello

Our understanding is that the reason of the "no consensus" on additional recommended codecs was the additional costs for browsers.
The proposal is then to make these "MUST" fully conditional to the case of no (or very reduced) additional costs, when the codecs are already available on the device and when no additional license fee is required

We could even live with lower level of "requirements" with respectively May and Should (instead of Should and shall) but we think that this proposal is a way to take into account both browser manufacturers concerns on browsers costs and telcos concerns on transcoding costs and some other companies share this view.

Stéphane	

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jean-Marc Valin
Envoyé : mercredi 13 mars 2013 20:24
À : MARJOU Xavier OLNC/OLN
Cc : [email-masked]
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi,

I'd really like to understand how the chairs coming to the conclusion that there was *no consensus* on recommended codecs can result in a draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
3 new codecs MTI for a range of devices. I understand that it's an individual draft and you can write whatever you like in there, but it definitely goes against the result of the WG discussion.

Cheers,

	Jean-Marc

On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> _______________________________________________ rtcweb mailing list 
> _______________________________________________ rtcweb mailing list 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 13 Mar 2013 15:45:01 -0400

> installed, paid by the device vendor...).

I think this is the main faulty assumption here. "Royalties already
paid" does not imply "free". There's a real cost here because
supporting AMR, AMR-WB, G.722 and any other codecs added to that list
means that:
1) Someone has to write all the code for actually using these codecs
in their RTP stack.
2) There is no standard interface for accessing these codecs, so a
browser vendor would have to write code for each of these (often
undocumented) interface and *test* it on every device.
3) This code needs to be maintained and fixed for security
vulnerabilities.
4) If there's any issue (e.g. buffer overflow) in the platform
implementation of the codec, there's nothing the browser vendor can do
about it.

Oh, and that cost would be paid by pretty much all browser vendors
because they're all running on at least one platform that supports
each of these codecs.

Cheers,

	Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 13 Mar 2013 15:55:01 -0400

On 03/13/2013 03:36 PM, [email-masked] wrote:
> Our understanding is that the reason of the "no consensus" on 
> additional recommended codecs was the additional costs for
> browsers. The proposal is then to make these "MUST" fully
> conditional to the case of no (or very reduced) additional costs,
> when the codecs are already available on the device and when no
> additional license fee is required

I think this understanding is wrong, or else there would have been
consensus on recommending G.722. People (including myself) objected on
the basis that SHOULD/RECOMMENDED is too strong for an optional codec.

> We could even live with lower level of "requirements" with 
> respectively May and Should (instead of Should and shall) but we 
> think that this proposal is a way to take into account both
> browser manufacturers concerns on browsers costs and telcos
> concerns on transcoding costs and some other companies share this
> view.

It should all be MAY unless the WG agrees on making any of these
codecs a SHOULD -- which has not happened yet AFAIK.

Cheers,

	Jean-Marc

---

From: Tim Panton <[email-masked]>
Date: Wed, 13 Mar 2013 20:11:35 +0000

On 13 Mar 2013, at 19:45, Jean-Marc Valin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

And that assumes that the codec license signed by the hardware maker permits the use of these 'no-cost' in all the possible ways
the javascript user wants. E.g. is it limited in number of channels ? Is the license symmetrical wrt encoding and decoding ?
Is it available to 3rd party browser makers (eg chrome on blackberry? Or to products derived from the native browser browsers
or that embed browser objects (like cordova/phonegap) ?

T.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Mar 2013 16:44:07 -0400

G.722 is currently part of the browser code base and the cost of adding it
is the cost of adding one define. Availability of G.722 on the platform
itself is irrelevant. Cost of supporting it in the future is a different
matter, but it is fairly small and would be comparable to support cost of
G.711.

I would generally agree that in the long run having too many MTI codecs is
too restricting. What I want to see is some sort of commitment from the
browser manufacturers to support codecs beside MTI, especially initially,
until Opus support is more wide spread.
_____________
Roman Shpount

---

From: Michael Procter <[email-masked]>
Date: Wed, 13 Mar 2013 20:53:45 +0000

On 13 March 2013 17:49, Adam Roach <[email-masked]> wrote:
>> I don't think everyone gets the that selecting a small subset as mandatory
>> for WebRTC does NOT exclude all other codecs. Feel free to add everything
>> you got. Have fun. Let the best mutual codec with the best mutual properties
>> win the session.
>
> fairly consistent misinterpretation that having an MTI codec somehow implies
> that every other codec becomes "MNTI".
>

This seems to be the key point - we aren't dividing codecs into two
buckets, one labelled MUST implement and one labelled MUST NOT
implement.  Codecs outside the MTI set can still be implemented and
will be implemented if it makes sense to the implementer.

Conversely, even if you get an RFC with dozens of "MUST implement
<favourite codec>" in it, there won't be any protocol police to
enforce it if implementers decide it doesn't make sense (economic or
otherwise) for them to support those codecs.  There are plenty of
MUSTs in other RFCs that are routinely ignored, after all.

Michael

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 21:36:51 +0000

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the best venue for you to pursue it, however. Perhaps you as a mobile operator should rather set it as a requirement to your mobile device platforms that they open up the APIs to AMR and AMR-WB and that at least the in-built default browser needs to support it. If there are enough operators setting such requirements directly to the device and platform vendors, it probably has a bigger impact than an IETF RFC. Getting that support for user-installed additional browsers might be more difficult, but most mobile device users stick with the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the benefits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a bit too complicated. Hmm, perhaps we need to do an _informational_ RFC as something like "Recommendations for WebRTC on Mobile Devices" addressing the codec and perhaps other issues, that you could use as a reference in your requirements.  

Markus

>Of ext [email-masked]
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: [email-masked]
>Our understanding is that the reason of the "no consensus" on additional
>recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case of no
>(or very reduced) additional costs, when the codecs are already available on
>the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively May
>and Should (instead of Should and shall) but we think that this proposal is a
>way to take into account both browser manufacturers concerns on browsers
>costs and telcos concerns on transcoding costs and some other companies
>share this view.
>
>Stéphane
>
>
>
>
>
>
>De : [email-masked] [mailto:[email-masked]] De la part
>de Jean-Marc Valin Envoyé : mercredi 13 mars 2013 20:24 À : MARJOU Xavier
>OLNC/OLN Cc : [email-masked] Objet : Re: [rtcweb] Agenda time request for
>I'd really like to understand how the chairs coming to the conclusion that there
>was *no consensus* on recommended codecs can result in a draft that
>includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an individual
>draft and you can write whatever you like in there, but it definitely goes
>against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=
>=P8Jl
>-----END PGP SIGNATURE-----
>___________________________________________________________
>___________________________________________________________
>___
>
>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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Mar 2013 22:03:24 +0000

And too many people are hiding behind the statement "we don't own all the problem" to ensure there will be no solution to the problem.

At the end of the day, the example already given of someone having had to pay for an AMR licence for an i-phone should not exist, because it means there are now two licensed versions of that codec on the i-phone.

Regards

Keith

________________________________
From: Andrew Allen [mailto:[email-masked]]
Sent: 13 March 2013 18:06
To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Keith

Andrew

Keith

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 22:14:43 +0000

Dear Markus

Thanks for your attempt to help !

Of course each Telco can handle this directly with vendors and browsers manufacturers at business level. But I don't'think this need of interoperability with mobile devices is specific to Orange. I think all mobile operators will have the same issue and this is why standardization exist. It's most cost and time efficient to have one common way forward for all the industry.

Then if the issue is that "conditional MUST/SHOULD are a too complicated requirement. We could also live as a compromise with a formulation that has already been suggested on the reflector: 

"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"
If possible with the addition of 
This is especially the case for AMR, AMR-WB for interoperability with mobile devices and G.722 for interoperability with fixed DECT CAT-iq devices

Would it have one chance to reach consensus ?

I think this Group should at least make one small step so that the interoperability issue with mobile terminals be not fully ignored in the RTC Web specification considering the huge number of deployed devices. At least something must be written on this ! G.711 which is the only codec in addition to OPUS for interoperability purpose is not a proper answer to this.

Stéphane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 13 mars 2013 22:37
À : PROUST Stephane OLNC/OLPS; [email-masked]; MARJOU Xavier OLNC/OLN
Cc : [email-masked]
Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Stephane, Xavier,

Markus

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext [email-masked]
>additional recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case 
>of no (or very reduced) additional costs, when the codecs are already 
>available on the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively 
>May and Should (instead of Should and shall) but we think that this 
>proposal is a way to take into account both browser manufacturers 
>concerns on browsers costs and telcos concerns on transcoding costs and 
>some other companies share this view.
>
>Stéphane
>
>
>
>
>
>
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Jean-Marc Valin Envoyé : mercredi 13 mars 2013 20:24 À : MARJOU 
>Xavier OLNC/OLN Cc : [email-masked] Objet : Re: [rtcweb] Agenda time 
>request for
>> commitment, however, so please try and get discussion on the list on 
>> the points from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>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.
>
>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: Wed, 13 Mar 2013 22:40:57 +0000

No this wouldn't be acceptable to me. 

I don't see a reason to push a particular set of Codecs over any other set of codecs supported on the device. If the device supports the codecs and they are available to the browser then we should recommend that they be offered in the negotiation.

The marjou draft can advertise the merits and reasons why they are good codecs to support.

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01

Dear Markus

Stéphane

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

Hi Stephane, Xavier,

Markus

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 22:48:01 +0000

The reason is simply that AMR and AMR-WB are supported in billions of devices !

Stéphane

-----Message d'origine-----
De : Andrew Allen [mailto:[email-masked]] 
Envoyé : mercredi 13 mars 2013 23:41
À : PROUST Stephane OLNC/OLPS; [email-masked]; [email-masked]
Cc : MARJOU Xavier OLNC/OLN; [email-masked]
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01

Dear Markus

Stéphane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] Envoyé : mercredi 13 mars 2013 22:37 À : PROUST Stephane OLNC/OLPS; [email-masked]; MARJOU Xavier OLNC/OLN Cc : [email-masked] Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Stephane, Xavier,

Markus

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: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 23:00:54 +0000

I think the if available to the browser text applies to all codecs regardless of whether there are billions or only hundreds of other devices that support a codec.

It shoulld be appreciated that the number of devices supporting a particular codec are snapshots in time and this will likely change - either increasing or decreasing in the future and the specifications we write now should be as future proof as possible and not have a built in best before date.

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 05:48 PM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01

Stéphane

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01

Dear Markus

Stéphane

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

Hi Stephane, Xavier,

Markus

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 13 Mar 2013 23:25:09 +0000

On Mar 13, 2013, at 11:53 AM, Ron <[email-masked]> wrote:

> they could just, you know, call them on their cell phone normally … ?

Well I can think of one reason: it's a lot cheaper, when traveling internationally/roaming.  I.e., it's a lot cheaper today to use my cell phone with Skype-out on Wifi when I'm in another country, than it is to pay my cell carrier's price for international roaming charges... even though Skype also charges money for their Skype-out service.  But if my carrier offered me WebRTC-calls at a price closer to Skype's, for this roaming usage scenario, I'd use that instead.

But I'm not suggesting that means we do/do-not need to mandate other codecs - just pointing out there is a use-case for WebRTC on mobile phones making calls to other cell phones and the PSTN.  Personally I don't think the big fish for mobile happens to be *browsers* using WebRTC, but rather web-based resident *apps* based on things like PhoneGap/Titanium/etc.  But I'm not a market analyst for mobile, and I'd expect people in that space to know more about it.

-hadriel

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 14 Mar 2013 00:55:15 -0400

> The reason is simply that AMR and AMR-WB are supported in billions

Just curious, why exclude from the list other codecs with similar huge
deployment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

(sorry, if I missed someone's favorite codec in this list)

It's not at all clear to me what's so special that makes AMR, AMR-WB
and G.722 different from the other codecs in the list above. Not that
I insist on shipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs,
describing for each one the benefits of supporting it. Implementers
could then choose which of these they care about for their particular
situation.

Cheers,

	Jean-Marc

> Stéphane
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:[email-masked]] Envoyé : mercredi 13 mars 2013
> 23:41 À : PROUST Stephane OLNC/OLPS; [email-masked];
> [email-masked] Cc : MARJOU Xavier OLNC/OLN; [email-masked] 
> Objet : Re: [rtcweb] Agenda time request for
> I don't see a reason to push a particular set of Codecs over any
> other set of codecs supported on the device. If the device supports
> the codecs and they are available to the browser then we should
> recommend that they be offered in the negotiation.
> 
> ----- Original Message ----- From: [email-masked]
> [mailto:[email-masked]] Sent: Wednesday, March 13, 2013
> 05:14 PM Central Standard Time To: [email-masked]
> <[email-masked]>; [email-masked]
> <[email-masked]> Cc: MARJOU Xavier OLNC/OLN
> <[email-masked]>; [email-masked] <[email-masked]> 
> Of course each Telco can handle this directly with vendors and
> browsers manufacturers at business level. But I don't'think this
> need of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is
> why standardization exist. It's most cost and time efficient to
> have one common way forward for all the industry.
> 
> Then if the issue is that "conditional MUST/SHOULD are a too
> complicated requirement. We could also live as a compromise with a
> formulation that has already been suggested on the reflector:
> 
> "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" If possible with the addition of This
> is especially the case for AMR, AMR-WB for interoperability with
> mobile devices and G.722 for interoperability with fixed DECT
> CAT-iq devices
> 
> I think this Group should at least make one small step so that the
> interoperability issue with mobile terminals be not fully ignored
> in the RTC Web specification considering the huge number of
> deployed devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for
> interoperability purpose is not a proper answer to this.
> 
> Stéphane
> 
> -----Message d'origine----- De : [email-masked]
> [mailto:[email-masked]] Envoyé : mercredi 13 mars 2013
> 22:37 À : PROUST Stephane OLNC/OLPS; [email-masked]; MARJOU
> Xavier OLNC/OLN Cc : [email-masked] Objet : RE: [rtcweb] Agenda
> time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hi Stephane, Xavier,
> 
> I understand the intent of your proposal. I'm not sure if the IETF
> is the best venue for you to pursue it, however. Perhaps you as a
> mobile operator should rather set it as a requirement to your
> mobile device platforms that they open up the APIs to AMR and
> AMR-WB and that at least the in-built default browser needs to
> support it. If there are enough operators setting such requirements
> directly to the device and platform vendors, it probably has a
> bigger impact than an IETF RFC. Getting that support for
> user-installed additional browsers might be more difficult, but
> most mobile device users stick with the default browser anyway.
> 
> The RTCWEB codec document needs to definitely explain this case and
> the benefits, but the conditional MUSTs or SHOULDs you are
> proposing are perhaps a bit too complicated. Hmm, perhaps we need
> to do an _informational_ RFC as something like "Recommendations for
> WebRTC on Mobile Devices" addressing the codec and perhaps other
> issues, that you could use as a reference in your requirements.
> 
> Markus
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ext
>> [email-masked] Sent: 13 March, 2013 21:37 To:
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: [email-masked] 
>> draft-marjou-rtcweb-audio- codecs-for-interop-01
>> 
>> Hello
>> 
>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Jean-Marc Valin
>> Envoyé : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN
>> Cc : [email-masked] Objet : Re: [rtcweb] Agenda time request
>> for draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
> Hi,
> 
> I'd really like to understand how the chairs coming to the
> conclusion that there was *no consensus* on recommended codecs can
> result in a draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes 3 new codecs MTI for a range of devices. I
> understand that it's an individual draft and you can write whatever
> you like in there, but it definitely goes against the result of the
> WG discussion.
> 
> Cheers,
> 
> Jean-Marc
> 
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation
>>>> that I had prepared for yesterday's session:
>>>> 
>>>> - The co-authors want to underline that non-WebRTC voice
>>>> endpoints usually use one of the following codecs: AMR,
>>>> AMR-WB or G.722, which will result in massive transcoding
>>>> when there will be communications between WebRTC endpoints
>>>> and non-WebRTC endpoints.
>>>> 
>>>> - On one side, transcoding is bad for many reasons discussed
>>>> in the draft (cost issues, intrinsic quality degradation,
>>>> degraded interactivity, fallback from HD to G.711...);
>>>> 
>>>> - On the other side, it is recognized that implementing
>>>> additional codecs in the browsers can generate additional
>>>> costs.
>>>> 
>>>> - In order to reach a compromise, we would like to add some
>>>> text in the WG draft draft-ietf-rtcweb-audio providing
>>>> incentives for the browser to use these three codecs: make
>>>> them mandatory to implement when there is no cost impact on
>>>> the browser (e.g. if codec already installed, paid by the
>>>> device vendor...).
>>>> 
>>>> Any opinion on that?
>>>> 
>>>> Cheers,
>>>> 
>>>> Xavier
>>>> 
>>>> (c.f.
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>
>>>> 
)
>>>> 
>>>> 
>>>> 
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Magnus and I discussed this this morning, and we encourage
>>>> you to prepare something.  If the discussion of working group
>>>> last call items runs short, we may be able to fit this in at
>>>> that time or at the end of day one if its full agenda his
>>>> finished.  This is not a commitment, however, so please try
>>>> and get discussion on the list on the points from the draft
>>>> you feel need resolution.
>>>> 
>>>> regards,
>>>> 
>>>> Ted
>>>> 
>>>> 
>>>>> The document  presents use-cases underlining why WebRTC
>>>>> needs
>>>> AMR-WB,  AMR
>>>>> and G.722 as additional relevant voice codecs to
>>>>> satisfactorily ensure interoperability with existing
>>>>> systems.
>>>>> 
>>>>> 
>>>>> 
>>>>> A 10-minute time slot should be sufficient for presentation
>>>>> and
>>>> discussion.
>>>>> 
>>>>> 
>>>>> 
>>>>> Regards
>>>>> 
>>>>> 
>>>>> 
>>>>> -Espen
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> list [email-masked] 
>> ___________________________________________________________ ___
>> 
>> 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.
>> 
>> list [email-masked] 
> 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.
> 
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.
> 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: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Mar 2013 08:51:12 +0100

> The reason is simply that AMR and AMR-WB are supported in billions of devices !
I think it's time to stop discussing historical numbers, current numbers and future numbers of installed codecs in various devices. We're all impressed, but it doesn't seem to change our position on the MTI codec list.

This is a very complex matrix and the codec landscape is every changing. That's why the offer/answer exchange is open for future additions. SIP only mandated a very small set of codecs in RFC 3261 over ten years ago. That did not stop the use of AMR, G722, H.264 or other codecs in SIP devices today. I've even seen Opus being used in SIP without updating RFC 3261. 

I'm pretty sure I will see quite a lot of offers with both AMR and H264 in WebRTC, as I have met them many times in my SIP life.

It seems that we need to clarify this openness to use any codec in the specification, since it seems to be widely misunderstood.

/O

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 14 Mar 2013 10:58:52 +0100

On 2013-03-13 23:14, [email-masked] wrote:
...
> to maximize the possibility to establish the session without the need
> for audio transcoding"

To me, that sounds reasonable. The document could also reference some 
informational RFC (to be written) that list codecs, and under what 
circumstances they are suitable.

Stefan

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Mar 2013 11:04:57 +0100

14 mar 2013 kl. 10:58 skrev Stefan Håkansson LK <[email-masked]>:

> To me, that sounds reasonable. The document could also reference some informational RFC (to be written) that list codecs, and under what circumstances they are suitable.

That informational RFC would count as training material, but that never hurts.

I agree with this - but please change "audio codecs" to "multimedia codecs" since we now have both audio, video, text and other "codecs" under discussion. Also "the browser" is too limiting, since this applies to every piece of software using WebRTC, even though browsers have the highest priority.

/O

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 14 Mar 2013 11:42:03 +0100

On 2013-03-14 11:04, Olle E. Johansson wrote:
>> On 2013-03-13 23:14, [email-masked] wrote: ...
>>>
>>> complicated requirement. We could also live as a compromise with
>>> a formulation that has already been suggested on the reflector:
>>>
>>> "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"
>>
>> To me, that sounds reasonable. The document could also reference
>> some informational RFC (to be written) that list codecs, and under
>> what circumstances they are suitable.
>
> I agree with this - but please change "audio codecs" to "multimedia
> codecs" since we now have both audio, video, text and other "codecs"
> under discussion.

I think the intention was to add this text to draft-ietf-rtcweb-audio-01 
which would mean that only audio is in scope. But I agree, the sentence 
is equally valid for video.

> Also "the browser" is too limiting, since this
> applies to every piece of software using WebRTC, even though browsers
> have the highest priority.

I agree to this.

---

From: Tim Panton <[email-masked]>
Date: Thu, 14 Mar 2013 11:01:27 +0000

> It seems that we need to clarify this openness to use any codec in the specification, since it seems to be widely misunderstood.

What this discussion leads to is the need for application authors to be able to dynamically add codecs.
We need an API that supports codec insertion by the hosting web-site. 
This would have 2 advantages:
	1) sites with specific needs would be able to supply codecs that were licensed per-user 
(so MNOs could supply AMR-WB for the duration of a call, even to devices that don't normally support it - e.g. laptops )
(Cisco could supply h264 for a webex session)
	2) we future proof the WebRTC API - so when a new codec arrives that is especially good for watching small white dots moving at high speed,
the golf sites can use it.

In essence, extending the API using technology like Google's NaCl to deliver new codec, this decouples the supported  codec selection decision from the browser makers and pushes it up to the Application vendors.

Note, I'm not saying we should do this now. I am saying we should do this as a revision to webRTC - and yes, this discussion probably belongs in w3c land.

Tim.

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 12:35:45 +0000

Hello 

The short list is aligned to what is specified in 3GPP (mobile) and CAT-iq (fixed). Check the related service specifications!
The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to minimize interop issues and transcoding costs for telco services. 
It's not a question of what's the favourite codec for a given application. It's interop with billions of mobile phones and with fixed terminals in legacy telephony services. 

Stéphane

-----Message d'origine-----
De : Jean-Marc Valin [mailto:[email-masked]] 
Envoyé : jeudi 14 mars 2013 05:55
À : PROUST Stephane OLNC/OLPS
Cc : Andrew Allen; [email-masked]; MARJOU Xavier OLNC/OLN; [email-masked]
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

> The reason is simply that AMR and AMR-WB are supported in billions of 

Just curious, why exclude from the list other codecs with similar huge deployment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

It's not at all clear to me what's so special that makes AMR, AMR-WB and G.722 different from the other codecs in the list above. Not that I insist on shipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs, describing for each one the benefits of supporting it. Implementers could then choose which of these they care about for their particular situation.

Cheers,

	Jean-Marc

> [email-masked] Cc : MARJOU Xavier OLNC/OLN; [email-masked] Objet 
> : Re: [rtcweb] Agenda time request for
> I don't see a reason to push a particular set of Codecs over any other 
> set of codecs supported on the device. If the device supports the 
> codecs and they are available to the browser then we should recommend 
> that they be offered in the negotiation.
> 
> <[email-masked]>; [email-masked] <[email-masked]> 
> browsers manufacturers at business level. But I don't'think this need 
> of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is why 
> standardization exist. It's most cost and time efficient to have one 
> common way forward for all the industry.
> 
> audio transcoding" If possible with the addition of This is especially 
> the case for AMR, AMR-WB for interoperability with mobile devices and 
> G.722 for interoperability with fixed DECT CAT-iq devices
> 
> interoperability issue with mobile terminals be not fully ignored in 
> the RTC Web specification considering the huge number of deployed 
> devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for interoperability 
> purpose is not a proper answer to this.
> 
> Stéphane
> 
> Xavier OLNC/OLN Cc : [email-masked] Objet : RE: [rtcweb] Agenda time 
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hi Stephane, Xavier,
> 
> I understand the intent of your proposal. I'm not sure if the IETF is 
> the best venue for you to pursue it, however. Perhaps you as a mobile 
> operator should rather set it as a requirement to your mobile device 
> platforms that they open up the APIs to AMR and AMR-WB and that at 
> least the in-built default browser needs to support it. If there are 
> enough operators setting such requirements directly to the device and 
> platform vendors, it probably has a bigger impact than an IETF RFC. 
> Getting that support for user-installed additional browsers might be 
> more difficult, but most mobile device users stick with the default 
> browser anyway.
> 
> the benefits, but the conditional MUSTs or SHOULDs you are proposing 
> are perhaps a bit too complicated. Hmm, perhaps we need to do an 
> _informational_ RFC as something like "Recommendations for WebRTC on 
> Mobile Devices" addressing the codec and perhaps other issues, that 
> you could use as a reference in your requirements.
> 
> Markus
> 
> 
>> The proposal is then to make these "MUST" fully conditional to the 
>> case of no (or very reduced) additional costs, when the codecs are 
>> already available on the device and when no additional license fee is 
>> required
>> 
>> think that this proposal is a way to take into account both browser 
>> manufacturers concerns on browsers costs and telcos concerns on 
>> transcoding costs and some other companies share this view.
>> 
>> Stéphane
>> 
>> 
>> 
>> 
>> 
>> 
>> [mailto:[email-masked]] De la part de Jean-Marc Valin Envoyé 
>> : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN Cc : 
>> [email-masked] Objet : Re: [rtcweb] Agenda time request for 
)
>> 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 
>> 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.
>> 
> ______________________________________________________________________
> ___________________________________________________
>
> 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 
> 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.
> 
> 
> ______________________________________________________________________
> ___________________________________________________
>
> 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 
> 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: "Espen Berger (espeberg)" <[email-masked]>
Date: Thu, 14 Mar 2013 12:59:46 +0000

I support this statement. 

The reason to support AMR, AMR-WB and G722 is to have a minimal set of common audio codecs available to avoid transcoding in the common cases. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14. mars 2013 13:36
To: Jean-Marc Valin
Cc: [email-masked]; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello 

Stéphane

-----Message d'origine-----
De : Jean-Marc Valin [mailto:[email-masked]] Envoyé : jeudi 14 mars 2013 05:55 À : PROUST Stephane OLNC/OLPS Cc : Andrew Allen; [email-masked]; MARJOU Xavier OLNC/OLN; [email-masked] Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Cheers,

	Jean-Marc

)

---

From: Koen Vos <[email-masked]>
Date: Thu, 14 Mar 2013 20:32:20 +0000

> It's interop with billions of mobile phones and with fixed terminals in legacy telephony services.

The problem is that WebRTC and legacy services live in separate networks: the open Web vs proprietary Telco networks.

WebRTC connecting to a Telco network would have to go through a Gateway.  The PSTN termination providers who run these Gateways support G.711, G.729 and perhaps some other  codecs like iLBC.  They do not, however, support the codecs you are advocating for.

The lack of support for Transcoding-Free Operation by Telcos to the rest of the world has been hurting interop voice quality for a long time, but unfortunately we can't fix that here at the IETF.

We can fit our cars with your costly railroad wheels, but you still wouldn't let us on your tracks.

koen.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14. mars 2013 13:36
To: Jean-Marc Valin
Cc: [email-masked]; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stéphane

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

Cheers,

        Jean-Marc

)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Mar 2013 16:41:55 -0400

On Thu, Mar 14, 2013 at 4:32 PM, Koen Vos <[email-masked]> wrote:

> WebRTC connecting to a Telco network would have to go through a Gateway.
>  The PSTN termination providers who run these Gateways support G.711, G.729
> and perhaps some other  codecs like iLBC.  They do not, however, support
> the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the rest
> of the world has been hurting interop voice quality for a long time, but
> unfortunately we can't fix that here at the IETF.
>
I would got to agree with you regarding cell phone operators, since we've
been trying to get access to native AMR-WB for years.

On the other hand, this is kind of interesting to hear coming from someone
from Skype, which does not allow connections using SILK from outside of
their own network, which has been hurting interop voice quality for a long
time as well.

Finally, it is possible to connect to almost any hosted PBX provider, as
well as quite a few premise based PBXs, using G.722, as long as their end
points support it.
_____________
Roman Shpount

---

From: Koen Vos <[email-masked]>
Date: Thu, 14 Mar 2013 20:57:06 +0000

> On the other hand, this is kind of interesting to hear coming from someone from Skype, which
> does not allow connections using SILK from outside of their own network, which has been
> hurting interop voice quality for a long time as well.

Skype has ever used "interop with the 100s of millions of our endpoints" as an argument :)

koen.

________________________________
From: Roman Shpount
Sent: Thursday, March 14, 2013 1:41 PM
To: Koen Vos
Cc: Espen Berger (espeberg); [email-masked]; [email-masked]; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

On Thu, Mar 14, 2013 at 4:32 PM, Koen Vos <[email-masked]<mailto:[email-masked]>> wrote:
WebRTC connecting to a Telco network would have to go through a Gateway.  The PSTN termination providers who run these Gateways support G.711, G.729 and perhaps some other  codecs like iLBC.  They do not, however, support the codecs you are advocating for.

I would got to agree with you regarding cell phone operators, since we've been trying to get access to native AMR-WB for years.

On the other hand, this is kind of interesting to hear coming from someone from Skype, which does not allow connections using SILK from outside of their own network, which has been hurting interop voice quality for a long time as well.

Finally, it is possible to connect to almost any hosted PBX provider, as well as quite a few premise based PBXs, using G.722, as long as their end points support it.
_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Thu, 14 Mar 2013 21:09:35 +0000

Koen is right that there are many more obstacles to RTCweb and legacy network interop than just a common codec. First there will need to be RTCweb signaling gateways to interface between the RTCweb signaling and the legacy networks (SIP, H.323 etc) and there will need to be in place mechanisms for peering, federation and address resolution between networks as well as service agreements in place between the players.

Until those are resolved supporting codecs used in those networks is pointless.

Andrew

----- Original Message -----
From: Koen Vos [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
To: Espen Berger (espeberg) <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; MARJOU Xavier OLNC/OLN <[email-masked]>
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

koen.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14. mars 2013 13:36
To: Jean-Marc Valin
Cc: [email-masked]; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stéphane

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

Cheers,

        Jean-Marc

)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Mar 2013 17:17:11 -0400

On Thu, Mar 14, 2013 at 5:09 PM, Andrew Allen <[email-masked]> wrote:

>
> Koen is right that there are many more obstacles to RTCweb and legacy
> network interop than just a common codec. First there will need to be
> RTCweb signaling gateways to interface between the RTCweb signaling and the
> legacy networks (SIP, H.323 etc) and there will need to be in place
> mechanisms for peering, federation and address resolution between networks
> as well as service agreements in place between the players.
>

These issues are resolved. See one example here: http://webrtc2sip.org/.
These solutions do suffer from the need to transcode, this is why this
codec discussion has been going on.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 14 Mar 2013 22:37:29 +0000

> Until those are resolved supporting codecs used in those networks is pointless.

There are already WebRTC-SIP gateways, as I think you know.  I know of two SBC vendors who are in customer labs with it, for example, and there are probably more.  And yes at least one of them, and probably both, can transcode the audio... though it's by no means free.  I don't know if the business case justifies the cost or not for WebRTC use-cases - it appears to in some cases, not others.

It costs far more than has been discussed on this list though, because we think like engineers and consider the cost as a CAPEX issue; whereas in practice the OPEX costs often dwarf the CAPEX ones.  In some data centers, for example, the local Real-Estate costs dwarf CAPEX too, and using less rack-space can pay for a product in no time. (there's an entire company out there that built its business leveraging this fact, replacing POTS switches with much-higher-density ones purely based on rack-space usage savings)

Anyway... moving on to your other point of federation/peering/etc. - I think the use-case that mobile operators have in mind is fairly obvious, and it clearly doesn't have that problem.  Whether you agree with helping that use-case or not is up to you and the rest of this WG, of course.  I'm just noting that peering isn't an obstacle for it.

-hadriel
p.s. Transcoding video, on the other hand, is untenable for pretty much anyone.  I have never heard of a business-case which justifies it, because it simply doesn't scale.  Except for maybe companies that live on other revenue sources, for whom all of this stuff is a rounding error in their IT budget. ;)

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 10:44:31 +0100

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. März 2013 22:10
> An: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [rtcweb] Agenda time request for
> Koen is right that there are many more obstacles to RTCweb
> and legacy network interop than just a common codec. First
> there will need to be RTCweb signaling gateways to interface
> between the RTCweb signaling and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for
> peering, federation and address resolution between networks
> To: Espen Berger (espeberg) <[email-masked]>;
> [email-masked] <[email-masked]>
> The problem is that WebRTC and legacy services live in
> separate networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through
> a Gateway.  The PSTN termination providers who run these
> Gateways support G.711, G.729 and perhaps some other  codecs
> like iLBC.  They do not, however, support the codecs you are
> advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos
> to the rest of the world has been hurting interop voice
> quality for a long time, but unfortunately we can't fix that
> here at the IETF.
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of
> codecs to minimize interop issues and transcoding costs for
> telco services.
> It's not a question of what's the favourite codec for a given
> application. It's interop with billions of mobile phones and
> with fixed terminals in legacy telephony services.
>
> Stéphane
>
> De : Jean-Marc Valin [mailto:[email-masked]] Envoyé :
> jeudi 14 mars 2013 05:55 À : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; [email-masked]; MARJOU Xavier
> OLNC/OLN; [email-masked] Objet : Re: [rtcweb] Agenda time
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with
> similar huge deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> It's not at all clear to me what's so special that makes AMR,
> AMR-WB and G.722 different from the other codecs in the list
> above. Not that I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more
> codecs, describing for each one the benefits of supporting
> it. Implementers could then choose which of these they care
> about for their particular situation.
>
> Cheers,
>
>         Jean-Marc
>
> > Stéphane
> >
> >
> <[email-masked]>
> > Cc: MARJOU Xavier OLNC/OLN <[email-masked]>;
> [email-masked]
> > <[email-masked]>
> proposing
> browsers.
> conclusion
> endpoints
> additional
> diffuses,
> 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.
> >
> >
> diffuses,
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=
> =K56v
> ______________________________________________________________
> 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
> 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.
>
> 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: Adam Roach <[email-masked]>
Date: Fri, 15 Mar 2013 08:42:17 -0400

> Koen is right that there are many more obstacles to RTCweb and legacy network interop than just a common codec. First there will need to be RTCweb signaling gateways to interface between the RTCweb…

We had this mostly working at the SIPit in Boston, using the SIP over 
Websockets spec. The only reason we weren't actually setting calls up 
was that we couldn't find any clients there that supported both ICE and 
DTLS-SRTP. What's neat is that this isn't even really "gatewaying" in 
the way that you mean it -- all you need is a SIP proxy that supports 
one more (easy-to-implement) transport protocol.

And once you hit that proxy, all of the peering, federation, and address 
resolution solutions developed for SIP apply.

I don't think this points to a need to push AMR into the web browsers, 
mind you. To take Justin's earlier point a few steps further: if we're 
going on number of shipping units, the mere existence of Chrome and 
Firefox's WebRTC implementation means that the number of deployed Opus 
codecs far overwhelms the number of deployed AMR codecs. Appeals to the 
size of codec deployment would more reasonably reach the conclusion that 
Opus should be MTI for the next 3GPP release. ;-)

/a

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 15 Mar 2013 14:51:05 +0100

Again, this threads deals with interoperability (i.e. communications
between a WebRTC device and a non-WebRTC device).
Non-WebRTC devices mean nearly all of existing phones in the world; they
are already deployed and there's no way to upgrade them all with OPUS on
them.

Xavier

---

From: Andrew Allen <[email-masked]>
Date: Fri, 15 Mar 2013 13:55:13 +0000

My response was directed to the current deployment situation and the comment/concern that currently the pre standard RTCweb browser implementations do not support Codecs used in some legacy networks.

While the technology may be there and the products even available they are not widely deployed today so currently there is not a business case for browser vendors to include these codecs as today practical interoperability is not possible.

Right now browser implementors are focused solely on achieving interoperability between browsers I expect. The additional codecs for legacy interop will I expect come in the future when the infrastructure is deployed to make this possible and if the right business case is there to make it commercially viable.

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 05:37 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

-hadriel

---

From: Andrew Allen <[email-masked]>
Date: Fri, 15 Mar 2013 14:55:54 +0000

Roland

I have proposed that we add the following text to address the interoperability concerns

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

The MTI Audio Codecs are defined to ensure a basic level of interoperability and will need to be always supported for that reason. Support for additional audio codecs is an implementation and business case decision and the additional audio codecs that it makes sense to support will change over time (as codecs become obsolete and new ones are developed and deployed. So additional audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Andrew Allen
> RTCweb signaling gateways to interface between the RTCweb signaling 
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering, 
> federation and address resolution between networks as well as service 
> agreements in place between the players.
>
> The problem is that WebRTC and legacy services live in separate 
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a 
> Gateway.  The PSTN termination providers who run these Gateways 
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They 
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the 
> rest of the world has been hurting interop voice quality for a long 
> time, but unfortunately we can't fix that here at the IETF.
>
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to 
> minimize interop issues and transcoding costs for telco services.
> application. It's interop with billions of mobile phones and with 
> fixed terminals in legacy telephony services.
>
> Stéphane
>
> Andrew Allen; [email-masked]; MARJOU Xavier OLNC/OLN; 
> should not
> should not
> non-public information.
> 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 
> should not
> be distributed, used or copied without authorisation.
> non-public information.
> 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

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 15:50:18 +0000

Hello

As mentioned earlier, this kind of general statement makes sense and would be acceptable for us only if it gives some minimum guidance on what "suitable" means. It means: the codecs that are especially important to be considered because their support would solve the interoperability issue for a huge number of calls and because they can be made available to the browsers on a high number of devices: 

"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 especially the case for AMR and AMR-WB for interoperability with 3GPP mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-iq devices

Stephane Proust

-----Message d'origine-----
De : Andrew Allen [mailto:[email-masked]] 
Envoyé : vendredi 15 mars 2013 15:56
À : [email-masked]; [email-masked]; [email-masked]; PROUST Stephane OLNC/OLPS
Cc : MARJOU Xavier OLNC/OLN; [email-masked]
Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Andrew Allen <[email-masked]>
Date: Fri, 15 Mar 2013 15:58:23 +0000

Suitable to me means suitable for the application context i.e if the application is conversational real time audio then all audio codecs suitable for conversational real time audio the browser has the ability to use are recommended to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitability for the application apply and we shouldn't give the impression that its more important to include some codecs than others that are available to the browser to use. 

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

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

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Ralph Giles <[email-masked]>
Date: Fri, 15 Mar 2013 12:07:54 -0400

On 13-03-13 2:01 PM, Roman Shpount wrote:

> All of the currently available WebRTC implementations support G.711.
> Opus, and (most likely deprecated in near future) ISAC.

Our implementation in Firefox doesn't support ISAC.

 -r

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 16:08:17 +0000

>>we shouldn't give the impression that its more important to include some codecs than others that are available to the browser to use.

But Why shouldn't we give that impression ?

Because obviously YES it is more important to support codecs that are implemented in billions of devices and the support of which will improve the quality for millions of customers and reduce the costs in networks than codecs of specific and limited usage.

And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't think the importance of these codecs can ben challenged for the future

Stéphane

-----Message d'origine-----
De : Andrew Allen [mailto:[email-masked]] 
Envoyé : vendredi 15 mars 2013 16:58
À : PROUST Stephane OLNC/OLPS; [email-masked]; [email-masked]; [email-masked]
Cc : MARJOU Xavier OLNC/OLN; [email-masked]
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

-----Message d'origine-----
De : Andrew Allen [mailto:[email-masked]] Envoyé : vendredi 15 mars 2013 15:56 À : [email-masked]; [email-masked]; [email-masked]; PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN; [email-masked] Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Andrew Allen <[email-masked]>
Date: Fri, 15 Mar 2013 16:08:33 +0000

Based on the clarification I just made I propose revised text

"If other audio codecs suitable for use by the application 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."

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

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

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Fri, 15 Mar 2013 12:46:34 -0400

Here is a slight variation with an example for clarifying what 'suitable' means.

"If other audio codecs suitable for use by the application are available to the browser (e.g. AMR/AMR-WB for 3GPP devices) 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."

Regards,
Kalyani Bogineni

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time       request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

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

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Mar 2013 12:52:45 -0400

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

For the record, I find this statement non-objectionable.

/a

---

From: Roman Shpount <[email-masked]>
Date: Fri, 15 Mar 2013 12:53:40 -0400

Out of curiosity, since you are pushing so hard for AMR/AMR-WB support, how
would one connect to devices on Orange network using these codecs? Is there
currently a way to connect without going through G.711 transcoding?
_____________
Roman Shpount

On Fri, Mar 15, 2013 at 11:50 AM, <[email-masked]> wrote:

> Hello
>
> As mentioned earlier, this kind of general statement makes sense and would
> be acceptable for us only if it gives some minimum guidance on what
> "suitable" means. It means: the codecs that are especially important to be
> considered because their support would solve the interoperability issue for
> a huge number of calls and because they can be made available to the
> browsers on a high number of devices:
>
> "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 especially the case for AMR and AMR-WB for interoperability with
> 3GPP mobile devices and G.722 for interoperability with fixed ETSI/DECT
> CAT-iq devices
>
>
> Stephane Proust
>
>
>
> Objet : RE: [rtcweb] Agenda time request for
> "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."
>
> The MTI Audio Codecs are defined to ensure a basic level of
> interoperability and will need to be always supported for that reason.
> Support for additional audio codecs is an implementation and business case
> decision and the additional audio codecs that it makes sense to support
> will change over time (as codecs become obsolete and new ones are developed
> and deployed. So additional audio codecs should not be specified in the
> RTCweb RFCs.
>
> Andrew
>
> Subject: AW: [rtcweb] Agenda time request for
> 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.
>
>
> 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,
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 17:59:37 +0100

Hi,

+1
I support to have a general statement as given below and I very much support to state which cases and codecs would be important to be supported. This also would make clear to the implementer what relevance and potential the implementation of a certain codec for WebRTC has.

Best regards,
Bernhard Feiten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Freitag, 15. März 2013 16:50
To: Andrew Allen; Jesske, Roland; [email-masked]; [email-masked]
Cc: [email-masked]; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

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

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Andrew Allen <[email-masked]>
Date: Fri, 15 Mar 2013 17:03:28 +0000

Stephane

I don't think the numbers of devices currently supported is relevant. As has already been pointed out these are snapshots in time. We are writing a standard for the next 20 years at least and 20 years ago GSM would have been one of the codecs that some people would have been advocating as the most important.

I think realistically browsers are not likely to natively support encumbered codecs like AMR regardless whether we recomend it in RTCweb or not, but all mobile devices will support AMR (at least in the near term) and I fully expect those devices will have a browser that has access to the embedded AMR codec which will I think mostly address your use case.

Andrew. 

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 11:08 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

Stéphane

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hello

Stephane Proust

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

Roland

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hi Andrew,

Roland

---

From: Koen Vos <[email-masked]>
Date: Fri, 15 Mar 2013 17:34:10 +0000

Xavier Marjou wrote:
> Again, this threads deals with interoperability (i.e. communications between a WebRTC device and a non-WebRTC device).

Given that it's currently impossible to connect to a mobile phone in a legacy network without transcoding, could you tell us a bit about Orange/3GPP's plans to provide the kind of interop you describe?  If those plans  don't exist, how could this thread (or the IETF) be dealing with such interoperability?

koen.

________________________________
From: [email-masked] on behalf of Xavier Marjou
Sent: Friday, March 15, 2013 6:51 AM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Again, this threads deals with interoperability (i.e. communications between a WebRTC device and a non-WebRTC device).
Non-WebRTC devices mean nearly all of existing phones in the world; they are already deployed and there's no way to upgrade them all with OPUS on them.

Xavier

On Fri, Mar 15, 2013 at 1:42 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

I don't think this points to a need to push AMR into the web browsers, mind you. To take Justin's earlier point a few steps further: if we're going on number of shipping units, the mere existence of Chrome and Firefox's WebRTC implementation means that the number of deployed Opus codecs far overwhelms the number of deployed AMR codecs. Appeals to the size of codec deployment would more reasonably reach the conclusion that Opus should be MTI for the next 3GPP release. ;-)

/a

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 15 Mar 2013 13:48:29 -0400

Seriously, I think this whole issue is adequately addressed by this
audio draft ticket by Bernard:
http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12

Cheers,

	Jean-Marc

On 03/15/2013 12:08 PM, [email-masked] wrote:
>>> we shouldn't give the impression that its more important to
>>> include some codecs than others that are available to the
>>> browser to use.
> 
> Because obviously YES it is more important to support codecs that
> are implemented in billions of devices and the support of which
> will improve the quality for millions of customers and reduce the
> costs in networks than codecs of specific and limited usage.
> 
> And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't
> think the importance of these codecs can ben challenged for the
> future
> 
> Stéphane
> 
> 
> [mailto:[email-masked]] Envoyé : vendredi 15 mars 2013
> 16:58 À : PROUST Stephane OLNC/OLPS; [email-masked];
> [email-masked]; [email-masked] Cc : MARJOU Xavier OLNC/OLN;
> Suitable to me means suitable for the application context i.e if
> the application is conversational real time audio then all audio
> codecs suitable for conversational real time audio the browser has
> the ability to use are recommended to be included in the offer.
> 
> I don't agree to mention specific codecs - all codecs that meet the
> suitability for the application apply and we shouldn't give the
> impression that its more important to include some codecs than
> others that are available to the browser to use.
> 
> 
> [mailto:[email-masked]] Sent: Friday, March 15, 2013
> 10:50 AM Central Standard Time To: Andrew Allen;
> [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>; [email-masked] <[email-masked]> Cc:
> MARJOU Xavier OLNC/OLN <[email-masked]>; [email-masked]
> <[email-masked]> Subject: RE: [rtcweb] Agenda time	request	for
> As mentioned earlier, this kind of general statement makes sense
> and would be acceptable for us only if it gives some minimum
> guidance on what "suitable" means. It means: the codecs that are
> especially important to be considered because their support would
> solve the interoperability issue for a huge number of calls and
> because they can be made available to the browsers on a high number
> of devices:
> 
> need for audio transcoding." This is especially the case for AMR
> and AMR-WB for interoperability with 3GPP mobile devices and G.722
> for interoperability with fixed ETSI/DECT CAT-iq devices
> 
> 
> Stephane Proust
> 
> 
> 
> [mailto:[email-masked]] Envoyé : vendredi 15 mars 2013 15:56
> À : [email-masked]; [email-masked]; [email-masked];
> PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN;
> [email-masked] Objet : RE: [rtcweb] Agenda time request for
> need for audio transcoding."
> 
> interoperability and will need to be always supported for that
> reason. Support for additional audio codecs is an implementation
> and business case decision and the additional audio codecs that it
> makes sense to support will change over time (as codecs become
> obsolete and new ones are developed and deployed. So additional
> audio codecs should not be specified in the RTCweb RFCs.
> 
> Andrew
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Friday, March 15, 2013 5:45 AM 
> To: Andrew Allen; [email-masked]; [email-masked];
> [email-masked] Cc: [email-masked];
> [email-masked] Subject: AW: [rtcweb] Agenda time request for
> Hi Andrew, but where will you start and where will you end. The
> codec discussion appears now so why not try to solve this now? And
> one proposal is to use these codecs and I fully support it.
> 
> Roland
> 
>> -----Ursprüngliche Nachricht----- Von: [email-masked]
>> [mailto:[email-masked]] Im Auftrag von Andrew Allen 
>> Gesendet: Donnerstag, 14. März 2013 22:10 An: [email-masked];
>> [email-masked]; [email-masked] Cc:
>> [email-masked]; [email-masked] Betreff: Re: [rtcweb]
>> Agenda time request for 
>> Koen is right that there are many more obstacles to RTCweb and
>> legacy network interop than just a common codec. First there will
>> need to be RTCweb signaling gateways to interface between the
>> RTCweb signaling and the legacy networks (SIP, H.323 etc) and
>> there will need to be in place mechanisms for peering, federation
>> and address resolution between networks as well as service 
>> ----- Original Message ----- From: Koen Vos
>> [mailto:[email-masked]] Sent: Thursday, March 14, 2013 03:32
>> PM Central Standard Time To: Espen Berger (espeberg)
>> <[email-masked]>; [email-masked]
>> <[email-masked]> Cc: [email-masked]
>> <[email-masked]>; MARJOU Xavier OLNC/OLN 
>> <[email-masked]> Subject: Re: [rtcweb] Agenda time
>> support G.711, G.729 and perhaps some other  codecs like iLBC.
>> They do not, however, support the codecs you are advocating for.
>> 
>> The lack of support for Transcoding-Free Operation by Telcos to
>> the rest of the world has been hurting interop voice quality for
>> a long time, but unfortunately we can't fix that here at the
>> IETF.
>> 
>> [email-masked] Sent: 14. mars 2013 13:36 To:
>> Jean-Marc Valin Cc: [email-masked]; MARJOU Xavier OLNC/OLN 
>> The short list is aligned to what is specified in 3GPP (mobile)
>> and CAT-iq (fixed). Check the related service specifications! The
>> short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
>>  minimize interop issues and transcoding costs for telco
>> services. It's not a question of what's the favourite codec for a
>> given application. It's interop with billions of mobile phones
>> and with fixed terminals in legacy telephony services.
>> 
>> Stéphane
>> 
>> -----Message d'origine----- De : Jean-Marc Valin
>> [mailto:[email-masked]] Envoyé : jeudi 14 mars 2013 05:55 À
>> : PROUST Stephane OLNC/OLPS Cc : Andrew Allen;
>> [email-masked]; MARJOU Xavier OLNC/OLN; [email-masked]
> Just curious, why exclude from the list other codecs with similar
> huge deployment? I can think of at least: - GSM-FR (mobile) - Speex
> (Flash) - G.729 (PSTN gateways) - iLBC (PSTN gateways) - G.726
> (DECT) - SILK (original non-Opus version in Skype)
> 
> AMR-WB and G.722 different from the other codecs in the list above.
> Not that I insist on shipping G.729 :-)
> 
>  could then choose which of these they care about for their
> particular situation.
> 
> Cheers,
> 
> Jean-Marc
> 
>>>> Stéphane
>>>> 
>>>> 
>>>> [mailto:[email-masked]] Envoyé : mercredi 13 mars
>>>> 2013 23:41 À : PROUST Stephane OLNC/OLPS;
>>>> [email-masked]; [email-masked] Cc : MARJOU
>>>> Xavier OLNC/OLN;
> [email-masked] Objet
>>>> set of codecs supported on the device. If the device supports
>>>>  [mailto:[email-masked]] Sent: Wednesday, March
>>>> 13, 2013 05:14 PM Central Standard Time To:
>>>> [email-masked] <[email-masked]>;
>>>> [email-masked]
> <[email-masked]>
>>>> <[email-masked]> Subject: Re: [rtcweb] Agenda time
>>>> Of course each Telco can handle this directly with vendors
>>>> and browsers manufacturers at business level. But I
>>>> don't'think
> this need
>>>> of interoperability with mobile devices is specific to
>>>> Orange. I think all mobile operators will have the same issue
>>>> and
> this is why
>>>>  complicated requirement. We could also live as a compromise
>>>> with a formulation that has already been suggested on the
>>>> reflector:
>>>> 
>>>> is recommended that they are also included in the offer in
>>>> without
> the need for
>>>> I think this Group should at least make one small step so
>>>> that the interoperability issue with mobile terminals be not
>>>> fully
> ignored in
>>>> the RTC Web specification considering the huge number of
>>>> deployed devices. At least something must be written on this
>>>> ! G.711 which is the only codec in addition to OPUS for
> interoperability
>>>> [mailto:[email-masked]] Envoyé : mercredi 13 mars
>>>> 2013 22:37 À : PROUST Stephane OLNC/OLPS;
>>>> [email-masked]; MARJOU Xavier OLNC/OLN Cc :
>>>> [email-masked] Objet : RE: [rtcweb]
> Agenda time
>>>> platforms that they open up the APIs to AMR and AMR-WB and
>>>> that at least the in-built default browser needs to support
>>>> it. If
> there are
>>>> platform vendors, it probably has a bigger impact than an
>>>> IETF RFC. Getting that support for user-installed additional
>>>> browsers
> might be
>>>> more difficult, but most mobile device users stick with the
>>>> default browser anyway.
>>>> 
>>>> The RTCWEB codec document needs to definitely explain this
>>>> case and the benefits, but the conditional MUSTs or SHOULDs
>>>> you are
> proposing
>>>> are perhaps a bit too complicated. Hmm, perhaps we need to do
>>>> an _informational_ RFC as something like "Recommendations
>>>> for
> WebRTC on
>>>> Mobile Devices" addressing the codec and perhaps other
>>>>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc:
>>>>> [email-masked] Subject: Re: [rtcweb] Agenda time request
>>>>> for draft-marjou-rtcweb-audio- codecs-for-interop-01
>>>>> 
>>>>> Hello
>>>>> 
>>>>> Our understanding is that the reason of the "no consensus"
>>>>> on additional recommended codecs was the additional costs
>>>>> for
> browsers.
>>>>> The proposal is then to make these "MUST" fully conditional
>>>>> to the case of no (or very reduced) additional costs, when
>>>>> the codecs are already available on the device and when no
>>>>> additional
> license fee is
>>>>> required
>>>>> 
>>>>>  respectively May and Should (instead of Should and shall)
>>>>> but we think that this proposal is a way to take into
>>>>> account
> both browser
>>>>> manufacturers concerns on browsers costs and telcos
>>>>> concerns on transcoding costs and some other companies
>>>>> share this view.
>>>>> 
>>>>> Stéphane
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN Cc
>>>>> : [email-masked] Objet : Re: [rtcweb] Agenda time request
>>>> that there was *no consensus* on recommended codecs can
> effectively makes
>>>> 3 new codecs MTI for a range of devices. I understand that
>>>> it's an individual draft and you can write whatever you like
>>>> in
> there, but it
>>>>>>> usually use one of the following codecs: AMR, AMR-WB or
>>>>>>> G.722, which will result in massive transcoding when
>>>>>>> there will be communications between WebRTC endpoints
>>>>>>> draft (cost issues, intrinsic quality degradation,
)
>>>>>>> prepare something.  If the discussion of working group
>>>>>>> last call items runs short, we may be able to fit this
>>>>>>> in at that
> time or at
>>>>>>> commitment, however, so please try and get discussion
>>>>>>> on
> the list
>>>>>>>> The document  presents use-cases underlining why
>>>>>>>> WebRTC needs
>>>>>>> AMR-WB,  AMR
>>>>>>>> A 10-minute time slot should be sufficient for
>>>>>>>> presentation and
>>>>>>> discussion.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Espen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> rtcweb
>>>> mailing list
>>>>> donc pas
> etre diffuses,
>>>>> 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,
>>>> donc pas etre
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> be distributed, used or copied without authorisation. If you
> delete this
>>>> _______________________________________________ rtcweb
>>>> mailing list [email-masked]
> 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.
>>>> 
>>>> 
>>>> donc pas etre
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> be distributed, used or copied without authorisation. If you
> delete this
>> information, privileged material (including material protected by
>> the solicitor-client or other applicable privileges), or
>> constitute non-public information. Any use of this information by
>> anyone other than the intended recipient is prohibited. If you
>> have received this transmission in error, please immediately
>> reply to the sender and delete this information from your system.
>> Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may
>> be unlawful. _______________________________________________ 
>> rtcweb mailing list [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 16 Mar 2013 02:14:25 +0000

> Opus should be MTI for the next 3GPP release. ;-)

You are welcome to create the relevant work item in 3GPP SA4 if you think it appropriate.

That of course will not solve the need to transcode with all the phones prior to the release where that work item is adopted.

Keith

> Of Adam Roach
> Sent: 15 March 2013 12:42
> To: Andrew Allen
> Cc: [email-masked]; [email-masked]
> RTCweb signaling gateways to interface between the RTCweb signaling and
> the legacy networks (SIP, H.323 etc) and there will need to be in place