Re: [rtcweb] State of the Forking discussion
Cullen Jennings <fluffy@cisco.com> Tue, 08 November 2011 22:50 UTC
Return-Path: <fluffy@cisco.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 1F6CE21F8B05 for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 14:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.122
X-Spam-Level:
X-Spam-Status: No, score=-107.122 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Ojc5tbhOMGyU for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 14:50:49 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 052B921F8B03 for <rtcweb@ietf.org>; Tue, 8 Nov 2011 14:50:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=9190; q=dns/txt; s=iport; t=1320792634; x=1322002234; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RP3p8FLcwVCqTdHH1bGaglSOSzZczRbWwQEdikb9k1U=; b=YJ1benG8QuQTMKNhMmCqr07zIZmsyQVFwUJB5ECfHXrXcSYPAL6OUVrz VYs4tACr9dSd2bnU+sbS5/MXBmrodf0L7xB2Nz9neLil/joJRnCgXcawP 0OKKqhfMjAvciX7+P4yGtAmth5qfBlSDy8KhRk1Z6Xji742krb0iE1QQh w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am0FAASyuU6rRDoG/2dsb2JhbABDqH2BJoEFgXIBAQEDAQEBAQkGAVsLBQkCCz8HGwwfEQYTGweHYAiZMwGeYwQCiEhjBIgLjBaFMYxd
X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13069372"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2011 22:50:33 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA8MoWQM023260; Tue, 8 Nov 2011 22:50:33 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4EB26945.40607@ericsson.com>
Date: Tue, 08 Nov 2011 15:50:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com>
References: <4EB26945.40607@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] State of the Forking discussion
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: Tue, 08 Nov 2011 22:50:50 -0000
<in my individual contributor role> Much of this I don't feel too strongly about but there is one thing that I do have a strong opinion on. I don't want to require PRACK for legacy SIP support because it is has many problems. Cullen On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote: > WG, > > I just reviewed the last weeks Forking discussion. This includes the > threads "RTCWeb Forking usecase [was RE: > draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media > forking solution for SIP interoperability (without a media gateway)" > > As far as I can tell there is not yet even a rough consensus. Therefore > I will attempt to summarize what I personally believe to be the > important points and alternatives in this discussion. Keep in mind that > my assumptions or understanding may be unclear or have errors. So don't > hesitate to challenge what I write. > > I think it is important that there are in fact at least two important > questions here. > > 1. Is forking needed to be supported at all? > > 2. If it is supported in which form would it supported in. > > so lets start looking into the arguments and possibilities for these two > questions. And I do hope that you will read to the end of this mail > which is quite long. > > Lets start with the high level functionality part. Is forking needed and > what usage does it have. So forking is all about sending out an > invitation to a media session including an actual media configuration > offer, i.e. SDP Offer, then get more than a single answer to that offer > back. How you deal with these answers as they come in is the difference > between serial and parallel forking. So lets define those. > > Parallel forking: For each answer you receive you establish a new actual > media session. Thus if you receive two answers you will have to > different media sessions that are potentially in use at the same time. > > Serial forking: The first answer is received and results the > establishment of a media session. At a later point in time a second > answer is received. At that point you take the decision if that second > answer is going to be used to establish a new media session that > replaces the first one. In other words at any given time you will only > have a single media session established based on each offer. > > So there has been a number of different views on how one can see on > forking. And I think I will have to bring in a bit reflections on how > this can be done with the current PeerConnection API. > > A) No forking is needed: Between WebRTC end-points there is no need for > forking. Instead the application can send out session invitations to the > peers it wants to talk to. These are without any SDP Offer equivalent, > instead end-points that want to communicate they create PeerConnections, > which results in SDP Offers. Thus the communication initiating end-point > becomes the ones that provides SDP answers and get one PeerConnection > per remote end-point that actually want to communicate. > > B) We need to have some interworking with SIP: So the fundamental here > is that it needs to be reasonable to interwork with SIP, independent if > one uses a SIP in JS in the application running on the WebRTC enabled > browser, or have signalling gateway in the webserver, or as a remote > WebRTC peer. The issue is that A)'s method of initiating call doesn't > work well with SIP. There is a need to send a SIP Invite with an SDP > Offer and that can result in multiple answers. > > To resolve this one could deal with this in a couple of different ways: > > B1) Use Iñaki's proposal which forces the WebRTC application to create a > second PeerConnection and then forces an update in the SIP domain with > the second peer-connections Offer. However, it was pointed out that this > doesn't work with SIP Provisional answers, as used by ICE for example, > unless PRACK is supported. The level of PRACK support is reasonable but > far from universal so this would limit the SIP UAs one can interwork > with. However, from WebRTC perspective no forking support is needed. A > single PeerConnection results in one offer and a single answer is > processed. > > B2) Require WebRTC to handle replace Answers: So the idea here is that > one changes the PeerConnection API and have underlying functionality so > that at any point in time a new Answer can pushed onto a PeerConnection > and that forces the media session to be reestablished if needed. So if > the ICE candidate list is different an ICE restart happens. This clearly > supports serial forking. It also can create some complexities in the > underlying SDP handling logic if one desires to minimize the media impact. > > B3) Local side shared parameters in multiple PeerConnections: The idea > in this proposal is that all PeerConnections generated in a browser > context, like a tab will implicit share the fundamental parameters like > ICE candidates etc for the number of media streams added. So if one > creates a second PeerConnection with the same audio+video MediaStream > object added I will get an offer that is mostly identical to the the > first PeerConnection, thus I can push in the answer from the first > PeerConnection Offer into the second PC object and it will still work. > The downside of this is that it is implicit and it becomes difficult to > determine when it works and when it will fail. It will also be highly > dependent on the application performing the right process to get it to > work. It also causes a sharing of the parameters when not needed or > desired, which primarily is an issue from a security point of view, > especially with SDES keys (see below). The positive is this likely > requires no API changes. This method would also support parallel forking. > > B4) Cloning/Factory for PeerConnection: On the API level there will be > explicit support for generating multiple PeerConnections from the same > base. This could either be a factory for PeerConnections or some Object > constructor that clones an existing PeerConnection but that is a W3C > question. By being explicit some of the B3) issues goes away and the > applications can choose when this should happen or not. This also > support parallel forking as the application can deal with each media > session independently. This clearly will have some impact on the API. > > > Additional considerations: > > Shared SDES keys: B2 to B4 will result in that SDES keys from the > Offering party to be used towards all invited parties. This is security > risk as any of the invited parties can spoof the offering side towards > any of the other invited parties. This threat can be resolved by having > the inviter rekey immediately after having received an answer. > > Sharing ICE candidates: B3 and B4 and also B2 to some degree will share > the ICE candidates. That has certain implications. One is the positive > in that it minimizes the resource consumption as additional > PeerConnections come at very little extra cost, no need for additional > ICE gathering candidate phases, and also be very quick as no external > communication is required. The downside of this is that the end-points > candidates must always be kept alive as long as some PeerConnection > instance exist. Because the browser never knows when the application may > create an additional PC and expect them to have the same ICE candidates. > It should also be noted that the answering WebRTC end-point will need to > gather candidates for each offer. Otherwise it will become impossible to > create multiple PeerConnections between the same end-points if that is > desired by the application. > > > I know the above doesn't list all of the pro and cons of the different > alternatives. So please fill in additional arguments. And if I missed > some proposal please add that also if relevant > > As you may have noted I the two questions in the above have kind of > floated together. The reason for this is that I think the majority are > fine with having SIP support as long as it doesn't have to high cost or > complexity associated with it. Thus, the question how becomes very > intertwined with forking support yes or no. > > So please continue the discussion > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] State of the Forking discussion Randell Jesup
- [rtcweb] State of the Forking discussion Magnus Westerlund
- Re: [rtcweb] State of the Forking discussion Christer Holmberg
- Re: [rtcweb] State of the Forking discussion Ravindran Parthasarathi
- Re: [rtcweb] State of the Forking discussion Iñaki Baz Castillo
- Re: [rtcweb] State of the Forking discussion Hadriel Kaplan
- Re: [rtcweb] State of the Forking discussion Christer Holmberg
- Re: [rtcweb] State of the Forking discussion Cullen Jennings
- Re: [rtcweb] SRTP mandatory to implement versus m… Bernard Aboba
- Re: [rtcweb] State of the Forking discussion Christer Holmberg
- Re: [rtcweb] SRTP mandatory to implement versus m… Bernard Aboba
- Re: [rtcweb] State of the Forking discussion Cullen Jennings
- Re: [rtcweb] State of the Forking discussion Christer Holmberg
- Re: [rtcweb] SRTP mandatory to implement versus m… Magnus Westerlund