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

["Ravindran Parthasarathi" <[e-mail]>]

I agree with Hadriel for PSTN interop.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Hadriel Kaplan
>Sent: Sunday, September 11, 2011 7:21 PM
>To: Cullen Jennings
>Cc: <[e-mail]>
>Subject: [rtcweb] Supporting legacy PSTN interop (was: Use of offer /
>answer semantics)
>
>
>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
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb