Re: [Bug 25579] New: State transitions are missing in RTCPeerConnections state transition diagram.

Paul,

With this it is clear that rollback scenario will never happen because of
PRACK.
But I have a question here, the text is saying termination of dialog, but
you are saying termination of session. This phrase is a bit confusing.

Also what do you suggest, is it good to consider a provisional answer to be
final answer ? and using the existing state transition
 or
 to add the new state transition from HAVE-REMOTE-PRANSWER to
 HAVE-LOCAL-OFFER?

I feel adding transition seems to be good to avoid any future worst case
experiences, what do you say?


On Wed, May 7, 2014 at 9:49 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 5/7/14 5:46 AM, Kiran Kumar Guduru wrote:
>
>> Hi,
>>
>
>  [KIRAN] In PRACK case, If the SIP user agent is not willing to accept an
>> offer, if it responds with an error response, than that terminates that
>> particular SIP Invite / Re-Invite transaction.
>>
>> In such case, it will roll-back to the state that is negotiated by
>> previous Invite- with final ANSWER.
>>
>> This case has been outlined (it has not explained in brief) in RFC 6337,
>> section 2.3 Table-2.
>>
>>      Offer                Rejection
>>       ------------------------------------------------------------------
>>       1. INVITE Req. (*)      488 INVITE Response
>>       2. 2xx INVITE Resp.     Answer in ACK Req. followed by new offer
>>                               OR termination of dialog
>>       3. INVITE Req.          488 INVITE Response (same as Pattern 1)
>>       4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
>>       5. PRACK Req. (**)      200 PRACK Resp. followed by new offer
>>                               OR termination of dialog
>>       6. UPDATE Req.          488 UPDATE Response
>>
>> [1] http://tools.ietf.org/html/rfc6337#page-5
>>
>
> Note that the OR in row 5 above was added because we felt we had do say
> something about that case in RFC 6337.
>
> RFC 3262 says:
>
>    If the PRACK does match an
>    unacknowledged reliable provisional response, it MUST be responded to
>    with a 2xx response.
>
> It is saying the PRACK *MUST* succeed. Unfortunately it ignored the
> reality that it might not be possible to accept the PRACK. (For instance,
> the message might not be well formed, or it may be that security
> credentials are incorrect, etc.)
>
> So in 6337 we acknowledged that it might be necessary to fail it, and then
> specified what should happen next to make the best of the bad situation.
> And the best here is to give up on the whole session. There aren't any
> rollback provisions in this case, and we didn't feel it was appropriate for
> 6337 to define any.
>
> The bottom line of this is that one should be very careful about putting
> offers in PRACKs. If you are doing so you had better limit yourself to
> offers that are virtually certain to be accepted by an entity that accepted
> the previous offer.
>
>         Thanks,
>         Paul
>
>