Modification with mandatory precondition can not prompt the user and be committed at once ---RFC3312.
If the session description has changed, the UAS MUST
adjust the session parameters accordingly and generate an answer in
the 2xx response.
If the UAS cannot change
the session parameters without prompting the user, it SHOULD reject
the request with a 504 response. ---RFC3311
Then, that's why the UAC can not accept the UPDATE.
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-06 14:08 |
|
Hi,
>So, if the UAS sends a "rollback UPDATE", and offers m1 and m2 to be
put
>back, and the UAC cannot accept it, the UAC should of course reject the
>UPDATE. What happens after that is an implementation issue, I think.
>
>[Gao] But Gonzalo's draft using "should not", but this is a case
"MUST".
I don't know what text you are referring to, but there is always a risk
that the UPDATE will be rejected. We can't assume, it won't.
>You could end up in the same situations even without preconditions
>intermediate UPDATEs. For example:
>
>- Session before re-INVITE = m1 and m2
>- Re-INVITE adds m3 and removes m1 and m2
>- UAS rejects the re-INVITE
>
>Now, m1 and m2 has been removed, and no matter if the UAS sends 4xx, or
>a rollback UPDATE, the UAC may not be able to put m1 and m2 back.
>
>[Gao] Without precondition, there is no such problem at all.
>UAS can reject the Offer, without giving answer, such as 488.
Yes, but in my example there was already an answer in 18x.
>The only way to solve this would be to say that any committed change
(no
>matter whether the change has been done using reINV/18x or UPD/200) is
>never rolled back - which is the current solution.
>
>[Gao] We are talking session state in theory level. And
>I think I have show in my draft that we have definitive session state
obeying current RFCs.
And I think Gonzalo's draft says the same thing.
>How to get to the session state, is practical level thing.
>If you are interested in it. You can make a new thread, and I will
share my ways(I think we have many ways to do so).
I don't want a new thread - I want a solution.
Regards,
Christer
-------------------------------------------------------- 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
