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

[Tim Panton <[e-mail]>]

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

> 
> 13 mar 2013 kl. 23:48 skrev <[e-mail]>:
> 
>> 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.