1. Using your pic, but UPDATE(6)/200OK(7) with no Offer/Answer:
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
| |
|<------------(6) UPDATE --------------------|
| |
|-------------(7) 200 OK ------------------->|
| |
|<---------------(8) 200 OK------------------|
| |
|------------------(9) ACK------------------>|
| |
Dialog state before Re-INVITE: dialog;
Re-INVITE(4) want to refresh to state: dialog';
UPDATE(6) is a newer refresh: dialog''
200OK(7) is the commitment of dialog''. And 200OK(8) is just using the committed state(dialog'') if UAS want to commit the session modification. And this is defined in RFC3311:
If a UA
uses an UPDATE request or response to modify the remote target while
an INVITE transaction is in progress, and it is a UAS for that INVITE
transaction, it MUST place the same value into the Contact header
field of the 2xx to the INVITE that it placed into the UPDATE request
or response.
2. I think the same is for session modification if UPDATE(6)/200OK(7) with Offer/Answer. That is, if the Offer/Answer in UPDATE(6)/200OK(7) is a new modification. Then the modification MUST be committed by 200OK(7). Then, it has nothing to do with (8).
Only with specific definition, the Offer/Answer in UPDATE(6)/200OK(7) can be treated as part of the modification triggered by Re-INVITE. Precondition is one case.
3. About racing condtion.
My proposal has no racing condition. And in later e-mail, I will explain it specificly.
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2009-03-03 21:32 |
|
Hi,
I have put together the following draft. It contains a proposal for the
rollback issue that has been discussed on the list:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
I have also written another short draft on an issue related to
preconditions that was also discussed on the list in one of the
rollback-related threads:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
Comments are welcome.
Cheers,
Gonzalo
_______________________________________________
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
-------------------------------------------------------- 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
