Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking

[Christer Holmberg <[e-mail]>]

Hi,

>>> My understanding is that the mismatch is that the JS APP isn't giving a consistent story to the browser on whether the answer was final or not.
>>> This sequence would work:
>>>
>>> BROWSER                         JS APP                                    REMOTE ENITTY
>>>
>>>      ------ create offer ----------
>>>                                               -------- SDP Offer 1----------------->
>>>                                              <------- SDP Answer 1 ----------------
>>>      ------ set remote pranswer(1) ---------
>>>                                              <------- SDP Offer 2 -------------------
>>>      ------ set remote answer(1) -----
>>>      ------ set remote offer(2) -----
>>>
>>> that is, when the JS app gets the information that there's a new offer incoming, it realizes that Answer 1 needs to be treated as a final answer, and finalizes it before passing in the new offer.
>> The problem with such approach is that it will terminate forking, i.e. it will not be possible to pass an SDP Answer from ANOTHER remote entity to the browser.
>
>
>>
>> BROWSER                         JS APP                                    REMOTE ENTITY A         REMOTE ENTITY B
>>
>>      ------ create offer ----------
>>                                               -------- SDP Offer 1----------------->
>>                                              ------- SDP Offer 1 ---------------------------------------------------->
>>                                              <------- SDP Answer 1 (A) -----------
>>      ------ set remote pranswer(1) ---------
>>                                              <------- SDP Offer 2 (A) --------------
>>      ------ set remote answer(1) -----
>>      ------ set remote offer(2) --------
>>                                              <------ SDP Answer 1 (B) ---------------------------------------------
>>      ------ ???? ----------------------------
>
> Right. I don't think that's avoidable; after a second offer/answer exchange, you can't go back and act as if you were still in the first offer/answer exchange.
>
> Is there a sequence of SIP operations described in a spec that would allow this to happen?

It's not that common for the offerer (the BROWSER in this case) to RECEIVE an offer in the backward direction before the call has been established, but I HAVE seen such flow(s) somewhere.

However, it is more common for the offerer to SEND a new offer (as I showed in Q_OA_3) before the call has been established. It's used e.g. for negotiation down codecs, changing the media direction attribute, changing pre-conditions status - and, for BUNDLE.

>I don't even think it's logically possible in all cases.
>
>For example, if Offer 1 (and answer 1a and 1b) have the form
>
>m=audio
>
>and offer 2 is
>
>m=audio
>m=video
>
>then it's not possible to handle Answer 1(b) without dropping the video m-line - and in SDP offer/answer, you aren't allowed to drop m-lines, ever. (Right?)

Please keep in mind that, in SIP terms, we are talking about two separate early SIP dialogs, and the SDP offer/answer state machines are independent from each other. So, it would be allowed.

PeerConnection cloning would introduce the same concept in browsers, as each clone could represent a separate SIP early dialog. 

Regards,

Christer