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

[Harald Alvestrand <[e-mail]>]

On 02/28/2013 11:37 PM, Justin Uberti wrote:
>
>
>
> On Wed, Feb 27, 2013 at 10:57 PM, Christer Holmberg 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     Hi Justin,
>
>     Thanks for your response!
>
>     Comments inline, with an additional state machine question (Q_OA_3).
>
>
>     ------------------
>
>
>     >> Q_OA_1: As I have commented earlier, the state machine does not
>     support setting of remote offer when a
>     >> remote pranswer has been set. A JS SIP app may e.g. receive an
>     SDP answer in a reliable 18x response,
>     >> call setPranswer, and then receive an UPDATE on the same leg
>     with a new offer.
>     >
>     > Section 3.5.2, paragraph 2, attempts to provide a workaround for
>     this issue.
>
>     Section 3.5.2 talks about parallel forking, and how it can be
>     solved by creating a new PC, and then send an UPDATE to provide
>     the new PC information to the remote entity.
>
>     But, my issues is when the remote entity sends an UPDATE, with a
>     new offer. It's not even related to forking. See my example below:
>
>
>     BROWSER                         JS APP                REMOTE ENITTY
>
>         ------ create offer ----------
>                                                  -------- SDP Offer
>     1----------------->
>                                                 <------- SDP Answer 1
>     ----------------
>         ------ set pranswer ---------
>                                                 <------- SDP Offer 2
>     -------------------
>         ------ ??? ----------------------
>
>
>     ------------------
>
>
> Right. This is clearly a problem, but the reason it is a problem is 
> because the two sides don't agree on the state of the negotiation. In 
> a forking case, it would be handled via the mechanism I mentioned 
> above. In a non-forking case, this is not solvable even with cloning, 
> because the two sides are out of sync. The browser has to handle this 
> case by rejecting SDP Offer 2.
>

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.

(I'll leave it to others to argue about whether or not there needs to be 
a stable state between the set remote answer(1) and set remote offer(2))