Hi, There are also "B2BUAs acting as proxies", that do not terminate the dialogs. There are even proxies which need to keep SDP state. Regards, Christer > -----Original Message----- > From: OKUMURA Shinji [mailto:shin@xxxxxxxxxxxxxxx] > Sent: 5. maaliskuuta 2009 15:32 > To: Christer Holmberg; sipping > Subject: RE: My proposal has no racing condition > > 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
