Re: [rtcweb] State of the Forking discussion

[Christer Holmberg <[e-mail]>]

Hi, 

> <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. 

If you are not using PRACK, you will not be able to receive a "real" answer before 200 OK, at a point where forking will be no issue anymore :)

Regards,

Christer



> 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  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > 
> ----------------------------------------------------------------------
> > 
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>