>run a 64 * t1 second timer to handle duplicate 2xxs ON UAC ??? hmm seems i really miss something. Can you exmaplain with few word why timer is needed in UAC, in UAS i get why, UAS must retransmit 2xx while gets answer,uac needs just to answer to 2xx with ACK.
Do you handle these in dialog or out side dialog ? Singh, Indresh (SNL US) wrote: > 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
