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

["DRAGE, Keith (Keith)" <[e-mail]>]

And too many people are hiding behind the statement "we don't own all the problem" to ensure there will be no solution to the problem.

At the end of the day, the example already given of someone having had to pay for an AMR licence for an i-phone should not exist, because it means there are now two licensed versions of that codec on the i-phone.

Regards

Keith

________________________________
From: Andrew Allen [mailto:[e-mail]]
Sent: 13 March 2013 18:06
To: DRAGE, Keith (Keith); [e-mail]; [e-mail]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01


Keith

That is out of scope of IETF. What I think you are suggesting amounts to operating system standardisation.

If you believe in the market then the business case of the browser implementers and the device vendors should align with the interests of the users (I.e their customers) assuming the costs are not prohibitive.

Andrew



From: DRAGE, Keith (Keith) [mailto:[e-mail]]
Sent: Wednesday, March 13, 2013 12:36 PM Central Standard Time
To: Andrew Allen; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

The problem is that the business case for the device vendor or end user may not be the business case for the browser vendor.

To be honest this discussion goes round and round in circles, with people trying to say things are out of scope.

What I believe we need is something that encourages creation of APIs for embedded codecs in the devices. Those API's should then be made available within the browser.

This gets even more important when we get to video codecs. I am certainly interested in gateways from RTCWEB endpoints to other SIP based networks. Having to transcode from one video codec to another because of this impasse is a nightmare.

Someone has to break this loop.

Keith

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Andrew Allen
Sent: 13 March 2013 17:30
To: [e-mail]; [e-mail]
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01


If there is a business case for implementers to support other codecs for improved inteoperability with other networks and devices then they are very likely to do so.



From: Roman Shpount [mailto:[e-mail]]
Sent: Wednesday, March 13, 2013 12:12 PM Central Standard Time
To: [e-mail] <[e-mail]>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Normally, when implementing VoIP devices, unless they are intended for some sort of walled garden, you try to support as many codecs as possible. This increases your chances of interoperability with other devices and your product adoption. In case of WebRTC, it would be adopted regardless of what codecs are supported. The number of enabled devices would be so great that all the legacy networks will have to adapt. This has some negative implications to the legacy networks as far as quality and costs are concerned, but these challenges are not insurmountable. So, taking this into consideration, I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs except MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that would make browser manufacturers to change their mind? After all, this represents additional cost to them with no direct benefit for the use cases which are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next few years, do support a reasonable set of other codecs in addition to MTI, including G.722, AMR, AMR-WB, and may be Speex, . This would give me an opportunity to migrate from devices that support legacy codecs to devices that support Opus. The fact that different browser versions would support different codec sets (like desktop browsers not supporting AMR) is not a big issue, at least for me, since we always have G.711 or transcoding to fall back to. The same goes for browsers fazing some of the legacy codecs out in the future. The end result would still be better then 100% G.711 or transcoding.
_____________
Roman Shpount

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.