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

[Gunnar Hellström <[e-mail]>]

Here is the current US regulation draft:
http://www.access-board.gov/sec508/refresh/draft-rule.htm#_Toc310327586
Look at point 408.5.

The European draft is here:
http://www.mandate376.eu/doc/EN301549v008.zip
The wide-band codec is mentioned in point 6.2.
It is a bit weak, but still points at G.722 with should.

Both drafts allow other codecs to be used by endpoints, as long as G722 
interoperability is provided, e.g. by transcoding.

*I looked back to Magnus' original question for voting, **I think in 
consequence with the information I provided, I vote for alternative 1).**
*
And, excuse me for again clobbering the voting thread with discussion. 
We should keep discussions in other threads to make it easier to count 
votes.

Gunnar

On 2012-12-23 08:49, Bernard Aboba wrote:
> I would agree.  G.722 is widely implemented and there are no IPR 
> issues. So making it a SHOULD seems compelling.
> *From:* Gunnar Hellström
> *Sent:* ‎December‎ ‎22‎, ‎2012 ‎11‎:‎47‎ ‎PM
> *To:* [e-mail]
> *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting 
> Recommended Audio Codecs
> There is an accessibility side of this as well.
>
> Wide band audio can make it much easier for persons with hearing 
> impairments to use voice communication over distance.
> Therefore both US and European draft regulation or draft standards for 
> support of regulation requires wide band audio wherever you have voice 
> communication. And these drafts point at G.722 as the common codec at 
> least to assure interoperability with wide-band audio between providers.
> These draft regulations aim at public procurement and at marketing of 
> electronic communication products and services.
>
> Therefore, it seems logical to include G.722 in a codec recommendation 
> document.
>
> Gunnar
>
>
> On 2012-12-22 18:12, Adam Roach wrote:
>
>     Recommendations or *normative* recommendations?
>
>     I think the former is a very good idea. The latter,  not so much.
>
>     /a
>
>     On Dec 22, 2012, at 7:17, "Hutton, Andrew"
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         I agree with Roman’s comments below.
>
>         So +1 for providing some recommendations on additional audio
>         codec’s for RTCWEB.
>
>         Andy
>
>         *From:*[e-mail]
>         <mailto:[e-mail]>
>         [mailto:[e-mail]] *On Behalf Of *Roman Shpount
>         *Sent:* 21 December 2012 21:43
>         *To:* Adam Roach
>         *Cc:* [e-mail] <mailto:[e-mail]>
>         *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting
>         Recommended Audio Codecs
>
>
>         On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             What I think would be beneficial would be a section
>             documenting codecs in widespread use today, where they're
>             used, and what is gained by including them in WebRTC
>             implementations (mostly transcoder-free interop with those
>             other implementations). Documenting that AMR is used in
>             3GPP VoIP networks would allow implementors to make an
>             educated decision about the benefit of including that
>             codec. A similar mention that many modern VoIP phones
>             support G.722 and/or AAC-LD would provide similar guidance.
>
>         In reality very few phones support AAC-LD.
>
>         For me the major concern is support for G.722. There is no
>         reason not to support it. None. It is free, it is efficient,
>         and it sounds better then G.711 any day of the week. It was
>         not made an MTI for political reasons to promote OPUS. I think
>         it deserves a SHOULD in the standard.
>
>         As far  as AMR and AMR-WB are concerned, they should be
>         implemented if your platform provides it. I, personally, would
>         never pay a license fee for these codecs, but if implementing
>         a browser on a cell phone where these codecs are present, I
>         would make an extra effort to support them. So, these codecs
>         probably do not deserve a SHOULD, but some guidance to
>         implementers is probably required.
>
>         _____________
>         Roman Shpount
>
>         _______________________________________________
>         rtcweb mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail]  <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>