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

[Andrew Allen <[e-mail]>]

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Roman Shpount
Sent: Thursday, January 17, 2013 5:32 AM
To: Martin Thomson
Cc: [e-mail]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs)


On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <[e-mail]>
wrote:


	If we don't say "webrtc implementations SHOULD implement
	G.722/AMR/AMR-WB", what is the failure mode for your application?
	Keeping in mind that - because this isn't 2119 MUST - you have to
	expect that some non-negligible proportion of clients will not
support
	this no matter how much extra ink we using in printing large
letters,
	how much pain does this really cause you?
	
	I expect that the transcoding costs are what this come down to.
Does
	anyone care to quantify this?


If common codecs are not implemented in the browser this would mean
transcoding will need to be performed on some sort of server-side media
gateway. There are three distinct issues we need to take into account when
dealing with transcoding. I would list them in what, at least from my point
of view, is the order of importance:

1. If you need to do trancoding, you will need to implement a jitter buffer
on the transcoding media gateway. ICE processing and SRTP en/decoding can be
performed on out of order packets as they are received. You cannot transcode
out of order audio. This means audio packets would need to be delayed by the
jitter buffer size. In cases of good internet connection this means 40 ms
jitter buffer delay. In cases of consumer internet in US (somebody sitting
on a DSL connection at home behind a WiFi router) you are typically looking
at 60-80 ms jitter buffer delay. If you are dealing with international
internet connections jitter of 150 ms to 200 ms is not unheard of. This
means an additional delay due to jitter buffering of 40 ms (best case) to
200 ms. This is in addition to any other delays that are already present on
the audio path. Adding an extra 100 ms of delay can make audio conversions
very awkward or unusable. On the other hand, if the gateway were performing
just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case
I am talking about a software based implementation running on generic server
hardware. A dedicated DSP solution would probably be even faster).

2. Audio artifacts due to transcoding. Apart from usual audio degradation
due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or
AMR), we would also deal with double packet loss concealment. Media gateway
will conceal lost packets when transcoding. Client will conceal lost packet
received from the gateway. This would actually sound worse then PLC
performed in one place.

3. Scalability of the transcoding gateway. Gateway which just deals with ICE
processing and SRTP en/decoding can handle from 2000 to 10000 concurrent
call when running on a generic server CPU (different scalability is due to
differences in CPU performance and presence of AES specific instructions).
Gateway that would do G.722 to OPUS transcoding would most likely handle
from 500 to 1000 concurrent calls. We are looking at 10x difference in
performance. If we need to transcode AMR to OPUS the difference would be
even higher. This translates in 10x difference in hardware, data center,
power, and operations costs.

_____________
Roman Shpount

Classification: UNCLASSIFIED
Caveats: NONE



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.