Re: [rtcweb] State of the Forking discussion

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 03 November 2011 11:53 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 9CE9C11E80E8 for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 04:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.987
X-Spam-Level:
X-Spam-Status: No, score=-6.987 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, 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 5kvdNEJPiKc0 for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 04:53:42 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 342E211E8088 for <rtcweb@ietf.org>; Thu, 3 Nov 2011 04:53:42 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-91-4eb280c5decf
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 49.ED.13753.5C082BE4; Thu, 3 Nov 2011 12:53:41 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 3 Nov 2011 12:53:40 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 03 Nov 2011 12:53:39 +0100
Thread-Topic: [rtcweb] State of the Forking discussion
Thread-Index: AcyaET/UQS0OLGexRSeTGvjWAriroQADHEGA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se>
References: <4EB26945.40607@ericsson.com>
In-Reply-To: <4EB26945.40607@ericsson.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] 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: Thu, 03 Nov 2011 11:53:43 -0000

Hi Magnus,



Question #1: Is forking needed to be supported at all?

Answer: 	Yes


Question #2: If it is supported in which form would it supported in?

Answer: 	Serial (ie one "active" media session at any given time) forking is enough.

		Solution B2, B3 or B4 - whatever is possible and least complex from a PeerConnection perspective :)


Regards,

Christer
		



> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: 3. marraskuuta 2011 12:13
> To: rtcweb@ietf.org
> Subject: [rtcweb] State of the Forking discussion
> 
> 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
>