Re: [rtcweb] PRANSWER is unusable for serial forking

[Christer Holmberg <[e-mail]>]

Hi Cullen,

I'll read your reply more in detail later, but please note that I assume that the 180 is sent *reliably* (I left the PRACK out).

Regards,

Christer

________________________________________
From: Cullen Jennings (fluffy) [[e-mail]]
Sent: Saturday, October 13, 2012 5:24 AM
To: Christer Holmberg
Cc: Roman Shpount; Cullen Jennings; [e-mail]
Subject: Re: [rtcweb] PRANSWER is unusable for serial forking

On Oct 9, 2012, at 12:40 AM, Christer Holmberg <[e-mail]> wrote:

> Hi,
>
> I THINK Roman is talking about the following flow:
>
>
> BROWSER               JS APP                  FORKING PROXY                   SIP UA 1                        SIP UA 2
>
> ------- OFFER --------------->
>                                                  ----- INVITE (OFFER 1) --------->
>                                                       ----- INVITE (OFFER 1) --------->
>                                                       ----- INVITE (OFFER 1) ---------------------------------------------------->
>                                                       <----180 (ANSWER 1a) ----------
>                       <----180 (ANSWER 1a) ----------
> <----PRANSWER -----------
>                                                       <----UPDATE (OFFER 2) --------
>                       <----UPDATE (OFFER 2) ---------
> <----???? --------------------
>                                                       <----200 (ANSWER 1b) ------------------------------------------------------
>                       <----200 (ANSWER 1b) ----------
> <----ANSWER ---------------
>
>

That's not a call flow that is legal for use of update. From section 5.1 of of RFC 3311 has

     o  If the UPDATE is being sent before completion of the initial
         INVITE transaction, and the initial INVITE contained an offer,
         the UPDATE can contain an offer if the callee generated an
         answer in a reliable provisional response, and the caller has
         received answers to any other offers it sent in either PRACK or
         UPDATE, and has generated answers for any offers it received in
         an UPDATE from the callee.

If the answer from UA1 is going to do updates before the invite transaction complete, it needs to do that with 100rel / PRACK. Note the diagram should also show an the 200 response to the update is going to cary an answer.

So if you made all these changes, lets talk about how you would solve this problem in the JS App.

Fundamentally what is happening here is the call signaling is setting up two session - this is parallel media forking and parallel signaling forking. One fork to UA1, and one to UA2. The JS App needs to pick which one it is going to choose to have a media session with. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer. If it was going to choose UA2, it would not pass the answer down to the browser at all and would instead wait till it Answer 1b and pass that down. If you think it should simultaneously have a media session with both UA1 and UA2, then things are more complicated. I realize that at the time it gets ANSWER 1a, it does not know it will later get ANSWR 1b so that make it hard to choose UA2.

Parallel forking with early media and secure media is a hard problem in SIP as we know from the HERFP discussion. I'm unaware of real world problem that are solved well with SIP and require parallel forking and thus my focus has been on making sure we solve serial forking. I'm perfectly happy if we *also* solve parallel forking but I don't care too much as long a early media serial forking scenarios work because theses do happen all the time. I'm pretty skeptical that are a lot of existing SIP phones that deal well with simultaneously receiving and sending media to two other UAs in a scenario like this (I'm trying to separate this from conferencing - I know lots of SIP UA do 3 way calling and conferencing just fine).

If you want to do both, one way might be to create a new peer connection for the 2nd call, and map it to and IVNTE with replaces, or send a SIP refer to get the second session mapped to the new PeerConnection object. One could also try and work on some thing that allows one PeerConenction to clone to two places but that's going to be a bunch of work to figure out - and again, perfectly happy if someone goes and does that but it's a hard problem when you have resource allocations.