Re: [rtcweb] Some thoughts on optional audio codecs

[<[e-mail]>]

It would be good to close this voice/audio codecs topic with an agreeable minimum "conclusion statement" 

My recollection is that the proposed statement is exactly the compromise statement that was almost reached in e-mail discussions last January (from an initial proposal from Andrew Allen) 

>> "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".

This came along with the conclusion from the Chairs that it would be of interest to have some additional informative 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/msg06167.html

So, if this is the way to move forward and make at least one small step to conclude something, yes this sounds reasonable and I support this.

Stéphane

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de ???/Lingli Deng
Envoyé : vendredi 19 juillet 2013 07:34
À : 'Paul Coverdale'; 'Hutton, Andrew'; 'Bogineni, Kalyani'; 'Bo Burman'; [e-mail]
Objet : [rtcweb] 答复: Some thoughts on optional audio codecs

We also support this proposal.

In particular, I think it makes sense to allow the codec choice be possibly delegated to individual web developers making use of WebRTC functionality.
Therefore, it would be better for them to be informed of available options and make the decision accordingly.
While it is not realistic to assume that a browser could always implement a best choice for every potential setting, to include other available codec in the offer would open the door to a win-win outcome.

BR
Lingli

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Paul Coverdale
发送时间: 2013年7月18日 20:25
收件人: 'Hutton, Andrew'; 'Bogineni, Kalyani'; 'Bo Burman'; [e-mail]
主题: Re: [rtcweb] Some thoughts on optional audio codecs

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

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
[e-mail]
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.