Hi, >In my opinion,the re-INVITE should fallback to the state before the re-INVITE. >And it doesn't matter what the precodition state is. Because the re-INVITE is >rejected,the state of its precondition state seems useless. > >By limiting UDPATEs for new modification outside re-INVITE,we can find the >right state to fallback. This issue does only talk about UPDATEs "inside" the re-INVITE. Regards, Christer "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> 写于 2009-02-19 03:24:04: > 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 > -------------------------------------------------------- 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
