Hi, >>>"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. > >Where is the behavior of "useful entities" defined ? draft-real-world and draft-customer-requirements At the end of the day, those drafts are what really matters to many people :) I'll look at the rest later. Regards, Christer > >>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. > > 1.IT receive 4xx from UAS > 2.IT send ACK to UAS > 3.IT send 4xx to UAC > 4.IT receive UPDATE from UAC > 5.IT send UPDATE to UAS > 6.IT receive 2xx to UPDATE from UAS > 7.IT send 2xx to UPDATE to UAC > > UAC IT UAS > | session established | > |<====================|====================>| > state1| state1 | state1 | state1 > | | | > | F1 re-INVITE (SDP) | > |-------------------->|-------------------->| > | F2 1xx-rel (SDP) | > |<--------------------|<--------------------| > state2| state2 | state2 | state2 > | | | > | F3 PRACK | > |-------------------->|-------------------->| > | F4 2xx PRA | > |<--------------------|<--------------------| > | | | > |F5 UPDATE(offer) F6 4xx INV | > offer3|---------\ /--------|<--------------------| rollback state1 > | state1 | state1 | > | | | > | | | > | \/ | F7 ACK | > | /\ |-------------------->| > state1|<--------/ \ | F5 UPDATE | > | \------>|-------------------->| offer3 > | offer3 | offer3 | > | | | > | F8 2xx UPDATE(answer) | > |<--------------------|<--------------------| answer3 = state3 > state3| state3 | state3 | > | ACK | | > |-------------------->| | > > It is no problem, isn't it? > > Regards, > > Shinji > > >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 > > > >--------------------------"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
