Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

Tim Panton <tim@phonefromhere.com> Thu, 12 September 2013 09:54 UTC

Return-Path: <tim@phonefromhere.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 6C11421E8091 for <rtcweb@ietfa.amsl.com>; Thu, 12 Sep 2013 02:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzphrNcF6V8i for <rtcweb@ietfa.amsl.com>; Thu, 12 Sep 2013 02:54:12 -0700 (PDT)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 3577611E81BF for <rtcweb@ietf.org>; Thu, 12 Sep 2013 02:54:11 -0700 (PDT)
Received: (qmail 23002 invoked from network); 12 Sep 2013 09:54:09 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 12 Sep 2013 09:54:09 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9A24118A0AE3; Thu, 12 Sep 2013 10:54:09 +0100 (BST)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6F43318A0462; Thu, 12 Sep 2013 10:54:09 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup>
Date: Thu, 12 Sep 2013 10:54:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E948534-4ADA-4CB7-8705-C970E5294ACD@phonefromhere.com>
References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <BBE9739C2C302046BD34B42713A1E2A22DF83C31@ESESSMB105.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <BBE9739C2C302046BD34B42713A1E2A22DF88232@ESESSMB105.ericsson.se> <CAGgHUiSK-bZrdXtxf-An8NM+pw-iqoWCrsG_bRUpxcD2DOCQrQ@mail.gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> <522F4836.6030001@mozilla.com> <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup>
To: stephane.proust@orange.com
X-Mailer: Apple Mail (2.1283)
Cc: "'rtcweb@ietf.org'" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt
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, 12 Sep 2013 09:54:17 -0000

As I said last time this came up, we need to include language that ensures that these non-mandatory codecs don't 
get used unless the mandatory ones are unavailable, or the web developer explicitly selected them.

I don't want to find that I'm getting amr-nb between a pair of phone based browsers and getting narrow band because
both the phones happen to have that codec available.


How about: 

To ensure a baseline level of interoperability between WebRTC clients, 
a minimum set of required codecs are specified below.
If other suitable audio codecs are available to the browser to use, it 
is advised that they are also included in the offer at a lower priority than the required codecs in order to 
maximize the possibility to establish the session without the need for 
audio transcoding when the required codecs are unavailable to one party.


- Of course this whole discussion highlights the need for a set of constraints (or an API) that let the web developer 
express her preferences wrt codec selection.


Tim.

On 11 Sep 2013, at 10:19, <stephane.proust@orange.com> <stephane.proust@orange.com> wrote:

>> These are the codecs that would be recommended under such text. None of them is really ideal for interactive audio
> 
> That is the reason why the proposed text only applies to "suitable" audio codecs
> " If other suitable audio codecs..."
> 
> That's also why it cannot be interpreted as a strictly normative text and why I also suggested (as it was previously suggested by the Chairs) to have some additional informative (and separate) text about what are those suitable codecs to be considered and what is the rationale behind this (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html)
> 
> Stéphane
> 
> 
> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin
> Envoyé : mardi 10 septembre 2013 18:27
> À : Mo Zanaty (mzanaty)
> Cc : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt
> 
>> To ensure a baseline level of interoperability between WebRTC clients, 
>> a minimum set of required codecs are specified below.
>> If other suitable audio codecs are available to the browser to use, it 
>> is RECOMMENDED that they are also included in the offer in order to 
>> maximize the possibility to establish the session without the need for 
>> audio transcoding.
> 
> Let's look at the practical effect here, assuming people were to actually follow such a recommendation. The only audio codecs that are implemented in browsers but not available for WebRTC are the ones used for HTML5. According to http://html5test.com/ these codecs are Vorbis, MP3, AAC, and uncompressed PCM. These are the codecs that would be recommended under such text. None of them is really ideal for interactive audio, none of them is implemented in old phones AFAIK, but all of them would require time and effort to add to a browser's RTP stack. I really don't see the point here.
> 
> 	Jean-Marc
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb