Christer, >Hi, > >There are also "B2BUAs acting as proxies", that do not terminate the >dialogs. "B2BUAs acting as proxies" is a terrible entities ! It should behave as B2BUA. Regards, Shinji >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
