Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Tim Panton <tim@phonefromhere.com> Thu, 14 March 2013 11:01 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 0ADE621F8E1D for <rtcweb@ietfa.amsl.com>; Thu, 14 Mar 2013 04:01:33 -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=[AWL=0.000, 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 R20MyLi4huXL for <rtcweb@ietfa.amsl.com>; Thu, 14 Mar 2013 04:01:32 -0700 (PDT)
Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51721F8DF9 for <rtcweb@ietf.org>; Thu, 14 Mar 2013 04:01:30 -0700 (PDT)
Received: (qmail 59010 invoked from network); 14 Mar 2013 11:01:28 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 14 Mar 2013 11:01:28 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BA8EF18A02BC; Thu, 14 Mar 2013 11:01:28 +0000 (GMT)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9596618A021C; Thu, 14 Mar 2013 11:01:28 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <B94296F8-EFD8-424D-A09E-B2151427CD7D@edvina.net>
Date: Thu, 14 Mar 2013 11:01:27 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1012AF5-854E-4B7E-BA1E-F258B4B0775A@phonefromhere.com>
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup> <BBF5DDFE515C3946BC18D733B20DAD2338D28EA3@XMB104ADS.rim.net> <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <B94296F8-EFD8-424D-A09E-B2151427CD7D@edvina.net>
To: Olle E. Johansson <oej@edvina.net>
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, MARJOU Xavier OLNC/OLN <xavier.marjou@orange.com>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
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, 14 Mar 2013 11:01:33 -0000

On 14 Mar 2013, at 07:51, Olle E. Johansson wrote:

> 
> 13 mar 2013 kl. 23:48 skrev <stephane.proust@orange.com>om>:
> 
>> The reason is simply that AMR and AMR-WB are supported in billions of devices !
> I think it's time to stop discussing historical numbers, current numbers and future numbers of installed codecs in various devices. We're all impressed, but it doesn't seem to change our position on the MTI codec list.
> 
> This is a very complex matrix and the codec landscape is every changing. That's why the offer/answer exchange is open for future additions. SIP only mandated a very small set of codecs in RFC 3261 over ten years ago. That did not stop the use of AMR, G722, H.264 or other codecs in SIP devices today. I've even seen Opus being used in SIP without updating RFC 3261. 
> 
> I'm pretty sure I will see quite a lot of offers with both AMR and H264 in WebRTC, as I have met them many times in my SIP life.
> 
> It seems that we need to clarify this openness to use any codec in the specification, since it seems to be widely misunderstood.

What this discussion leads to is the need for application authors to be able to dynamically add codecs.
We need an API that supports codec insertion by the hosting web-site. 
This would have 2 advantages:
	1) sites with specific needs would be able to supply codecs that were licensed per-user 
(so MNOs could supply AMR-WB for the duration of a call, even to devices that don't normally support it - e.g. laptops )
(Cisco could supply h264 for a webex session)
	2) we future proof the WebRTC API - so when a new codec arrives that is especially good for watching small white dots moving at high speed,
the golf sites can use it.

In essence, extending the API using technology like Google's NaCl to deliver new codec, this decouples the supported  codec selection decision from the browser makers and pushes it up to the Application vendors.

Note, I'm not saying we should do this now. I am saying we should do this as a revision to webRTC - and yes, this discussion probably belongs in w3c land.

Tim.