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
