Re: [rtcweb] Confirmation of consensus on audio codecs

Ted Hardie <ted.ietf@gmail.com> Tue, 21 August 2012 15:35 UTC

Return-Path: <ted.ietf@gmail.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 27BA121F87A4 for <rtcweb@ietfa.amsl.com>; Tue, 21 Aug 2012 08:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.764
X-Spam-Level:
X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 BUKxpnGgFGgx for <rtcweb@ietfa.amsl.com>; Tue, 21 Aug 2012 08:35:17 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2621F879F for <rtcweb@ietf.org>; Tue, 21 Aug 2012 08:35:17 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so7181301vcb.31 for <rtcweb@ietf.org>; Tue, 21 Aug 2012 08:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/ePBN3VXF5MYsxp7jw4YO3r1nKvW1bOUWF6q/DVE1So=; b=PvK/jxcLIUtLczLDigTupPpH/XK3gDH5rrma92p2BgsX6axX/AgwtZPZa2+I/IE3Ig ifg5us3vVRFu09P75uWEk04qmlGTkbTL/DD1Zbw0DpY16wl/mgo4mDnWbgSsf9tsyN76 l1g1CiR0oikhMSXdsp3Rp++Q9zEjd1CW9cAuaCs7q8Oj0nT53bpEkWxXM77a2IEw8QXr 0a3GEdPYhcdX19m2NndfD3b/o2TIbAWu7SBjYXfjF0cw0D1z+/lapJGHn6GA/Qj5dfAD jDa3KoZ7pt1J7KnrHt+lNvT2hYa1EiOkkQhEPBwCOS8UQe4fqABQto1h1MU4RGBMPQ7m +SSA==
MIME-Version: 1.0
Received: by 10.58.239.232 with SMTP id vv8mr15047378vec.37.1345563309933; Tue, 21 Aug 2012 08:35:09 -0700 (PDT)
Received: by 10.58.228.232 with HTTP; Tue, 21 Aug 2012 08:35:09 -0700 (PDT)
In-Reply-To: <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup>
References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup>
Date: Tue, 21 Aug 2012 08:35:09 -0700
Message-ID: <CA+9kkMB+QVitAahRMV-Pq7wrYr5b_F88us33gCmRBLjU59fPPg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: stephane.proust@orange.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Confirmation of consensus on 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: Tue, 21 Aug 2012 15:35:18 -0000

On Tue, Aug 21, 2012 at 12:57 AM,  <stephane.proust@orange.com> wrote:

> In addition, we believe that two additional requirements are necessary to make WebRTC a future proof technology and suitable for a wide range of applications and environments:
> Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB.
> Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser.
>
>
 Stephane,

On you first point, the fundamental design of RTCWEB allows for the
negotiation of any codec mutually supported.  The decision to chose a
Mandatory-to-implement was not made to eliminate other choices, but to
eliminate interoperability failures by ensuring that at least one
common codec is always available.

On your second point, the group presumes that codec support does not
come from the downloadable Javascript application, but from the
application environment into which it is downloaded (commonly a
browser or mobile environment using similar technology).  Promoting
support for those environments to have access to codecs supported by
the underlying hardware is the best way to further this goal, at least
in my personal opinion.

best regards,

Ted Hardie