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

[Byron Campen <[e-mail]>]

	Any non-dialog-killing failure response will do here. My suspicion is that a 500 will be the most commonly seen such response in the wild, but I could be mistaken.

Best regards,
Byron Campen

> 
> Hi Byron Campen, 
> 
> Before getting into the details, I'd like to check does the "INVITE/500" just means the 5xx of INVITE? 
> 
> Thanks, 
> 
> Gao 
> 
> >    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 sub
> >  sequent 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
> > 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore