Hi,
I also consider UPDATE/200OK as atomic transaction. And I think UPDATE's atomicity has no conflict with Re-INVITE's atomicity in current RFCs.
As we know, atomicity's semantics is "all or nothing". And if new modification is acceptted, the older pending one would be discarded(that is the semantics of "nothing"). Then, UPDATE's atomicity has no conflict with Re-INVITE's atomicity.
One special thing is precondition:
First, we should make sure the effect of the later Offer/Answer pairs
which are used as "refreshing the precondtion state table" during
suspending state of session. By RFC3312, these Offer/Answer pairs
just refresh the precondtion state table, but it has no impact on the
commitment of the modification.
Then, as the UAs has adjusted the session parameters(refresh the
precondtion state table) accordingly, it obeys RFC3311.
And as current pending session modification is still the one
triggered by Re-INVITE, and it is only discarded for the failure of Re-
INVITE, not by "refreshing the precondtion state table". This obeys RFC3261.
Gao
| Brett Tate <brett@xxxxxxxxxxxxx>
发件人: sip-bounces@xxxxxxxx 2009-03-11 02:08 |
|
>>> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sipping@xxxxxxxx for new developments on the application of sip
-------------------------------------------------------- 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.
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
