Ian, yes, you are right. ACK is sent hop-by-hop. This is the problem associated with full-rollback. Do you have an idea to solve it ? Regards, Shinji "Ian Elz" <ian.elz@xxxxxxxxxxxx> >Shinji, > >I don't believe that your proposal to reject all UPDATEs received >between the 4xx and the ACK will solve the problem. It won't harm but >there are situations where the UPDATE may arrive after the ACK has been >received by the UAS. > >This may occur when another node exists between the UAC and the UAS. >RFC3261 requires that the ACK for a non-2xx response be sent by the >transaction and hence the ACK in this case is hop-by-hop. Only an ACK to >a 2xx response is end-to-end. > >This may lead to the following scenario: > >1 UPDATE and 4xx/5xx/6xx of Re-INVITE > > UAC P1 UAS > | session established | > |<====================|====================>| > | | | > | F1 re-INVITE (SDP) | > |-------------------->|-------------------->| > | F2 1xx-rel (SDP) | > |<--------------------|<--------------------| > | F3 PRACK | > |-------------------->|-------------------->| > | F4 2xx PRA | > |<--------------------|<--------------------| > | | | > |F5 UPDATE F6 4xx INV | > |---------\ /--------|<--------------------| > | \/ | ACK | > | /\ |-------------------->| > |<--------/ \ | UPDATE F6 | > | \------>|-------------------->| > | | | > | ACK | | > |-------------------->| | > >The more intervening nodes the greater the probability that this >situation will occur. > >Ian Elz > >-----Original Message----- >From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On >Behalf Of OKUMURA Shinji >Sent: 05 March 2009 02:48 >To: sipping >Cc: Gonzalo Camarillo >Subject: Re: My proposal has no racing condition > >Gao, > >I feel your proposal is no bad for a summary. > >BUT, The biggest drawback is which UPDATE is "part of the original >modification" or "new modification". it is very very ambiguous. > >the distinction seems to impossible. > >It is no doubt that an UPDATE without SDP is "new modification". >UPDATE after ACk is "new modification" too. >but it has a racing condition. > >new UAS behavior > reject all UPDATEs received between 4xx and ACK > >can the above rule solve the problem ? > >Regards, >Shinji > >gao.yang2@xxxxxxxxxx >>My proposal has no racing condition >> >>1 UPDATE and 4xx/5xx/6xx of Re-INVITE >> >> UAC UAS >> | session established | >> |<===================>| >> | | >> | F1 re-INVITE (SDP) | >> |-------------------->| >> | F2 1xx-rel (SDP) | >> |<--------------------| >> | F3 PRACK | >> |-------------------->| >> | F4 2xx PRA | >> |<--------------------| >> | | >> |F5 UPDATE F6 4xx INV | >> |---------\ /--------| >> | \/ | >> | /\ | >> |<--------/ \------->| >> | | >> >>Currently, there are only two cases for the Offer in UPDATE: >> >> o part of the original modification; >> >> o a new modification request. >> >>If it is part of the original modification, the session state is clear. > >>That >>is the state before F1. >> >>If it is a new modification request, there are only two cases for the >> UPDATE: >> >> o accepted by 200OK; >> >> o rejected by 4xx/5xx/6xx, such as 504. >> >> If it is accepted by 200OK, the new modification is committed. And >> the session state is committed state of the modification triggered by >> F5. >> >> If it is rejected, and the original modification failed, the session > >>state is one before F1. _______________________________________________ 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
