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

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Folks:

If transcoding is happening today in real-life situations and people are
happy with the quality (assuming transcoding cost is negligible), we should
not even need negotiations for the codec. Life will be simpler (if not
simplest).

Let us explore the audio codec options as stated below.

If people want negotiations as far as practicable for a common codec before
going for transcoding, then the question comes as follows:

"At what point of negotiations, people will decide that we have to go for
transcoding?"

It appears that we should not go both ways (negotiations + transcoding).

On the other hand, we can mandate two audio codecs: one for wired network
and another for mobile wireless network.

In this way, transcoding may occur only once for the calls that go between
the wired and the wireless (mobile) network.

If we want only one codec without any transcoding for both wireless (mobile)
and wired network, we need to go for a single codec whose quality is
reasonably acceptable for both wired and wireless (mobile) network.

If we make more than two (wired + wireless) codecs mandatory, we can do so
if the implementation cost is negligible.

BR/Radhika

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Burger Eric
Sent: Thursday, January 17, 2013 8:32 AM
To: [e-mail]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

People, let's be real:
I get the impression that people think that if their favorite codec does not
become mandatory to implement or at least implement-under-threat-of-SHOULD,
then no one will implement their favorite codec.

Let us look at the real world. All of those mobile phones with AMR-WB? They
are statistically likely to be calling other mobile phones with AMR-WB.
Unless I missed something, RTCweb still lets the offer include AMR-WB and
the answer select AMR-WB. Your precious AMR-WB codec will still get used,
and you can leverage all of the silicon and pre-paid IPR licenses. What
about all of those Flash implementations with speex? They are statistically
likely to be calling other implementations with speex. I am again only just
guessing that the offer will contain speed and the answer will contain
speex.

What about the poor slob on a mobile with AMR-WB that wants to call that
Flash buddy with speex? Last I looked, the specification has a MTI of opus.
They will connect with opus. If the client is RTCweb compliant, THERE WILL
BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING.

Now, what about the really poor slob on a non-RTCweb device? Well, they are,
ahem, on a non-RTCweb device. That is way out of scope. But wait, you will
say -- what about the 1.1 billion 3G subscribers with AMR-WB but no RTCweb?
Well, first off, the mobile-based RTCweb device will almost certainly have
AMR-WB. While some folks like to pick on mobile phone manufacturers, I doubt
some product manager is going to say, "Gee, the IETF specification does not
even mention AMR-WB, so I suppose I will not enable the silicon I already
paid for or use the license I already paid for, and I will spend my
engineering budget to take out AMR-WB." Duh - AMR-WB will be there already,
no transcoding, life is good. What about fixed-line or broadband
interoperability with some wireless user, when they only have G.722? Well,
while we are not making the situation any better, THE SITUATION IS NO WORSE.
Transcoding would happen ANYWAY. It happens TODAY. So get with the program.

Let us fill in the rat-hole and just move on. Two MTI codecs and a SEPARATE
implementation guide listing why you MIGHT want to implement your favorite
codec.

[Hmmmm. "MIGHT".  Perhaps a new 2119 term, meaning "You might consider this,
and if you don't do it, may may get cooties."]

On Jan 17, 2013, at 7:54 AM, Andrew Allen <[e-mail]> wrote:

> 
> As I recall during the MTI discussion it was claimed that OPUS was
intended for interoperability between RTCweb endoints and G.711 for
interoperability with legacy. That's why we selected 2 MTI Codecs.
> 
> Transcoding between G.711 and something else like G.722 will not have
anything like the transcoding cost as between OPUS and G.722 - basically the
complexity of a media gateway.  Of course you will not get the full fidelity
of either OPUS or G.722 but basic audio communications will work fine which
is all I think we can guarantee with legacy.
> 
> If platforms already have other codecs (such as AMR on mobile devices)
that are usable by the browser then it makes perfect sense that they be
included in the offer but I don't think IETF should start recommending other
codecs to implement other than the 2 MTI. This should be left as product
decisions based on commercial needs and not recommendations made by IETF the
driver for which I suspect has more to do with the interests of some legacy
products/deployments than those of RTCweb. 
> 
> Since almost every computing platform has a browser (including most mobile
phones) within a few years every computing platform will have RTCweb and
OPUS so the need for high fidelity legacy codec interoperability will I
think become a mute point.
> 
> I think the inteoperability concerns should be more focussed on the video
issue where we seem to have a real problem.
> 
> Andrew
> 
> ----- Original Message -----
> From: Roy, Radhika R CIV USARMY (US) 
> [mailto:[e-mail]]
> Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time
> To: Roman Shpount <[e-mail]>; Martin Thomson 
> <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus 
> Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Hi, all:
> 
> A good assessment - thanks to Roman. 
> 
> So, the transcoding cost is enormous from both performance and HW/SW 
> implementation point of view.
> 
> In the end it may so appear that we are not hearing each other.
> 
> BR/Radhika
> 


Classification: UNCLASSIFIED
Caveats: NONE