From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= <denglingli@chinamobile.com>
To: "'Paul Coverdale'" <coverdale@sympatico.ca>, "'Hutton,
 Andrew'" <andrew.hutton@siemens-enterprise.com>, "'Bogineni,
 Kalyani'" <Kalyani.Bogineni@VerizonWireless.com>,
 "'Bo Burman'" <bo.burman@ericsson.com>, <rtcweb@ietf.org>
References: <BBE9739C2C302046BD34B42713A1E2A22DEE3029@ESESSMB105.ericsson.se>	<20130716170223.B5DD911E80D7@ietfa.amsl.com>	<9F33F40F6F2CD847824537F3C4E37DDF1164B89C@MCHP04MSX.global-ad.net>
 <BLU0-SMTP56EF44A5EA6EA09EDECAB9D0620@phx.gbl>
In-Reply-To: <BLU0-SMTP56EF44A5EA6EA09EDECAB9D0620@phx.gbl>
Date: Fri, 19 Jul 2013 13:33:42 +0800
Message-ID: <00b801ce8441$88198e80$984cab80$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3ABDXdRAACEuDYAAOgsjMAAf0RCw
Content-Language: zh-cn
Subject: [rtcweb] =?utf-8?b?562U5aSNOiAgU29tZSB0aG91Z2h0cyBvbiBvcHRpb25h?=
 =?utf-8?q?l_audio_codecs?=
Precedence: list

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

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org =
[mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Paul Coverdale
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8818=E6=97=A5 =
20:25
=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Hutton, Andrew'; 'Bogineni, Kalyani'; 'Bo =
Burman'; rtcweb@ietf.org
=E4=B8=BB=E9=A2=98: 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On =
Behalf
>Of Hutton, Andrew
>Sent: Wednesday, July 17, 2013 4:46 AM
>To: Bogineni, Kalyani; 'Bo Burman'; rtcweb@ietf.org
>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: 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=C3=A4r=C3=B6gatan 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
>_______________________________________________
>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