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

[Gonzalo Camarillo <[e-mail]>]

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