Subject: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop

From: Sean Turner <[email-masked]>
Date: Thu, 24 Jul 2014 15:50:53 -0400

At the RTCWEB session on Thursday there was support for adoption of draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If you do not support adoption of this draft as a WG draft please respond to this email by August 1st.  Please also indicate why you do not support WG adoption.

spt

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 24 Jul 2014 16:18:15 -0400

I do not support adoption of the draft in its current form, for the
following reasons:

a. The draft only currently covers AMR-WB, AMR and G.722.  Since the AMR
codecs generally are accessible only through a proprietary "blackbox" API
that does not permit WebRTC use without a separate license, these codecs
are not currently practical to support in browsers, even in operating
systems that support AMR-WB/AMR for other uses.

b. The remaining codec (G.722) does not have these issues, and so it could
be implemented in browsers.  However, the useful text in this portion of
the document is so small that it does not justify creation of yet another
document, even a separate one.

On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner <[email-masked]> wrote:

> At the RTCWEB session on Thursday there was support for adoption of
> draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.
>  If you do not support adoption of this draft as a WG draft please respond
> to this email by August 1st.  Please also indicate why you do not support
> WG adoption.
>
> spt
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 17:02:27 -0400

I agree that it is currently impractical to support AMR/AMR-WB in browsers,
and therefore a document that recommends support of these codecs without
addressing the associated issues is not suitable for adoption.

I have no issues with the recommendation of G.722.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 14:10:36 -0700

> At the RTCWEB session on Thursday there was support for adoption of draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If you do not support adoption of this draft as a WG…

Do we anticipate this draft having a material impact on what
people/implementations do?  Otherwise, I think that I'm against
spending working group time on this.

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Jul 2014 03:13:52 +0000

I am with Martin on this.

Have it as an individual draft and AD sponsored. Its basically as I understand it an informational summary of the reality in existing deployments. So this isn't reallly the work of the RTCweb WG - in fact is relevant (for as long as its information is up to date) also for work in RAI groups other than RTCweb too.

Andrew

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 24 Jul 2014 21:21:16 -0700

Bernard Aboba wrote:
> b. The remaining codec (G.722) does not have these issues, and so it
> could be implemented in browsers.  However, the useful text in this
> portion of the document is so small that it does not justify creation of
> yet another document, even a separate one.

+1

I also do not support the adoption of the draft.

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 25 Jul 2014 00:54:10 -0400

I also do not support adoption of the draft. I agree with the reasons
stated by Bernard, but I also think that a separate codec document is
a bad idea in general, regardless of its content. As new codecs get
adopted and included in non-IETF contexts, the contents would soon be
outdated.

	Jean-Marc

On 24/07/14 04:18 PM, Bernard Aboba wrote:
> I do not support adoption of the draft in its current form, for
> the following reasons:
> 
> a. The draft only currently covers AMR-WB, AMR and G.722.  Since
> the AMR codecs generally are accessible only through a proprietary
> "blackbox" API that does not permit WebRTC use without a separate
> license, these codecs are not currently practical to support in
> browsers, even in operating systems that support AMR-WB/AMR for
> other uses.
> 
> b. The remaining codec (G.722) does not have these issues, and so
> it could be implemented in browsers.  However, the useful text in
> this portion of the document is so small that it does not justify
> creation of yet another document, even a separate one.
> 
> 
> On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> At the RTCWEB session on Thursday there was support for adoption
> of draft-proust-rtcweb-audio-codecs-for-interop as an informational
> WG draft.  If you do not support adoption of this draft as a WG
> draft please respond to this email by August 1st.  Please also
> indicate why you do not support WG adoption.
> 
> spt _______________________________________________ rtcweb mailing
> list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Paul Coverdale <[email-masked]>
Date: Sun, 27 Jul 2014 20:44:15 -0400

I don't follow the comment about not wanting to spend working group time on
this. The aim is to provide an informational document which will provide
guidance on enhancing audio interoperability for WebRTC. This seems a
relevant activity to me, in the rtcweb WG. Of course if some individuals
don't want to work on it, that's their prerogative.

...Paul

