Christer, Are you talking about B2BUA ? It will go without saying B2BUA is an endpoint, terminate both dialog. It should handle both O/A state adequately. If you know a concrete problem, pl show me it's sequence flow. Regards, Shinji >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
