|
Hi,
>I MUST point out that: >Chapter 4.3.3 is not the solution in theory for race condition problem, it is just BCP level. >Chapter 4.3.2 is the solution in theory. Well, 4.3.3
still solves the problem :)
>And the racing condition problem described here is not same with the one in 6.2 of "draft-ietf-sipping-sip-offeranswer". >The one in 6.2 of "draft-ietf-sipping-sip-offeranswer" does not exist here. I know. The
race condition in the offeranswer draft is about when both endpoints send a new
offer at the same time, which is a completely separate
issue.
Regards,
Christer
> Date: Mon, 16 Feb 2009 14:41:59 +0100 > From: christer.holmberg@xxxxxxxxxxxx > To: gao.yang2@xxxxxxxxxx > CC: wang.libo@xxxxxxxxxx; sipping@xxxxxxxx > Subject: Re: [Sipping] About "rollback of re-Invite" > > > 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 > nest ed 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 defini tion 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 devel opment of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP 使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！
|
_______________________________________________ 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
