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

[Harald Alvestrand <[e-mail]>]

On 03/01/2013 12:24 PM, Christer Holmberg wrote:
> Hi Harald,
>
>> 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?

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