Re: "UPDATE during Re-INVITE" discussion

Brett Tate <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.sipping
Message-ID <9B2A061A1137254BBE4F4B2CD843646A10B4A04FBD@mbx02.citservers.local>
>>> Regarding your second bullet, I don't even think that one 
>>> should send "nested" UPDATEs, if they don't have anything 
>>> to do with the re-INVITE. I think that is bad application 
>>> design.  Non-related changes should be done outside the 
>>> re-INVITE transaction.
>>
>> Sending UPDATE per RFC 4028 to refresh or audit the dialog
>> is one of the times UPDATE may be tried while a re-INVITE is
>> occurring.
> 
> True, but normally those UPDATEs are not going to modify session
> parameters.
>
> So, yes, it may happen, but I think we should recommend 
> against doing so.

There are two key phrases within rfc3261 which might be adding to the confusion: "session parameters" and "state changes".  RFC 3261 section 12.2.2 and 14.1 basically indicate to rollback as though the re-INVITE was not sent.  There have been numerous proposal concerning what should and shouldn't rollback; it is occasional hard to distinguish if people mean 1) SDP 2) non SDP state data (like Contact, Session-Expires, ...), or 3) both.  

I agree that UPDATE likely wouldn't include SDP when only attempting to refresh or audit the session; however it can.

I think 12.2.2 is sufficiently clear concerning what should occur upon re-INVITE failure; however I think it was unfortunate that section 14.1 indicated "session parameters" instead of "state changes".

RFC 3261 section 12.2.2: "Requests sent within a dialog, as any other requests, are atomic.  If a particular request is accepted by the UAS, all the state changes associated with it are performed.  If the request is rejected, none of the state changes are performed."

Concerning UPDATE in relation to section 12.2.2, I consider it an atomic transaction.  And for it is worth, I consider PRACK to not be an atomic transaction.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.