Hi, >I also pay high attention to the topic of "rollback of re-Invite". >As lots of service is implemented on the network using SIP, and different ways >may be carried out by different corporations, it's necessary to define a complete >and clear method to solve the failure when the unsuccessful re-Invite happens. I agree, and we thought that having a generic rule, not related to specific use-cases, would be the most clear, clean and complete solution. >And the problems "Commit any session parameters that have been sucessfully changed" >metioned in "draft-gaoyang-sipping-session-state-analysis-01.txt" need further discuss, >I think. The draft does not define a generic rule. It more or less says that every time there is a new use-case, the offer/answer rollback aspects needs to be documented for that use-case. I think that is something we wanted to avoid. If I understand chapter 4.3.3 correct, it says that if you have a pending re-INVITE transaction, a NEW modification must be sent in a re-INVITE request. That way we would get rid of the race condition problem. That is an interesting point. I guess the question is whether it's too lake to make such a rule. Regards, Christer _______________________________________________ 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
