Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
Christer Holmberg <christer.holmberg@ericsson.com> Sun, 30 October 2011 16:03 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAE921F8B49 for <rtcweb@ietfa.amsl.com>; Sun, 30 Oct 2011 09:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.777
X-Spam-Level:
X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5ecnRfeY0s5 for <rtcweb@ietfa.amsl.com>; Sun, 30 Oct 2011 09:03:07 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2511921F8B43 for <rtcweb@ietf.org>; Sun, 30 Oct 2011 09:03:06 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-a3-4ead75372c64
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CD.DD.13753.7357DAE4; Sun, 30 Oct 2011 17:03:04 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 30 Oct 2011 17:03:03 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Iñaki Baz Castillo <ibc@aliax.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Sun, 30 Oct 2011 16:58:09 +0100
Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
Thread-Index: AcyWYE5k7XnXBTfwTS2iFiRnk8hglwAvGn++
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se>
References: <CALiegfkikmpi55ePUo=AQCQvorv4_6v2ByTCdL=V_=umcCEpUA@mail.gmail.com>
In-Reply-To: <CALiegfkikmpi55ePUo=AQCQvorv4_6v2ByTCdL=V_=umcCEpUA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Oct 2011 16:03:10 -0000
Hi, I don't like the idea of having to send UPDATE/re-INVITE for every new early dialog. In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real answer, the UAC is not allowed to send an UDPATE. In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. In such case there is no need to send an UPDATE. Regards, Chrsiter ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo [ibc@aliax.net] Sent: Saturday, October 29, 2011 8:29 PM To: rtcweb@ietf.org Subject: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Hi, the next suggestion would allow media serial/parallel forking scenarios when interoperating with a SIP network. It is just a *suggestion*. Assumtions ------------------ - WebRTC specs don't allow sharing a local PeerConnection for sending and receiving media to/from more than a single remote peer. - The remote pure SIP peers implement ICE+SRTP and can interoperate with a WebRTC client in the media plane without requiring media gateways. The problem ------------------ Let's assume a WebRTC client implementing SIP at JavaScript level (although there could be a signaling gateway). - The WebRTC client makes an outgoing call which arrives to a SIP proxy and forking occurs (serial or parallel). - The WebRTC client receives more than a single SIP 183 response with different To-tags and different SDPs (so they are different remote SIP peers). - And/or the WebRTC client receives a 200 OK with a Totag and SDP different than the one received in the previous 183. In this case, given the first assumption above, the WebRTC client must choose a single remote SIP peer and can just send and receive media to the chosen peer (limitation 1). If the SIP 200 OK arriving to the WebRTC client belongs to a remote peer different than the chosen one, the WebRTC client cannot reuse the already open local PeerConnection since it was created passing it a different remote SDP (limitation 2). Solution ------------ - The WebRTC client sends the call and receives a 183 with Totag "AAAA" and SDP "SDP_A" from SIP_PEER_A. - It creates a PeerConnection passing it "SDP_A", sends like a ROAP Answer to the peer and media flow starts between client and SIP_PEER_A. - Later (or very soon) another 183 with Totag "BBBB" and SDP "SDP_B" arrives to the WebRTC client from SIP_PEER_B. - The client creates a *new* PeerConnection *without* passing it "SDP_B" and sends a SIP UPDATE with the associated ROAP Offer to SIP_PEER_B. - If SIP_PEER_B implements SIP UPDATE it will reply a 200 OK with a new "SDP_B2" (it could be the same as "SDP_B"). - The client then passes "SDP_B2" to the second PeerConnection and media flow starts between client and SIP_PEER_A. - Later a SIP 200 OK with Totag "CCCC" and SDP "SDP_C" arrives to the client from SIP_PEER_C. - The client creates a *new* PeerConnection *without* passing it "SDP_C" and sends a SIP re-INVITE with the associated ROAP Offer to SIP_PEER_C. - SIP_PEER_C will reply a 200 OK with a new "SDP_C2" (it could be the same as "SDP_C"). - The client then passes "SDP_C2" to the third PeerConnection and media flow starts between client and SIP_PEER_C. At the same time the client destroys the first and second PeerConnections. And we are done. Limitation solved. Of course if SIP_PEER_B does not implement UPDATE we have a problem, but RFC 3311 (SIP UPDATE Method) is a standard since 2002, come on! Conclusion ---------------- SIP media forking can be implemented in JavaScript without mandating special requirements in WebRTC for interoperating with "legacy" SIP (why do we call "legacy" to SIP???). And we just need tu use existing SIP mechanisms. No signaling gateway is required (of course !!) nor a media gateway (if second bullet in "Assumtions" section above is satisfied). We all are happy (but those who have in mind a market selling WebRTC-SIP gateway boxes and want that the specs satisfy their business model). -- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Media forking solution for SIP interoper… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Stefan Håkansson
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Cullen Jennings
- Re: [rtcweb] Media forking solution for SIP inter… Harald Alvestrand
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Ravindran Parthasarathi
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Christer Holmberg
- Re: [rtcweb] Media forking solution for SIP inter… Ravindran Parthasarathi
- Re: [rtcweb] Media forking solution for SIP inter… Bernard Aboba
- Re: [rtcweb] Media forking solution for SIP inter… Iñaki Baz Castillo
- Re: [rtcweb] Media forking solution for SIP inter… Hadriel Kaplan