Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback

[Gonzalo Camarillo <[e-mail]>]

Hi,

the condition for resynching given in the draft is when the UA "receives
an error response to a re-INVITE that undoes already-executed changes
within the re-INVITE". The draft talks about several situation where UAs
can go out of synch.

In any case, as you suggest in your email, we are talking about corner
cases.

Cheers,

Gonzalo

On 14/10/2010 4:46 PM, Byron Campen wrote:
> 
> 	Perhaps I phrased my question poorly. My question wasn't so much about what a UA should do when it thinks the session is out of sync, but whether it thinks the session is out of sync in the specific case I posed. But, I suppose that any time we get a reINVITE that is rejected after an offer/answer exchange has been completed, whether or not there had been an UPDATE thrown into the mix, we should assume the worst and re-sync. This will lead to glare fairly often, but we are already in a relatively rare corner-case, so I can see this being acceptable.
> 
> Best regards,
> Byron Campen
> 
>> Hi Byron,
>>
>>> Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing?
>>
>> yes, that is what the re-INVITE draft says:
>>
>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4
>>
>> Figure 5 shows a message flow with a race condition similar to the ones
>> you are referring to:
>>
>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 11/10/2010 8:43 PM, Byron Campen wrote:
>>>
>>> 	Sending to the authors of the offeranswer and reinvite drafts, since I am not sure which bucket this would fall in:
>>>
>>> 	Consider the following. In all cases, this is within a reINVITE transaction, after an offer/answer exchange has completed using 100rel (which kind is not important), that is being rejected by the server side due to some unspecified error:
>>>
>>>                 A          B
>>>                 |<---------| INVITE/500
>>>                 |          |
>>>                 |          |
>>>  UPDATE (offer) |--------->|
>>>                 |          |
>>>                 |<---------| UPDATE/200 (answer)
>>>
>>>                 A          B
>>>  UPDATE (offer) |---\  /---| INVITE/500
>>>                 |    \/    |
>>>                 |    /\    |
>>>                 |<--/  \-->|
>>>                 |          |
>>>                 |<---------| UPDATE/200 (answer)
>>>
>>>                 A          B
>>>                 |        /-| INVITE/500
>>>                 |       /  |
>>>  UPDATE (offer) |------/-->|
>>>                 |     /    |
>>>                 |<---/-----| UPDATE/200 (answer)
>>>                 |   /      |
>>>                 |<-/       |
>>>
>>> 	All of these look identical to B; UPDATE offer/answer completes after the end of the INVITE transaction. However, A sees them very differently. B cannot know that something unusual has happened. Also consider the following cases:
>>>
>>>                 A          B
>>>  UPDATE (offer) |--------->|
>>>                 |          |
>>>                 |<---------| UPDATE/200 (answer)
>>>                 |          |
>>>                 |<---------| INVITE/500
>>>
>>>                 A          B
>>>  UPDATE (offer) |--------->|
>>>                 |          |
>>>                 |       /--| UPDATE/200 (answer)
>>>                 |      /   |
>>>                 |<----/----| INVITE/500
>>>                 |    /     |
>>>                 |<--/      |
>>>
>>> 	Again, these look the same to B, but different to A. What is the best approach to ensuring that session-state is consistent on both ends in all of these cases? It seems to me that one way would be to specify that rollback of a reINVITE does not invalidate session-state established with an UPDATE, regardless of whether that UPDATE transaction occurred (or appeared to have occurred) during the reINVITE transaction. If we insist that session-state established with an in-reINVITE UPDATE be rolled back (the current language says that both sides must roll back to the session-state in use prior to the reINVITE), then there is no way to ensure consistent rollback on both ends, even if everything has the same rollback logic, because what appears to be an in-reINVITE UPDATE on one end may appear to be after the reINVITE transaction on the other end. If any portion of the UPDATE transaction appeared to have happened within the reINVITE transaction, then the observing UA must send 
a 
>> subsequent UPDATE to re-sync (since there is no guarantee that the other end saw the UPDATE within the reINVITE transaction). This is likely to cause glare, unless we put asymmetric timers on the re-sync, and even then there will be a delay similar to that caused by glare.
>>>
>>> 	My gut says that it would be better to not rollback session-state established by an UPDATE, under any circumstances. But, there may be situations where the session-state established in an UPDATE is contingent on the reINVITE succeeding it. Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? Or is there something I am missing here?
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>
>>>
>>
>