>> Can you exmaplain with few word why timer is needed in UAC A timer is needed in UAC because of network delay the UAS may be retransmitting the 200 OK responses. Now once the UAS receives the first 200 OK it would send an ACK immedialtey, but for subsequent 200OK retransmission/duplicate 200OK it would expect only till 64*t1 and respond with an ACK. So you have to run a timer for 64*t1 and with in that time if you receive a duplicate 200OK you have to respond with an ACK, afterwards if you receive a duplicate 200 OK I think it would get discarded.
Section 13.2.2.4: Page 83. First paragraph Regards, Indresh >>-----Original Message----- >>From: ext Ivar [mailto:[EMAIL PROTECTED] >>Sent: Thursday, May 17, 2007 10:38 AM >>To: Singh, Indresh (SNL US) >>Cc: [email protected] >>Subject: Re: [Sip-implementors] ACK and UAS dialog >> >> >>>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
