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

G.711 allows interoperability with the PSTN.

----- Original Message -----
From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]
Sent: Thursday, January 17, 2013 07:16 AM Central Standard Time
To: Andrew Allen; radhika.r.roy.civ@mail.mil <radhika.r.roy.civ@mail.mil>; roman@telurix.com <roman@telurix.com>; martin.thomson@gmail.com <martin.thomson@gmail.com>
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
Subject: RE: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of ext Andrew Allen
> 
> 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.
> 
This is not the point. The use case is to enable a user of an RTCWeb
service to reach another user via the legacy telephone network, be it
mobile or fixed. The fact whether or not the browser on the mobile phone
is capable of RTCWeb is of no relevance for this use case, because it
may well be that the two call parties use different RTCWeb services with
no interconnection, and the only way to reach each other is via the
telephone network.

Kind regards,
Uwe

> ----- Original Message -----
> From: Roy, Radhika R CIV USARMY (US)
> [mailto:radhika.r.roy.civ@mail.mil]
> Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time
> To: Roman Shpount <roman@telurix.com>; Martin Thomson
> <martin.thomson@gmail.com>
> Cc: rtcweb@ietf.org <rtcweb@ietf.org>
> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of
> Roman Shpount
> Sent: Thursday, January 17, 2013 5:32 AM
> To: Martin Thomson
> Cc: rtcweb@ietf.org
> 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
> <martin.thomson@gmail.com>
> 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.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

---------------------------------------------------------------------
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.