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

From: Bernard Aboba <[email-masked]>
Date: Sun, 23 Dec 2012 07:49:48 +0000

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: [email-masked]
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" <[email-masked]> wrote:

I agree with Roman’s comments below.

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

Andy

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

On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 Dec 2012 09:37:29 +0100

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

---

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

Looks like I'll be a lone voice again.

I'm against any recommendation of use of g722 in webRTC 
If implementers want to provide it that's fine but it should not be in the standard.
Even if it is available it always be at a lower preference than Opus

g722 has several disadvantages over Opus and no real advantages.

1) The spec for g722 contains a historical error, so it's sample rate gets 
declared as 8khz even though it is actually 16khz - this means that the rtp/audio processing code is
littered with if( codec == CODEC_G722) {} else {} clauses to try and implement this mistake.
I've seen g722 mis-implemented more often than any other codec.

2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what is available - it won't play nice with any
congestion management that is specified with webRTC

3) g722 sounds ok  (despite using 14 or the available 16 bits)
- provided there is no packet loss - it has no built in FEC or PLC modes, so falls apart 
at quite low loss levels (especially compared to opus).

4) if we mandate g722 then we need to make some  methods  in the constraints API to ensure
that 2 browser endpoints that say they want wideband don't get g722 when they could both be doing opus in
full CELT mode for the same bandwidth.

The often stated advantage is that there are many existing g722 endpoints out there. This is
irrelevant - there is only 1 platform I know of that implements ICE+DTLS-SRTP and g722 but not opus 
(asterisk for the curious and there's an opus patch available). 

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 24 Dec 2012 05:52:36 -0500

> Looks like I'll be a lone voice again.

And I thought I was the lonely voice of reason saying exactly the opposite.

> Even if it is available it always be at a lower preference than Opus

I agree it should be lower preference by default, but the application
developer can change this if needed.

> 1) The spec for g722 contains a historical error, so it's sample rate gets

declared as 8khz even though it is actually 16khz - this means that the
> rtp/audio processing code is littered with if( codec == CODEC_G722) {} else
> {} clauses to try and implement this mistake. I've seen g722
> mis-implemented more often than any other codec.
>

I've seen more G722 implementations then of any other wide band codec. In
fact this is the most commonly implemented and used wideband codec right
now, may be with an exception of SILK.

> 2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what
> is available - it won't play nice with any congestion management that is
> specified with webRTC
>

So does G.711, but it still supported for interop reasons. In most cases
64kbps is little enough not to worry about it.

> - provided there is no packet loss - it has no built in FEC or PLC modes,
> so falls apart at quite low loss levels (especially compared to opus).
>

That is simply not true. PLC for G.722 is defined in Appendixes III and IV.
It is not as good as OPUS but it is acceptable.

> 4) if we mandate g722 then we need to make some  methods  in the
> constraints API to ensure that 2 browser endpoints that say they want
> wideband don't get g722 when they could both be doing opus in full CELT
> mode for the same bandwidth.
>

This should be up to the application developers, not a standard comity.  By
default OPUS should have higher preference.

> The often stated advantage is that there are many existing g722 endpoints
> out there. This is irrelevant - there is only 1 platform I know of that
> implements ICE+DTLS-SRTP and g722 but not opus (asterisk for the curious
> and there's an opus patch available).
>

It is not irrelevant. If SRTP is supported there are a lot of end points
that support ICE+SRTP+G.722.

P.S. A saner, more conservative approach would have been to make G.722 a
MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together with
such things like support of plain RTP, due to worrying about political
appearences first and stable product later.

---

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

> And I thought I was the lonely voice of reason saying exactly the opposite. 

Perhaps ;-)

> I agree it should be lower preference by default, but the application developer can change this if needed.

How? by dipping into the SDP or with an API ? - see my point 4) 

> declared as 8khz even though it is actually 16khz - this means that the rtp/audio processing code is littered with if( codec == CODEC_G722) {} else {} clauses to try and implement this mistake. I've seen g722 mis-implemented more often than any other codec.
> 
> I've seen more G722 implementations then of any other wide band codec. In fact this is the most commonly implemented and used wideband codec right now, may be with an exception of SILK. 

And almost every one of them got this wrong the first time, and then had a regression 6 months later. Lets admit it - it's a mess.

>  
> 2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what is available - it won't play nice with any congestion management that is specified with webRTC
> 
> So does G.711, but it still supported for interop reasons. In most cases 64kbps is little enough not to worry about it.

Ah. now there we disagree. We can run opus over lossy Edge but not g722 - many people's only internet connection is Edge at best.
On the other side if I'm on a 50Mbps fibre I'll still only get 64kb/s 722 quality even though I could have been in CELT stereo. Non adaptable codecs
aren't fit for the modern internet (IMHO). (- I also voted against 711 being mandatory for exactly that reason).

> - provided there is no packet loss - it has no built in FEC or PLC modes, so falls apart at quite low loss levels (especially compared to opus).
> 
> That is simply not true. PLC for G.722 is defined in Appendixes III and IV. It is not as good as OPUS but it is acceptable. 

I sorry, I forgot that - do all those legacy endpoints actually implement that?

>  
> 4) if we mandate g722 then we need to make some  methods  in the constraints API to ensure that 2 browser endpoints that say they want wideband don't get g722 when they could both be doing opus in full CELT mode for the same bandwidth.
> 
> This should be up to the application developers, not a standard comity.  By default OPUS should have higher preference.

Agreed. I'm not saying implementors cant add it. I just say the standard shouldn't even recommend something that isn't even close to the best we can do.

>  
> The often stated advantage is that there are many existing g722 endpoints out there. This is irrelevant - there is only 1 platform I know of that implements ICE+DTLS-SRTP and g722 but not opus (asterisk for the curious and there's an opus patch available).
>  
> It is not irrelevant. If SRTP is supported there are a lot of end points that support ICE+SRTP+G.722.

Interesting - I can't think of many full ICE clients that do SRTP and g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's SDP last 
I tried. My experience with legacy interop is that you _always_ need a gateway.

If the consensus is to make (non-dtls) SRTP support mandatory I might change my mind I suppose.

> 
> P.S. A saner, more conservative approach would have been to make G.722 a MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together with such things like support of plain RTP, due to worrying about political appearences first and stable product later.

I can't agree that the reasons were about political appearance. Speaking purely for myself they were about security and quality. 
Phonefromhere was a start-up that built webrtc-like functionality into browsers (using a java applet). So we have quite a bit of experience of
what worked and what didn't - my views are shaped by that experience and that of running a security startup westpoint.ltd.uk .  

What works for the deskphone on a managed secure LAN does not necessarily work for someone in a cafe in India on the wi[l]der internet.

T.

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 Dec 2012 09:46:34 -0600

> I tried. My experience with legacy interop is that you _always_ need a gateway.

Well, there's a huge difference in both quality and latency between de-encapsulation and transcoding. I think there are good reasons for implementations to support G.722 -- I just think specifying its use at RFC 2119 SHOULD level is beyond the spirit of what RFC 2119 intends. 

/a

---

From: Emil Ivov <[email-masked]>
Date: Mon, 24 Dec 2012 18:00:19 +0100

On 24.12.12, 12:28, Tim Panton wrote:
> Interesting - I can't think of many full ICE clients that do SRTP and
> g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's
> SDP last I tried. 

FWIW, it's on our roadmap but we probably won't start implementing it
before MMUSIC is done solving the bundle (or alternative) issue and
ready with an official version.

Cheers,
Emil

-- 
https://jitsi.org