Re: [rtcweb] Some thoughts on optional audio codecs

We appear to have been around this loop a number of times the text suggested here is exactly what was suggested by Andrew Allen back in January and I for one supported it them and still do - See http://www.ietf.org/mail-archive/web/rtcweb/current/msg06121.html.

Not sure there was a definitive conclusion to that particular consensus call.

Andy

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Bogineni, Kalyani
> Sent: 16 July 2013 18:02
> To: 'Bo Burman'; rtcweb@ietf.org
> Cc: Bogineni, Kalyani
> Subject: Re: [rtcweb] Some thoughts on optional audio codecs
> 
> We support the following wording proposal from Bo Burman.
> 
> "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".
> 
> Regards,
> Kalyani Bogineni
> Verizon
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Bo Burman
> Sent: Monday, July 15, 2013 11:15 AM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Some thoughts on optional audio codecs
> 
> Regarding the previous discussion on optional audio codecs in the
> (currently expired) draft on RTCWEB audio codecs
> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/)
> 
> I think most parties involved in WebRTC work, myself included, hope and
> believe that it will be ubiquitous and easy to include real-time media
> conversation functionality in nearly any web context. Since it will be
> that easy, it can be expected that most web developers need not be, and
> thus will not be, media specialists or very knowledgeable about codecs.
> 
> The definition of RTCWEB MTI codecs ensures that communication is
> possible since at least one codec will always be found, but it is not
> possible to claim the resulting communication to be optimum for every
> possible context.
> 
> Even if WebRTC will be close to ubiquitous, there will for quite some
> time likely be a desire to reach real-time media domains and devices
> that were not originally designed for and thus are not optimized for
> use with WebRTC. A communication device that is not designed solely for
> WebRTC use will likely include functionality and codecs also for its
> "native" domain.
> 
> Any added cost of not being able to use existing "native" codecs will
> vary both in amount and where the cost has to be taken. Eliminating it
> is indeed an optimization, but the total cost savings may still be
> significant.
> 
> With the current design and to my understanding, it will be the browser
> vendor's choice to add optional codecs, including any "native" domain
> codecs.  The choice may possibly be delegated to individual web
> developers making use of WebRTC functionality. A browser vendor will
> arguably have to know each target platform to some extent, but it can
> hardly be assumed that a web developer knows the capabilities of all
> devices that will use the WebRTC-enabled site unless the browser can
> provide the needed information. There is a risk that "native" codecs in
> devices are not well handled, unless the motivations and methods to
> make use of them are better specified.
> 
> While any audio codecs besides the MTI ones are clearly optional, I
> believe the suggested text addition on optional audio codecs to the
> RTCWEB audio draft in Ticket #12
> (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) to be too brief
> considering the above.
> 
> In that draft, I would prefer something more in line with:
> 
> "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".
> 
> Assuming that the browser vendor (or web developer) is sufficiently
> concerned with codecs to read the audio codecs draft (or the
> corresponding RFC to-be), the above text may, as a start, give some
> added guidance why non-MTI codecs may be desirable to consider in
> addition to the MTI ones.
> 
> Cheers,
> Bo
> 
> Multimedia Technologies
> Ericsson Research
> Färögatan 6
> SE-164 80, Kista, Sweden
> www.ericsson.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb