Re: [rtcweb] State of the Forking discussion

[Cullen Jennings <[e-mail]>]

On Nov 9, 2011, at 2:20 AM, Christer Holmberg wrote:

> 
> 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 :)
> 

I think it is a little more subtle than this. The UAC are not guarantee delivery of the 180s without prack but the UAC typically gets them anyways. Note I am fine with things that do support PRACK, I  just don't want  to require it. I also have had good luck with the systems that send the 180 more than once. 


> 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