>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
