Hi, >>There are also "B2BUAs acting as proxies", that do not terminate the >>dialogs. > >"B2BUAs acting as proxies" is a terrible entities ! I would call them useful entities, but that's just me... I would also say that many (most?) of the B2BUAs out there probably act that way, but I am sure there are people who has better information on that. >It should behave as B2BUA. Well, it doesn't :) Anyway, even if they do I don't think it would solve the issue. The point is that some entities may bet the 4xx from the UAS before they get the UPDATE from the UAC, while other entities get the UPDATE from the UAC before they get the 4xx from the UAS. But, as indicated in Gonzalo's draft, that can be avoided by the UAS sending an UPDATE instead of 4xx. Regards. Christer > >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. > >> > > > >--------------------------"AVG > certification"-------------------------- > > > >No virus found in this incoming message. > >Checked by AVG - www.grisoft.jp > >Version: 8.0.237 / Virus Database: 270.11.7/1983 - Release Date: > >03/04/09 07:41:00 > _______________________________________________ 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
