Re: [rtcweb] PRANSWER is unusable for serial forking

[Christer Holmberg <[e-mail]>]

Hi Cullen,

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

I agree. I appologize for making too many assumptions. The 180 IS sent reliably, there IS a PRACK, and there IS a response to the UPDATE.

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

We could even make it more simply by removing the forking part, ie there is a reliable 180, follwed by an UPDATE. But, for now, let's continue with the flow above...

(I have added some numbering to your text below)

>1. One fork to UA1, and one to UA2.

Yes.

>2. The JS App needs to pick which one it is going to choose to have a media session with.

Yes.

>3. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer.

Here comes the issue:

According to jsep-02, when Offer2 comes the JSEP O/A state machine is in the "pranswer" state, where a new offer is not accepted.

And, yes, we could fix that by accepting a new offer at that point. But, to which state would be then go?

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

Sure.

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

I am assuming serial forking. Once the answer from UA2 has been provided to the browser, I don't care if the media session with UA1 goes away.

But, again, my main issue at this point is not about media - it's about how the offers and answers between the JS app and the UAs are mapped to JSEP offer/pranswer/answer.

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

No disagreement from my side there :) 

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

At the moment, JSEP-02 does talk about cloning. I don't know whether you suggest that to be removed, but if it stays it would work also for serial forking.

Regards,

Christer