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
