Hi, Please be aware that there may also be offer/answer state aware intermediates, of which some may have received the 4xx (F6) BEFORE they received the UPDATE (F5), and they must all end up having the same SDP state. Otherwise you have a mess. Regards, Christer > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji > Sent: 5. maaliskuuta 2009 13:02 > To: Ian Elz; sipping > Subject: Re: My proposal has no racing condition > > Hi, > > New rule. > > UAC Behavior > After receiving 4xx, if UAC receive 200 response with answer > to UPDATE that sent before receiving 4xx, UAC MUST > treat it as if > UAC sent the UPDATE after sending ACK. > > UAC P1 UAS > | session established | > |<====================|====================>| > | | | > | F1 re-INVITE (SDP) | > |-------------------->|-------------------->| > | F2 1xx-rel (SDP) | > |<--------------------|<--------------------| > | F3 PRACK | > |-------------------->|-------------------->| > | F4 2xx PRA | > |<--------------------|<--------------------| > | | | > |F5 UPDATE(offer) F6 4xx INV | > |---------\ /--------|<--------------------| > | \/ | F7 ACK | > | /\ |-------------------->| > |<--------/ \ | F5 UPDATE | > | \------>|-------------------->| > | | | > | F8 2xx UPDATE(answer) | > |<--------------------|<--------------------| > | ACK | | > |-------------------->| | > > What do you think of this idea ? > > 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 > _______________________________________________ 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
