Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

[Adam Roach <[e-mail]>]

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

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

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

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

> What is the argument against it?

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

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

/a