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

"Flynn, Gerry J" <Gerry.Flynn@VerizonWireless.com> Wed, 16 January 2013 17:37 UTC

Return-Path: <Gerry.Flynn@VerizonWireless.com>
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 7BE5221F8B69 for <rtcweb@ietfa.amsl.com>; Wed, 16 Jan 2013 09:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 DdpqUkSzP3td for <rtcweb@ietfa.amsl.com>; Wed, 16 Jan 2013 09:37:29 -0800 (PST)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3725E21F8B58 for <rtcweb@ietf.org>; Wed, 16 Jan 2013 09:37:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1358357062; x=1389893062; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=QuDm6s1crpzlkoXCjSO3AjUqXRptXU11WpAygSdF21EBFi0wqW6S24tK Z87VZOFAzNCNmv4gQtO/ww8T5gWJKpKaG2jirZhmjMRgwINS1V3ZROzZZ GZhSVR1iyhmLCqW;
Received: from ohdub02exhub01.uswin.ad.vzwcorp.com ([10.97.42.201]) by vanguard.verizonwireless.com with ESMTP; 16 Jan 2013 09:24:09 -0800
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB01.uswin.ad.vzwcorp.com ([10.97.42.201]) with mapi; Wed, 16 Jan 2013 12:36:24 -0500
From: "Flynn, Gerry J" <Gerry.Flynn@VerizonWireless.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Wed, 16 Jan 2013 12:36:23 -0500
Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs
Thread-Index: Ac3zL3pmQ21KI6lHRG+ADs05bk33QQA4FOQw
References: <50D2CC6A.4090500@ericsson.com> <CAIRVNEXSMTP24IpVv8003a1bcf@CAIRVNEXSMTP24.uswin.ad.vzwcorp.com>
In-Reply-To: <CAIRVNEXSMTP24IpVv8003a1bcf@CAIRVNEXSMTP24.uswin.ad.vzwcorp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-Id: <20130116173729.3725E21F8B58@ietfa.amsl.com>
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs
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: Wed, 16 Jan 2013 17:37:30 -0000

Dear Colleagues

It has been challenging to absorb all the excellent ideas and inputs aiming to reach consensus around one of the two proposed options as there are valid considerations for each.  A degree of compromise is encouraged with recognition of the extensive current and future deployment of AMR and AMR-WB as well as the need for interoperability with new audio codecs and minimization of transcoding.  As such, Verizon endorses the e-mail by Magnus and supports option 1.


Gerry Flynn
Verizon

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Håkansson LK
Sent: Tuesday, January 15, 2013 9:48 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

On 2012-12-20 09:29, Magnus Westerlund wrote:
> WG,
>
> As an outcome of the Vancouver IETF meeting codec discussions we did 
> promise to run a call for consensus regarding if the WG was interested 
> in specifying a small set of recommended audio codecs. We are sorry 
> this has been delayed until now.
>
> The question for the call of consensus is between two options.
>
> 1) Run a process in the WG to select and specify a small set of 
> audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC 
> end-points
>
> 2) Do nothing and let the already specified Mandatory to Implement 
> Audio codecs be the only audio codecs mentioned in the WebRTC specification.
>
> Please indicate your position by January 16th 2013.

I see the following important reasons for creating a RECOMMENDED category:

1. interoperability without quality degradations due to transcoding with large installed legacy and existing services.
   Typical examples are interconnection cases to major mobile or fixed communication systems. Clearly interop with 3GPP voice services and HD Voice in 3GPP and fixed networks is very important. The option with transcoding should be avoided as - besides the equipment costs - it is affecting the communication quality in terms of more coding distortions and delay.

2. take advantage of deep codec specific integrations/optimizations.
   Typical examples are interconnection cases to major mobile systems which bearers are highly optimized for a given codec specified for these systems. For these systems operating with their 'native' codecs is beneficial not only in terms of system capacity and efficiency but also from end-user perspective as it will allow least battery consumption in the mobile devices (due to that hardware implementations for the codecs are often used) and provide best robustness/coverage. At least interop to such native codecs in 3GPP mobile networks is essential. This point partly overlaps with the previous but also covers cases where new codecs will get a deep system integration. The alternative with transcoding in a GW should be avoided for the reasons given above (avoiding extra distortions and delay).

3. future-proofness of specifications allowing to recommend new codecs that turn out to be better/more efficient than existing mandatory codecs.
   As history has proven, even the best mandatory codec has a best-before date. We should foresee the possibility to at least recommend such a better codec at some stage when felt appropriate.

At the same time, when creating a RECOMMENDED category, I think that it should be strictly limited to very few codecs only. At present I see a reasonable limit of 3 recommended codecs related to particular interop scenarios. However, this number could be increased if new and better codecs are deemed would in the future enter this category.

So, my vote goes for option 1.

Stefan

>
> Regards
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb