Dear Christer Holmberg
It is really a good question. And I'd like to extend this question.
F3/F4 is the precondition notification(there can be other precondition notification between F2 and F3).
After F4, the precondition is OK and session modification is resumed. And at that time, the UA can show the session modification windows to the user. Or just commit the modification with 200OK of Re-INVITE(such as RFC5027(Security Preconditions) without user permition).
But if one UA send another UPDATE(F6) with the SDP just same as the precondition notification(version num +1), what will happen?
It is really legitimate message here, though we can hardly say what the UA send it for. And in theory, we need to show the session state.
In semantics of suspending/resuming of session modification, the session state after F5 is the same as the one after F2 without precondition. And what will happen if one side send F3.
Under my understanding, I think this behavior can be explained as the UA want to use the SDP immediately(and before F1, he did not have such imminency. Beacuse he can replace F1 with UPDATE if he have such imminency.)
The other side can reject it with 504 for example, can not accept it without the user's permition. But if it accept it, it just means commitment(this if obey the sender's imminency).
So, I think F6(Figure 1) and F3(Figure 2) are new modification, even though the SDPs are the same as the previous one.
And it obeys the original explanation: the precondition notification in suspending state is part of the orignal modification.
What mentioned above is just by definition in RFC3312.
And there is a more situation: if the precondition notification with the orignal precondition OK and add another new precondition(it is legitimate, but unordinary). As the precondition of the session is still exist, the session is still in suspending state. And the one is precondition notification.
Waiting for your comments.
Gaoyang
Addenda:
Precondition(Figure 1)
UAC UAS
| session established |
|<===================>|
| |
| F1 re-INVITE (SDP) |
|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|
| F3 UPDATE | <- UPDATE request include state
|-------------------->| notification
| F4 2xx UPT |
|<--------------------|
| |
| F5 180 ringing |
|<--------------------|
| F6 UPDATE | <- UPDATE request same as state
|-------------------->| notification
| F7 2xx UPT |
|<--------------------|
| |
Without Precondition(Figure 2)
UAC UAS
| session established |
|<===================>|
| |
| F1 re-INVITE (SDP) |
|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|
| F3 UPDATE | <- UPDATE request with same SDP as F1
|-------------------->|
| F4 2xx UPT/504 |
|<--------------------|
| |
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-02-19 03:24 |
|
Hi,
Let's look into this precondition proposal.
There are some issues that needs to be taken into consideration.
Issue 2:
-----------
Assume I send a re-INVITE, and I use precondition. I modify the SDP, and indicate that preconditions are not met.
Then I receive a relaible 18x, and the first offer/answer transaction has succeeded.
Later I send an UPDATE request, where I indicate that preconditions are met.
Then I receive a 200 for the UPDATE, indicating that preconditions are met also at the other end.
Then the re-INVITE fails. Now, according to the ZTE proposal, is there a full fallback? The UPDATE was sent as part of the nested precondition procedure, but the preconditions were fullfilled before the re-INVITE failed?
Does it matter what the precondition state is when the re-INVITE fails, or is there always a full fallback?
Regards,
Christer
?br>
-------------------------------------------------------- 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
