Re: [rtcweb] State of the Forking discussion

[Ravindran Parthasarathi <[e-mail]>]

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?
             I support for B3 or B4 as it covers both serial & parallel forking.  I'm interested in parallel forking because serial forking support is partial support of forking in terms of SIP (RFC 3261) which may leads to interop issue and also, it is always possible to get 2 18x response with different to-tag and different SDP answers while interworking with SIP (2 dialogs with 2 different offer/answer pair at this stage) and 200 may came any one of the remote (first or second). Also, WebRTC forking infrastructure shall be used for other services as mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02516.html. 
       
Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Christer Holmberg
>Sent: Thursday, November 03, 2011 5:24 PM
>To: Magnus Westerlund; [e-mail]
>Subject: Re: [rtcweb] State of the Forking discussion
>
>
>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: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Magnus Westerlund
>> Sent: 3. marraskuuta 2011 12:13
>> To: [e-mail]
>> 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  [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