Yep there is some point. But again reaading too much rfc, head gets messed like:
13.2.2.4 The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. but invite transaction is always terminated after first 2xx. Probably i start messing your heads too ... . Like wise man said: 1 dumb (like me) can ask more than 10 wise man to answer ... . Singh, Indresh (SNL US) wrote: > Please read > > "Now once the UAS receives the first" As "Now once the UAC receives the > first" In the below reply :) > > 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: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf >>> Of ext Singh, Indresh (SNL US) >>> Sent: Thursday, May 17, 2007 11:58 AM >>> To: ext Ivar >>> Cc: [email protected] >>> Subject: Re: [Sip-implementors] ACK and UAS dialog >>> >>> >>>>> 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 >>> >>> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
