Retransmission blocks have to be created for each INVITE-2xx-ACK exchange ( including re-INVITEs ) and at a given point of time there could be many
So what I would do is that when we receive/process a 2xx response on UAC side I would create a retrans block and set a flag indicating need to run a 64 * t1 second timer to handle duplicate 2xxs and this bool I would also use for indicating the side of this INVITE-2xx-ACK exchange. For the UAS side this flag ( running ACK timer to handle duplicate 2xx ) would not be set, so it would indicate the UAS side. So the way I would recommend is keeping the mode UAC/UAS inside the retransmission blocks associated with dialog for both sides ( UAC/UAS ) where are created for each INVITE-2xx-ACK exchange and not in the dialog object itself. 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 9:58 AM >>To: Singh, Indresh (SNL US) >>Cc: [email protected] >>Subject: Re: [Sip-implementors] ACK and UAS dialog >> >> >>>Dialog mode does make sense >>Hmm, but how you konw then if to retransmit ack or wait ACK ? >>Because UAS and UAC modes may switch. >> >>For example: >> >>UA1 -> invite -> U2 >>UA1 has uac dialog, UA2 has UAS dialog, both knwo what todo. >>UA2 retransmits 2xx response while get ack, UA1 sends ACK. >> >>But now for example UA2 -> re-INVITE -> UA1, dialogs must >>change mode ... . Or am i missing something. >> >>My point is to make automatic dialog, what hides BYE and ACK >>from end users, dialog must smart enough to handle these. >> >>Thanks, >> >> >> >> >>Singh, Indresh (SNL US) wrote: >>> 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