>-----Original Message-----
>From: rtcweb [mailto:[email-masked]] On Behalf Of Andrew Allen
>Sent: Thursday, July 24, 2014 11:14 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Have it as an individual draft and AD sponsored. Its basically as I
>understand it an informational summary of the reality in existing
>deployments. So this isn't reallly the work of the RTCweb WG - in fact
>is relevant (for as long as its information is up to date) also for work
>in RAI groups other than RTCweb too.
>
>Andrew
>
>draft-proust-rtcweb-audio-codecs-for-interop as an informational WG
>draft.  If you do not support adoption of this draft as a WG draft
>please respond to this email by August 1st.  Please also indicate why
>you do not support WG adoption.
>
>people/implementations do?  Otherwise, I think that I'm against spending
>working group time on this.
>

---

From: Paul Coverdale <[email-masked]>
Date: Sun, 27 Jul 2014 20:45:52 -0400

The point of having this as a separate informational document, distinct from
draft-ietf-rtcweb-audio, is to allow for easier update if necessary, as new
codecs become available.

...Paul

>From: rtcweb [mailto:[email-masked]] On Behalf Of Jean-Marc
>Valin
>Sent: Friday, July 25, 2014 12:54 AM
>To: Bernard Aboba; Sean Turner
>Cc: [email-masked]
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>stated by Bernard, but I also think that a separate codec document is a
>bad idea in general, regardless of its content. As new codecs get
>> a. The draft only currently covers AMR-WB, AMR and G.722.  Since the
>> AMR codecs generally are accessible only through a proprietary
>> browsers, even in operating systems that support AMR-WB/AMR for other
>> uses.
>>
>> portion of the document is so small that it does not justify creation
>> of yet another document, even a separate one.
>>
>>
>> _______________________________________________ rtcweb mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJT0eLuAAoJEJ6/8sItn9q9BVYH/jbxk53SF+IV/mGpGpnqUXM9
>VSjlWSQcOBuJoSSUgjPlu3gIaJ+9uTypJXkq/vGYAOE8JSsNeZ3FkORqpsnR4CUX
>PGjNEahtkJN+3XqEAqJLU3mPuy8tLtgE+MUgSOi9iQvMyalxGMjpDg8ksEFyQG6p
>6/HzNGk7qtaA4v/LkuQvTV+OkGA4QfmtZKrwh9syZVZ7tHCBvM/J0dk3TOWoOrJ6
>RelfzBfk8+SWOm1rHBxO9+gDrxx0S8YjqQuVHddWo0sTofJ4is2MS5q1zbn2sN1M
>iauuVTkoePQbcnfUf9py1gYLofYsSkEupzoNstdmeAuJUYaIvLDVi09stNINgzk=
>=bnqu
>-----END PGP SIGNATURE-----
>

---

From: Jim Spring <[email-masked]>
Date: Sun, 27 Jul 2014 18:25:53 -0700

Right now, required codecs per draft-ietf-rtcweb-05 are Opus and G.711.

In terms of making progress in the working group, I don't see how this draft helps us make progress towards the base WebRtc requirements.

I'm against.

-Jim 

Sent from my iThingy

> On Jul 24, 2014, at 14:10, Martin Thomson <[email-masked]> wrote:
>

---

From: Paul Coverdale <[email-masked]>
Date: Mon, 28 Jul 2014 11:29:55 -0400

This draft isn't about the required codecs for WebRTC. That is already clear
in draft-ietf-rtcweb-05. 

It addresses the point in clause 3:

"If other suitable audio codecs are available for the browser to use, it is
RECOMMENDED that they are also be included in the offer in order to maximize
the possibility to establish the session without the need for audio
transcoding."

The intent is to list a set of optional audio codecs and appropriate
contexts and guidance to use them for increased interoperability.

...Paul

>From: rtcweb [mailto:[email-masked]] On Behalf Of Jim Spring
>Sent: Sunday, July 27, 2014 9:26 PM
>To: Martin Thomson
>Cc: [email-masked]
>In terms of making progress in the working group, I don't see how this
>draft helps us make progress towards the base WebRtc requirements.
>
>I'm against.
>
>-Jim
>
>Sent from my iThingy
>

---

From: Andrew Allen <[email-masked]>
Date: Mon, 28 Jul 2014 21:43:58 +0000

Paul

I view this as 

A) purely an informational analysis of what codecs other deployments are using and not normative or specific to the RTCweb work (although I don't have a problem RTCweb docs referencing it informatively).

B) useful outside of RTCweb (I.e SIP, MMUSIC)

Why does this need the overhead of WG review since the main areas of expertise required are from experts in deployments outside RTCweb.

AD sponsored seems a better path to me.

Andrew

