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. > >[gaoyang] It is simple and clear. But it disregard nature property of nested transaction. I concluded incorrectness and drawback of such way. More details in http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state- analysis-01.txt. I agree it's not the most "beautiful" solution - that's why we spent a long time discussing it. >>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. > >[gaoyang] It is not use-case oriented, but rules/definition oriented. >And the definition of how o/a pairs form nested transaction should be open for future. >Such as "a=chain" and so on extension can form more o/a pairs as nested transaction. It is not use-case. >We can have a further talk. > >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. > >[gaoyang] Is the "lake" late? I think it can be BCP, not rules :). Perhaps, yes. 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
