Re: [rtcweb] Some thoughts on optional audio codecs

[Paul Coverdale <[e-mail]>]

Yes, this text has been around for a while. I also support it.

...Paul

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Hutton, Andrew
>Sent: Wednesday, July 17, 2013 4:46 AM
>To: Bogineni, Kalyani; 'Bo Burman'; [e-mail]
>Subject: 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Bogineni, Kalyani
>> Sent: 16 July 2013 18:02
>> To: 'Bo Burman'; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Bo Burman
>> Sent: Monday, July 15, 2013 11:15 AM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb