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

"Ravindran Parthasarathi" <> Sun, 11 September 2011 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5908021F8A58 for <>; Sun, 11 Sep 2011 12:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JvomghqXivz2 for <>; Sun, 11 Sep 2011 12:34:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7502021F8A57 for <>; Sun, 11 Sep 2011 12:34:21 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p8BJahhT006798; Sun, 11 Sep 2011 15:36:43 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 15:36:13 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Sep 2011 01:06:09 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics)
Thread-Index: AQHMcIniZ46zQg8sI0u9j63r6cyTz5VIkV5A
References: <><><> <>
From: Ravindran Parthasarathi <>
To: Hadriel Kaplan <>, Cullen Jennings <>
X-OriginalArrivalTime: 11 Sep 2011 19:36:13.0530 (UTC) FILETIME=[10D193A0:01CC70BA]
Subject: Re: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Sep 2011 19:34:22 -0000

I agree with Hadriel for PSTN interop.


>-----Original Message-----
>From: [] On
>Of Hadriel Kaplan
>Sent: Sunday, September 11, 2011 7:21 PM
>To: Cullen Jennings
>Cc: <>
>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
>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
>  c
>> an connect to both, I want interoperability with the past (meaning
>the existing deployments) and path for an interesting future. Either
>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
>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).
>rtcweb mailing list