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

[Andrew Allen <[e-mail]>]

My response was directed to the current deployment situation and the comment/concern that currently the pre standard RTCweb browser implementations do not support Codecs used in some legacy networks.

While the technology may be there and the products even available they are not widely deployed today so currently there is not a business case for browser vendors to include these codecs as today practical interoperability is not possible.

Right now browser implementors are focused solely on achieving interoperability between browsers I expect. The additional codecs for legacy interop will I expect come in the future when the infrastructure is deployed to make this possible and if the right business case is there to make it commercially viable.

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:[e-mail]]
Sent: Thursday, March 14, 2013 05:37 PM Central Standard Time
To: Andrew Allen
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01


On Mar 14, 2013, at 5:09 PM, Andrew Allen <[e-mail]>
 wrote:

> Koen is right that there are many more obstacles to RTCweb and legacy network interop than just a common codec. First there will need to be RTCweb signaling gateways to interface between the RTCweb signaling and the legacy networks (SIP, H.323 etc) and there will need to be in place mechanisms for peering, federation and address resolution between networks as well as service agreements in place between the players.
> 
> Until those are resolved supporting codecs used in those networks is pointless.

There are already WebRTC-SIP gateways, as I think you know.  I know of two SBC vendors who are in customer labs with it, for example, and there are probably more.  And yes at least one of them, and probably both, can transcode the audio... though it's by no means free.  I don't know if the business case justifies the cost or not for WebRTC use-cases - it appears to in some cases, not others.

It costs far more than has been discussed on this list though, because we think like engineers and consider the cost as a CAPEX issue; whereas in practice the OPEX costs often dwarf the CAPEX ones.  In some data centers, for example, the local Real-Estate costs dwarf CAPEX too, and using less rack-space can pay for a product in no time. (there's an entire company out there that built its business leveraging this fact, replacing POTS switches with much-higher-density ones purely based on rack-space usage savings)

Anyway... moving on to your other point of federation/peering/etc. - I think the use-case that mobile operators have in mind is fairly obvious, and it clearly doesn't have that problem.  Whether you agree with helping that use-case or not is up to you and the rest of this WG, of course.  I'm just noting that peering isn't an obstacle for it.

-hadriel
p.s. Transcoding video, on the other hand, is untenable for pretty much anyone.  I have never heard of a business-case which justifies it, because it simply doesn't scale.  Except for maybe companies that live on other revenue sources, for whom all of this stuff is a rounding error in their IT budget. ;)


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