----- Original Message -----
From: Paul Coverdale [mailto:[email-masked]]
Sent: Sunday, July 27, 2014 08:44 PM Eastern Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop

...Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Jul 2014 22:02:22 +0000

I think this draft should progress.

How it progresses I do not mind - if the WG chairs in conjunction with Ads think it should be WG, then fine, if AD sponsored, then also fine.

Keith 

> Sent: 28 July 2014 22:44
> To: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] call for adoption: 
> draft-draft-proust-rtcweb-audio-codecs-for-interop
> 
> 
> Paul
> 
> I view this as 
> 
> A) purely an informational analysis of what codecs other 
> deployments are using and not normative or specific to the 
> RTCweb work (although I don't have a problem RTCweb docs 
> referencing it informatively).
> 
> Why does this need the overhead of WG review since the main 
> areas of expertise required are from experts in deployments 
> outside RTCweb.
> 
> Subject: Re: [rtcweb] call for adoption: 
> draft-draft-proust-rtcweb-audio-codecs-for-interop
> 
> I don't follow the comment about not wanting to spend working 
> group time on this. The aim is to provide an informational 
> document which will provide guidance on enhancing audio 
> interoperability for WebRTC. This seems a relevant activity 
> to me, in the rtcweb WG. Of course if some individuals don't 
> want to work on it, that's their prerogative.
> 
> 
> ...Paul
> 
> >is relevant (for as long as its information is up to date) also for 
> >work in RAI groups other than RTCweb too.
> >
> >Andrew
> >

---

From: <[email-masked]>
Date: Thu, 31 Jul 2014 13:50:48 +0000

>> therefore a document that recommends support of these codecs without addressing the associated issues is not suitable for adoption.

The current WebRTC audio draft already recommends the support of "available" codecs to address the interoperability issue
If other suitable audio codecs are available for the browser to use, it is RECOMMENDED that they are also be included in the offer in order to maximize the possibility to establish the session without the need for audio transcoding.
The purpose of this additional draft is only to complement this statement and capture all the additional information useful to extend the WebRTC interoperability to some well identified use cases including some reference and guidance on how to implement these codecs for interoperability.
The reason for having an informational separate draft is to keep the audio specification focused on mandatory audio codecs, not confuse the issue and hopefully make this proposal acceptable for all.

>>The draft only currently covers AMR-WB, AMR and G.722

It is not the intent of the draft to be limited to any specific codecs but just to identify all codecs that may be relevant for usage with WebRTC technology.  The Draft can progress as a WG Draft with other relevant codecs added if needed.

>> Since the AMR codecs generally are accessible only through a proprietary "blackbox" API that does not permit WebRTC use without a separate license, these codecs are not currently practical to support in browsers, even in operating systems that support AMR-WB/AMR for other uses.

There is currently a clear and increasing trend and related works to open APIs on devices to give access to hardware codecs. It is not the responsibility of this Group to work on this but it is in the interest of WebRTC standard to take this into consideration and show some openness to other codecs where needed. We can then anticipate some progress in the openness and standardization of "codecs" APIs on devices…

As a conclusion and recommendation I would say that adopting the draft as a WG Draft would be great for all who care about interop use cases without any impact on current WebRTC specification and use cases relying on OPUS and G.711 mandatory codecs

Stéphane

De : rtcweb [mailto:[email-masked]] De la part de Justin Uberti
Envoyé : jeudi 24 juillet 2014 23:02
À : Bernard Aboba
Cc : [email-masked]
Objet : Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop

I agree that it is currently impractical to support AMR/AMR-WB in browsers, and therefore a document that recommends support of these codecs without addressing the associated issues is not suitable for adoption.

On Thu, Jul 24, 2014 at 4:18 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
I do not support adoption of the draft in its current form, for the following reasons:

a. The draft only currently covers AMR-WB, AMR and G.722.  Since the AMR codecs generally are accessible only through a proprietary "blackbox" API that does not permit WebRTC use without a separate license, these codecs are not currently practical to support in browsers, even in operating systems that support AMR-WB/AMR for other uses.

b. The remaining codec (G.722) does not have these issues, and so it could be implemented in browsers.  However, the useful text in this portion of the document is so small that it does not justify creation of yet another document, even a separate one.

On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
At the RTCWEB session on Thursday there was support for adoption of draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If you do not support adoption of this draft as a WG draft please respond to this email by August 1st.  Please also indicate why you do not support WG adoption.

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

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

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.