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

["Richard Shockey" <[e-mail]>]

I'm really trying to understand the tortured logic here.  The presumption
was that you wanted to have some limited MTI's here in order to guarantee a
minimum level of interoperability.

Its clear there will be virtually no consensus on Video Codec's not very
much agreement on how text will be supported and now a sustained whine for
either SHOULD/RECOMMENDED ( whatever) for the most practical advanced
codec's that are or will be in use in the public SIP networks.

So instead of providing any minimum guidance to implementers why don't you
basically say "Well there is no consensus on anything and we've collectively
decided to drive off the protocol cliff and see what happens".   

Cliff diving is very popular in the US these days. 

Eliminate all MTI's and just say here is Video menu A, Audio menu B, Text
menu C and Dessert menu D good luck folks! 

That seems to be where you seem to be going.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Adam Roach
Sent: Friday, December 21, 2012 11:27 AM
To: Timothy B. Terriberry
Cc: [e-mail]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended
Audio Codecs

On 12/20/12 22:21, Timothy B. Terriberry wrote:
> [e-mail] wrote:
>> My proposal would be to recommend AMR, and perhaps AMR-WB. The 
>> rationale is
>
> I don't think we should list a set of RECOMMENDED codecs. If we were 
> talking just G.722, iLBC, etc., I might be persuaded. But this is a
> 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be 
> nice," and given the aforementioned IPR situation, Mozilla is not 
> likely to be deploying any of the AMR family anytime soon.
>
> If the goal is interoperability with deployed systems, you're going to 
> implement what you need to implement to achieve that, and nothing we 
> write down in an RFC will change what that needs to be.

I'm going to have to agree with Tim -- very little would be served by having
normative SHOULD-strength requirements here.

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.

But I don't think there's much to be gained by readying the scarlet letter
of "conditionally compliant" that would result from a SHOULD-strength
normative statement about royalty-bearing codecs.

/a
_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb