Hi Ivar, Re-invites do not change dialog state. It remains in confirmed state while/after processing re-INVITEs. It can only change to terminating/terminated state from confirmed state
Though for B2BUA one can define sub-states like holding or active to figure out if a re-invite has been received pending 2xx response etc ( This is not really specified in RFC-3261 ) Re-INVITEs or 200 OK for re-INVITEs can be used to refresh remote-target-URIs. Dialog mode does make sense as on one side we need to run two timers ( retransmission timer and timeout timer on UAS side ) and on other side/ UAC side we need to run only one timer ( to handle duplicate 2xx responses for 64 * t1 secs ) Hopefully this is what your query was. Regards, Indresh K Singh ------------------------------------------------------------- Sr. Software Engineer SIP Media Control and Signaling Nokia Siemens Networks Boca Raton, FL-33487 Ph: 561-923-5085 (o), 561-923-2048 (o) ------------------------------------------------------------- >>-----Original Message----- >>From: ext Ivar [mailto:[EMAIL PROTECTED] >>Sent: Thursday, May 17, 2007 6:01 AM >>To: Singh, Indresh (SNL US) >>Cc: [email protected] >>Subject: Re: [Sip-implementors] ACK and UAS dialog >> >> >>I got probably all working. >> >>I integrated ACK retransmission to dialog(if UAC) and also >>ACK confirm >>(if UAS). >> >>But now, if re-INVITE, ... For example must UAS dialog switch >>UAC dialog ? >>(and after 2xx, does target refresh) >>Hmm, but re-invite changes dialog state too or always >>confirmed and only >>does target refresh on 2xx. >> >>Probably dialog mode(UAC or UAS) makes sense at this time >>when it's not >>confirmed. >> >>Thanks, >> >> >> >>Singh, Indresh (SNL US) wrote: >>> You are correct. >>> >>> Pending a receiving of an ACK it is possilble that UAS may have >>> retransmitted the 2xx responses few times. In that case the UAC will >>> first process the first 2xx response, send an ACK and destroy the >>> transaction. Now at this point of time there is no >>transaction per say. >>> So in this case the network message handler will try to >>find a matching >>> transaction and will not find it, next it should find a >>matching dialog >>> which it would find and then in the matched dialog it >>should check to >>> see if an ACK has already been sent for original 2xx, if so then it >>> should simply retransmit the ACK for original 2XX. That would be one >>> approach to handle duplicate 2xx. >>> >>> Regards, >>> >>> Indresh K Singh >>> ------------------------------------------------------------- >>> Sr. Software Engineer >>> SIP Media Control and Signaling >>> Nokia Siemens Networks >>> Boca Raton, FL-33487 >>> Ph: 561-923-5085 (o), 561-923-2048 (o) >>> ------------------------------------------------------------- >>> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: ext Ivar [mailto:[EMAIL PROTECTED] >>>>> Sent: Wednesday, May 16, 2007 5:21 AM >>>>> To: Singh, Indresh (SNL US) >>>>> Cc: [email protected] >>>>> Subject: Re: [Sip-implementors] ACK and UAS dialog >>>>> >>>>> >>>>> Hmm , seems i miss yet something. >>>>> >>>>> 13.3.1.4 Note, however, that the INVITE server >>>>> transaction will be destroyed as soon as it receives this final >>>>> response and passes it to the transport. Therefore, it >>is necessary >>>>> to periodically pass the response directly to the >>transport until the >>>>> ACK arrives. The 2xx response is passed to the transport with an >>>>> interval that starts at T1 seconds and doubles for each >>>>> retransmission until it reaches T2 seconds (T1 and T2 are >>defined in >>>>> Section 17). Response retransmissions cease when an ACK >>request for >>>>> the response is received. This is independent of >>whatever transport >>>>> protocols are used to send the response. >>>>> >>>>> Ok 2xx retransmitted, but corresponding UAC client transaction is >>>>> terminated, so it's like stray response when reaches to UAC. >>>>> >>>>> and >>>>> >>>>> 13.2.2.4 >>>>> The UAC core MUST generate an ACK request for each 2xx >>received from >>>>> the transaction layer. >>>>> >>>>> How UAC core can get multiple 2xx from transaction layer >>if client >>>>> transaction is terminated ? >>>>> >>>>> Definitely this part is messy in rfc. >>>>> >>>>> What i get is that UAC must try to match response to transaction >>>>> (transaction also passes response to related dialog),then >>to dialog, >>>>> then dialog genrates ACK for each 2xx response. >>>>> >>>>> Any commnets are welcome, >>>>> >>>>> Thanks >>>>> >>>>> >>>>> Singh, Indresh (SNL US) wrote: >>>>> >>>>>> Dear Ivar, >>>>>> >>>>>> Transaction User for B2BUA or UAS/UAC separately, could be >>>>>> >>>>> defined as >>>>> >>>>>> Dialog and above it can be application Layers. >>>>>> >>>>>> RFC does not clearly define this ( as for stateless proxy >>>>>> >>>>> case there is >>>>> >>>>>> no dialog/session kind of thing, so RFC keeps TU detail a >>>>>> >>>>> bit generic by >>>>> >>>>>> refer it as UAC/UAS core ). >>>>>> >>>>>> RFC-3261 just splits the layer into UAC core/UAS core >>>>>> >>>>> running ontop of >>>>> >>>>>> transaction layer. Now UAC core/UAS core could contains dialog >>>>>> functionality and thus can provide the 200 OK >>retransmission/timeout >>>>>> handling on the UAS side and ACK for duplicate 2XX on >>the UAC side >>>>>> based on t1 and t2 timer value ( section 13.2.2.4, page 82, >>>>>> >>>>> 83, section >>>>> >>>>>> 17 page 122, 123, 124 third para ) >>>>>> >>>>>> Regards, >>>>>> >>>>>> Indresh K Singh >>>>>> ------------------------------------------------------------- >>>>>> Sr. Software Engineer >>>>>> SIP Media Control and Signaling >>>>>> Nokia Siemens Networks >>>>>> Boca Raton, FL-33487 >>>>>> Ph: 561-923-5085 (o), 561-923-2048 (o) >>>>>> ------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ext Ivar [mailto:[EMAIL PROTECTED] >>>>>>>> Sent: Tuesday, May 15, 2007 4:25 PM >>>>>>>> To: Singh, Indresh (SNL US); [email protected] >>>>>>>> Subject: RE: [Sip-implementors] ACK and UAS dialog >>>>>>>> >>>>>>>> I have read 12-19, >>>>>>>> >>>>>>>> >>>>>>>> I know that positive response ends transaction. >>>>>>>> Ok what is transaction user for b2bua ? >>>>>>>> >>>>>>>> I'm trying to figgure out if its possible and wise to handle >>>>>>>> ack in dialog. Like uac dialog sends ack and uas dialog does >>>>>>>> retransmission of positive response while gets ack or 64x >>>>>>>> >>>>> t2 reached. >>>>> >>>>>>>> If that's not allowed or wise, there may n calls at same >>>>>>>> time, what normal way to map timer to dialog. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: "Singh, Indresh (SNL US)" <[EMAIL PROTECTED]> >>>>>>>> To: "ext Ivar" <[EMAIL PROTECTED]>; >>>>>>>> >>>>> [email protected] >>>>> >>>>>>>> Sent: 05/15/2007 23:17 >>>>>>>> Subject: RE: [Sip-implementors] ACK and UAS dialog >>>>>>>> >>>>>>>> Hi Ivar, >>>>>>>> Hi Ivar, >>>>>>>> >>>>>>>> I would recommend referring to section-12 ( dialog ) section >>>>>>>> 13 (session >>>>>>>> ) and section 17 ( transaction ) collectively of >>RFC-3261 for case >>>>>>>> described below. >>>>>>>> >>>>>>>> Yes the UAS created dialog should wait for the ACK, >>otherwise TU ( >>>>>>>> Transaction User ) running a 2xx timer waiting for ACK >>>>>>>> >>>>> should timeout >>>>> >>>>>>>> and release the call by sending a BYE or fall-back to previous >>>>>>>> successfully negotiated media ( if it was for >>re-INVITE-200OK ). >>>>>>>> >>>>>>>> For 2XX case please note that the transaction becomes free, >>>>>>>> so it is the >>>>>>>> TU which is running the retransmission and timeout timers. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Indresh K Singh >>>>>>>> ------------------------------------------------------------- >>>>>>>> Sr. Software Engineer >>>>>>>> SIP Media Control and Signaling >>>>>>>> Nokia Siemens Networks >>>>>>>> Boca Raton, FL-33487 >>>>>>>> Ph: 561-923-5085 (o), 561-923-2048 (o) >>>>>>>> ------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: [EMAIL PROTECTED] >>>>>>>>>> [mailto:[EMAIL PROTECTED] On Behalf >>>>>>>>>> Of ext Ivar >>>>>>>>>> Sent: Tuesday, May 15, 2007 11:02 AM >>>>>>>>>> To: [email protected] >>>>>>>>>> Subject: [Sip-implementors] ACK and UAS dialog >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> After reading RFC 3261, i don't find place what >>>>>>>>>> >>>>> describes following: >>>>> >>>>>>>>>> UAC send INVITE, UAS gives 200 ok answer. >>>>>>>>>> >>>>>>>>>> Now UAC send ACK (thats nicely in rfc 13.2.2.4), >>where ACK is >>>>>>>>>> handled in >>>>>>>>>> UAS ? >>>>>>>>>> Does UAS created dialog must wait for ACK confirmation, if >>>>>>>>>> >>>>>>>>>> >>>>>>>> it doesn't >>>>>>>> >>>>>>>> >>>>>>>>>> get it, dialog will be terminated and BYE is sent to UAC ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Sip-implementors mailing list >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>> >>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >> >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
