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

Burger Eric <eburger@cs.georgetown.edu> Thu, 17 January 2013 13:31 UTC

Return-Path: <eburger@cs.georgetown.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB29F21F86BE for <rtcweb@ietfa.amsl.com>; Thu, 17 Jan 2013 05:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MKnu-meQlBv for <rtcweb@ietfa.amsl.com>; Thu, 17 Jan 2013 05:31:53 -0800 (PST)
Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD021F86AF for <rtcweb@ietf.org>; Thu, 17 Jan 2013 05:31:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 0F05442D74 for <rtcweb@ietf.org>; Thu, 17 Jan 2013 08:31:53 -0500 (EST)
X-Virus-Scanned: by amavisd-new at cs.georgetown.edu
Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y52FNWpUqU4i for <rtcweb@ietf.org>; Thu, 17 Jan 2013 08:31:51 -0500 (EST)
Received: from [192.168.15.177] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 2F6A542CDF for <rtcweb@ietf.org>; Thu, 17 Jan 2013 08:31:51 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Burger Eric <eburger@cs.georgetown.edu>
In-Reply-To: <BBF5DDFE515C3946BC18D733B20DAD2338CF2A76@XMB104ADS.rim.net>
Date: Thu, 17 Jan 2013 08:31:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E08C7757-8466-4C65-A938-B5739DC28747@cs.georgetown.edu>
References: <BBF5DDFE515C3946BC18D733B20DAD2338CF2A76@XMB104ADS.rim.net>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2013 13:31:54 -0000

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 <aallen@rim.com> 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: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