IETF Logo Mail Archive

Re: [rtcweb] RTCWEB needs an Internet Codec

Ted Hardie <ted.ietf@gmail.com> Thu, 06 September 2012 00:02 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 2DAA521F8508 for <rtcweb@ietfa.amsl.com>; Wed, 5 Sep 2012 17:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5UK4c1YxRrcI for <rtcweb@ietfa.amsl.com>; Wed, 5 Sep 2012 17:02:39 -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 9A9C321F8505 for <rtcweb@ietf.org>; Wed, 5 Sep 2012 17:02:39 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so1761145vcb.31 for <rtcweb@ietf.org>; Wed, 05 Sep 2012 17:02:39 -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=ZD9ZatdWoLLjm6kzMvqjemRV97oB7EqyYbpu8u8W6Tg=; b=PoJKLWvKq8oDYpS8fHLRfb56SElXMatlATsy4qbjAQ8qnjBS2Hr9rgyKfe1Bu5NS/J 1JO+59+XK7g2llRuWhfwzY43+pJEQmNQkGySQb6QJcmL1Q18kQeVAw6OVKVvMAdfsQG5 0jVJgtlCE/VtRhcL1Clcu6IWzWGmaA2Dti8e1sJ56lOg04xC9dy2rSL71KvWUViEbJQL P8uaDAOqytubrDBPrGcOs3+UVmqqes2S3NC2nfw0L5yMo+CwIb/wgTowf2ZGjaEPuVjQ QJLafhY7wDIobqy5W1aCGeO0h4SePkdYLgirm9ZmTUrlW/UqVGmRIeNiuwZIMmI3aL0w dBFw==
MIME-Version: 1.0
Received: by 10.52.32.99 with SMTP id h3mr138152vdi.108.1346889759112; Wed, 05 Sep 2012 17:02:39 -0700 (PDT)
Received: by 10.58.201.226 with HTTP; Wed, 5 Sep 2012 17:02:39 -0700 (PDT)
In-Reply-To: <p06240609cc6d8e39fb6c@99.111.97.136>
References: <CAC8DBE4E9704C41BCB290C2F3CC921A162D278D@nasanexd01h.na.qualcomm.com> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <CAD6AjGToznJtNdSzyFbxKhhXQTLTuOWnPutOYDCQCVH_8mRZ5w@mail.gmail.com> <20120901031955.GF23434@audi.shelbyville.oz> <CAD6AjGTN6JTQ50bj-6v2vvw56HOWNA7VmP-BZFwNWiX-c0AAnA@mail.gmail.com> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <p06240608cc66e4862829@99.111.97.136> <00a701cd89fc$e681e9d0$b385bd70$@us> <p06240601cc6aa58a7171@99.111.97.136> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120901061236.GH23434@audi.shelbyville.oz> <20120904210055.GN23434@audi.shelbyville.oz> <p06240609cc6d8e39fb6c@99.111.97.136>
Date: Wed, 05 Sep 2012 17:02:39 -0700
Message-ID: <CA+9kkMD6o7AFJxAwd27-vQ=_zNEwXRBuEybcc5k8yNKSkSya=A@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Randall Gellens <randy@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
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, 06 Sep 2012 00:02:40 -0000

On Wed, Sep 5, 2012 at 4:29 PM, Randall Gellens <randy@qualcomm.com> wrote:
> The discussion is over which codecs MUST be supported.  Since mandatory
> codecs are required, with no choice, they should have the lowest possible
> burden to implement, taking into account all aspects of the implementation
> burden.

Speaking personally, I would put this slightly differently.  After
all, a codec with low implementation burdens may have very poor
bandwidth consumption characteristics, relatively inferior acoustic
range, or other problematic aspects which don't read on the
implementation burden.

As you note below, the overall problem is one of cost/benefit
analysis.  In the end, we need to find a way to avoid implementation
failure with a set of choices that represent the best overall
cost/benefit ratio in the contexts identified by our use cases.

>Then, implementers are free to consider which additional codecs
> they will support, taking into account the costs and benefits.

Absolutely.

regards,

Ted Hardie

v2.23.0 | Report a Bug | By Email