[rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics)

[Hadriel Kaplan <[e-mail]>]

On Sep 6, 2011, at 9:45 PM, Cullen Jennings wrote:

> 
> On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote:
> 
>>> The primary issues identified with this was concerns over mapping this to legacy SDP.
>> 
>> This makes the assumption that the primary use case will have things that speak only SDP offer/answer on the far side. I think that's a very IETF + SIP + legacy point of view, which is an unfortunate way to approach the future of communications as enabled by web applications.
> 
> I'm not assuming anything about this being the primary use case. I'm assuming it is an important use case. If it were not, we would do this totally differently probably starting with not using RTP, certainly not using SDP or offer/answer, and I'd argue for a p2p (in the overlay network sense of the term) form rendezvous - there would be people on the list point out if we use used HIP, everything would be done. We are not doing that because it is an import use case.  The reason it is important is because that is the way we connect this to the existing voice and video communication infrastructure that currently supports well over 4 billion users and probably over 5 billion. We already have a boat load of solutions to this problem if we don't care about legacy. That Flash stuff seems to be in lots of browsers and work fine to other browsers - but I want more than that. For the same reason IPV6 device that can't connect to anything V4 are much less interesting than devices that c
> an connect to both, I want interoperability with the past (meaning all the existing deployments) and path for an interesting future. Either one by itself is not enough. 
> 

I don't see how the current rtcweb direction could really do that.  If you really want to interop with the 5 billion PSTN/IMS users without a gateway "interworking" rtcweb media to legacy SIP-based media, the rtcweb browser would have to mandate support for G.711, AVP rather than AVPF, support NOT using ICE, support not using SRTP, and not multiplexing RTP/RTCP.  If ICE remains mandatory to use, then there'll have to be some media-layer ICE terminator (or TURN server) to interop with the PSTN no matter what.  

The odds are there'll be some form of SBC at the border of the SIP-PSTN provider anyway (e.g., an IBCF), but the question is whether it'll be the PSTN providers that have to pay the additional cost to interop with rtcweb media, or whether it'll be the rtcweb service provider who also have to deploy gateways.  At the end of the day it costs money to interwork this stuff - i.e., more hardware/blades/CPUs/whatever.  So even if the PSTN providers already use SBCs and they're the ones doing the interop work, it'll cost more either in the form of more SBCs, or higher-scale hardware in them.

Generally the most expensive thing would be to make the gateway/SBC have to transcode, so if we could at least mandate rtcweb clients support G.711 and AVP, that would be good.  It would really suck if every call to/from the PSTN had to be transcoded from opus/AVPF to G.711/AVP, when G.711/AVP is royalty free (and trivial relative to opus/avpf).

-hadriel