Re: [Sip-implementors] 200 OK Retransmission
onewhoknows writes: > I have an issue with some older releases of Asterisk talking to an Avaya > PBX. > > I think there's a network issue somewhere, but in the meantime, I'd like to > know which side is handling the following transaction correctly: > > Asterisk > Avaya > Invite > > < 100 Trying > < 200 OK >> ACK > < 200 OK > < 200 OK > < 200 OK > ... several more times > < 200 OK > < BYE >> 200 OK > > The issue is intermittent and when it occurs, the far end does not see the > ACK. > > My question in this particular instance is should Asterisk be responding to > each 200 OK with an ACK, or has it satisfied its part of the transaction by > sending that first ACK? Each 200 OK has the same CSEQ, branch, etc. Every 200 that the UAC receives, it must answer with an ACK. See RFC 3261 section 13.2.2.4, "The UAC core MUST generate an ACK request for each 2xx received from the transaction layer.", etc. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
On 1/3/18 7:54 PM, onewhoknows wrote: Hello, I have an issue with some older releases of Asterisk talking to an Avaya PBX. I think there's a network issue somewhere, but in the meantime, I'd like to know which side is handling the following transaction correctly: Asterisk > Avaya Invite > < 100 Trying < 200 OK ACK < 200 OK < 200 OK < 200 OK ... several more times < 200 OK < BYE 200 OK The issue is intermittent and when it occurs, the far end does not see the ACK. My question in this particular instance is should Asterisk be responding to each 200 OK with an ACK, or has it satisfied its part of the transaction by sending that first ACK? Each 200 OK has the same CSEQ, branch, etc. Asterisk is wrong. The ACK must be transmitted for each 200 OK received. This is necessary in the case where an ACK is lost. The UAS is retransmitting the 200 because it hasn't yet received an ACK. You say this is intermittent, which is consistent with an ACK being lost. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] 200 OK Retransmission
Hello, I have an issue with some older releases of Asterisk talking to an Avaya PBX. I think there's a network issue somewhere, but in the meantime, I'd like to know which side is handling the following transaction correctly: Asterisk > Avaya Invite > < 100 Trying < 200 OK > ACK < 200 OK < 200 OK < 200 OK ... several more times < 200 OK < BYE > 200 OK The issue is intermittent and when it occurs, the far end does not see the ACK. My question in this particular instance is should Asterisk be responding to each 200 OK with an ACK, or has it satisfied its part of the transaction by sending that first ACK? Each 200 OK has the same CSEQ, branch, etc. Thanks! ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
>200 ok retransmission(starts at T1 and goes till T2=64*T1) is done by UAS Core or TU for both UDP/TCP till ACK comes >3xx-6xx retransmission(starts at Timer G=T1 and goes till Timer H=T2 )is done by UAS Tx layer for UDP only till ACK comes > reliable18x response retransmission((starts at T1 and goes till T2=64*T1)) is done by UAS Core for UDP only till PRACK comes. If T2 fires then UAS send 5xx for INVITE. Thanks & regards Ankur Bansal On Tue, Apr 29, 2014 at 6:42 PM, Brett Tate wrote: > See RFC 3262 section 3. > > > > *From:* Aditya Kumar [mailto:adityakumar...@yahoo.com] > *Sent:* Monday, April 28, 2014 9:59 PM > *To:* Brett Tate; Sip-implementors > *Subject:* Re: [Sip-implementors] 200 Ok retransmission > > > > Thanks Brett. > > > > so for 200 OK retranmission we start at t1 and stop at T2 and continue > untill we receive 64t1. > > can you also pl conform how the 18x need to be transmitted (both TCP and > UDP with 100rel)? > > this should be t1, 2t1,4t1?. > > -- > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
See RFC 3262 section 3. *From:* Aditya Kumar [mailto:adityakumar...@yahoo.com] *Sent:* Monday, April 28, 2014 9:59 PM *To:* Brett Tate; Sip-implementors *Subject:* Re: [Sip-implementors] 200 Ok retransmission Thanks Brett. so for 200 OK retranmission we start at t1 and stop at T2 and continue untill we receive 64t1. can you also pl conform how the 18x need to be transmitted (both TCP and UDP with 100rel)? this should be t1, 2t1,4t1?. -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
Thanks Brett. so for 200 OK retranmission we start at t1 and stop at T2 and continue untill we receive 64t1. can you also pl conform how the 18x need to be transmitted (both TCP and UDP with 100rel)? this should be t1, 2t1,4t1?. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
> how about PRACK-response on TCP? The PRACK and PRACK response retransmissions behave like other non-INVITE requests/responses. > if UA sends PRACK on TCP does not receive > 200 OK for prack? should it retransmit? No. -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
Thanks Brett for the detail explanation. So retransmission is needed in any transport layer. Related question, how about PRACK-response on TCP? if UA sends PRACK on TCP does not receive 200 OK for prack? should it retransmit? if so what is the Timer On Thursday, April 17, 2014 12:39 PM, Brett Tate wrote: Hi, It doesn't sound like you are interpreting section 13.3.1.4 correctly. Using default values, retransmissions occur .5, 1, 2, 4, 4, 4, ... until the 64*T1 timer pops. Also notice that 2xx is retransmitted over TCP. "Once the response has been constructed, it is passed to the INVITE server transaction. 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. Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15." And for completeness, you might want to look at RFC 6026 since it introduced more INVITE related timers to the transaction state machine. -brett -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 Ok retransmission
Hi, It doesn't sound like you are interpreting section 13.3.1.4 correctly. Using default values, retransmissions occur .5, 1, 2, 4, 4, 4, ... until the 64*T1 timer pops. Also notice that 2xx is retransmitted over TCP. "Once the response has been constructed, it is passed to the INVITE server transaction. 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. Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15." And for completeness, you might want to look at RFC 6026 since it introduced more INVITE related timers to the transaction state machine. -brett -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] 200 Ok retransmission
Hi All, Can you help me with the clarification? when acting as UAS and we send 200 Ok and dont receive ACK how many times should we reransmit 200 OK? in TCP there are no re transmission so after how much time we send BYE? want to know how is T2 coming to the picture and how are retranmission handled? UDP: 0,2,4,8,16 (if T2 is 16) stop here ? (or) 64T1? TCP: when do we send BYE after T2 (or) 64T1 for not receiving the ACK RFC 3261 from section 13.3.1.4 The INVITE is Accepted Once the response has been constructed, it is passed to the INVITE server transaction. 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 retransmissionuntil it reaches T2 seconds (T1 and T2 are defined in Section 17).. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
Hello Jitendra, I think application has to trigger BYE after the Timer H fires(ie..my answer is immediately after 31.5 sec). I can't find any RFC spec for this. Hello all, some one having good answer for this question. please welcome. Regards, Karthic -Original Message- From: Jitendra Singh Bhadoriya [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 3:10 PM To: JEEVANANDHAM KARTHIC KUMAR Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hi Karthic, I have a doubt here. The retransmission of the 2xx response In case ACK is not received will happen as below 1st 2xx - 0 2nd 2xx - 0.5 sec 3rd 2xx - 1.5 sec 4th 2xx - 3.5 sec 5th 2xx - 7.5 sec 6th 2xx - 11.5 sec 7th 2xx - 15.5 sec 8th 2xx - 19.5 sec 9th 2xx - 23.5 sec 10th 2xx - 27.5 sec 11th 2xx - 31.5 sec If even after 64*T1 (that is 32 seconds) the ACK is not received, the dialog Is confirmed but the session is terminated by sending BYE (as per RFC-3261). But after how many seconds of sending the last 2xx the BYE will be sent. How much time interval would be there between sending last 2xx (sent at 31.5 sec) and the BYE request(sent for session termination). Thanks Jitendra. -Original Message- From: JEEVANANDHAM KARTHIC KUMAR [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:40 PM To: Jitendra Singh Bhadoriya Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hello Jitendra, I think we can confirm from following section in RFC 3261 13.3.1.4 The INVITE is Accepted 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. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. UAC Point of view: 13.2.2.4 2xx Responses ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. thanks, Karthic -Original Message- From: Jitendra Singh Bhadoriya [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:25 PM To: JEEVANANDHAM KARTHIC KUMAR; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hi karthic, The Timers G and Timer H are used in case the INVITE Server Transaction has received 3xx-6xx response from TU and it has to retransmit these response until it gets an ACK. In the RFC 3261 nowhere it is given that for 200 OK also the Same retransmission process is applicable. Only what it says is - "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So can you please let me know from where I can confirm that the same Processing is true for 200 OK also. Regards, Jitendra. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JEEVANANDHAM KARTHIC KUMAR Sent: Wednesday, May 07, 2008 3:05 PM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx resp
Re: [Sip-implementors] 200 OK Retransmission
Hi Jitendra We can send BYE 4 seconds after the last retransmission of 2xx response as this is the maximum time we wait for the ACK to reach. Thanks & Regards, Sanjay Dhand -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Thursday, May 08, 2008 3:10 PM To: JEEVANANDHAM KARTHIC KUMAR Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi Karthic, I have a doubt here. The retransmission of the 2xx response In case ACK is not received will happen as below 1st 2xx - 0 2nd 2xx - 0.5 sec 3rd 2xx - 1.5 sec 4th 2xx - 3.5 sec 5th 2xx - 7.5 sec 6th 2xx - 11.5 sec 7th 2xx - 15.5 sec 8th 2xx - 19.5 sec 9th 2xx - 23.5 sec 10th 2xx - 27.5 sec 11th 2xx - 31.5 sec If even after 64*T1 (that is 32 seconds) the ACK is not received, the dialog Is confirmed but the session is terminated by sending BYE (as per RFC-3261). But after how many seconds of sending the last 2xx the BYE will be sent. How much time interval would be there between sending last 2xx (sent at 31.5 sec) and the BYE request(sent for session termination). Thanks Jitendra. -Original Message- From: JEEVANANDHAM KARTHIC KUMAR [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:40 PM To: Jitendra Singh Bhadoriya Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hello Jitendra, I think we can confirm from following section in RFC 3261 13.3.1.4 The INVITE is Accepted 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. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. UAC Point of view: 13.2.2.4 2xx Responses ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. thanks, Karthic -Original Message- From: Jitendra Singh Bhadoriya [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:25 PM To: JEEVANANDHAM KARTHIC KUMAR; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hi karthic, The Timers G and Timer H are used in case the INVITE Server Transaction has received 3xx-6xx response from TU and it has to retransmit these response until it gets an ACK. In the RFC 3261 nowhere it is given that for 200 OK also the Same retransmission process is applicable. Only what it says is - "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So can you please let me know from where I can confirm that the same Processing is true for 200 OK also. Regards, Jitendra. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JEEVANANDHAM KARTHIC KUMAR Sent: Wednesday, May 07, 2008 3:05 PM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass
Re: [Sip-implementors] 200 OK Retransmission
Hi Karthic, I have a doubt here. The retransmission of the 2xx response In case ACK is not received will happen as below 1st 2xx - 0 2nd 2xx - 0.5 sec 3rd 2xx - 1.5 sec 4th 2xx - 3.5 sec 5th 2xx - 7.5 sec 6th 2xx - 11.5 sec 7th 2xx - 15.5 sec 8th 2xx - 19.5 sec 9th 2xx - 23.5 sec 10th 2xx - 27.5 sec 11th 2xx - 31.5 sec If even after 64*T1 (that is 32 seconds) the ACK is not received, the dialog Is confirmed but the session is terminated by sending BYE (as per RFC-3261). But after how many seconds of sending the last 2xx the BYE will be sent. How much time interval would be there between sending last 2xx (sent at 31.5 sec) and the BYE request(sent for session termination). Thanks Jitendra. -Original Message- From: JEEVANANDHAM KARTHIC KUMAR [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:40 PM To: Jitendra Singh Bhadoriya Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hello Jitendra, I think we can confirm from following section in RFC 3261 13.3.1.4 The INVITE is Accepted 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. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. UAC Point of view: 13.2.2.4 2xx Responses ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. thanks, Karthic -Original Message- From: Jitendra Singh Bhadoriya [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:25 PM To: JEEVANANDHAM KARTHIC KUMAR; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hi karthic, The Timers G and Timer H are used in case the INVITE Server Transaction has received 3xx-6xx response from TU and it has to retransmit these response until it gets an ACK. In the RFC 3261 nowhere it is given that for 200 OK also the Same retransmission process is applicable. Only what it says is - "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So can you please let me know from where I can confirm that the same Processing is true for 200 OK also. Regards, Jitendra. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JEEVANANDHAM KARTHIC KUMAR Sent: Wednesday, May 07, 2008 3:05 PM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So please tell me how many times the TU will retransmits 2xx for which it has not an ACK. Thanks & Regards, Jitendra ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.c
Re: [Sip-implementors] 200 OK Retransmission
Hello Jitendra, I think we can confirm from following section in RFC 3261 13.3.1.4 The INVITE is Accepted 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. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. UAC Point of view: 13.2.2.4 2xx Responses ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. thanks, Karthic -Original Message- From: Jitendra Singh Bhadoriya [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 3:25 PM To: JEEVANANDHAM KARTHIC KUMAR; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK Retransmission Hi karthic, The Timers G and Timer H are used in case the INVITE Server Transaction has received 3xx-6xx response from TU and it has to retransmit these response until it gets an ACK. In the RFC 3261 nowhere it is given that for 200 OK also the Same retransmission process is applicable. Only what it says is - "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So can you please let me know from where I can confirm that the same Processing is true for 200 OK also. Regards, Jitendra. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JEEVANANDHAM KARTHIC KUMAR Sent: Wednesday, May 07, 2008 3:05 PM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So please tell me how many times the TU will retransmits 2xx for which it has not an ACK. Thanks & Regards, Jitendra ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
I pasted the significant RFC section inline Jitendra Singh Bhadoriya wrote: > Hi karthic, > > The Timers G and Timer H are used in case the INVITE Server Transaction > has received 3xx-6xx response from TU and it has to retransmit these > response until it gets an ACK. In the RFC 3261 nowhere it is given that > for 200 OK also the Same retransmission process is applicable. Only what > it says is - > > "If, while in the "Proceeding" state, the TU passes a 2xx response to > > the server transaction, the server transaction MUST pass this > > response to the transport layer for transmission. It is not > > retransmitted by the server transaction; retransmissions of 2xx > > responses are handled by the TU." > > So can you please let me know from where I can confirm that the same > Processing is true for 200 OK also. > 13.3.1.4 The INVITE is Accepted [snipped] Once the response has been constructed, it is passed to the INVITE server transaction. 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. Rosenberg, et. al. Standards Track[Page 85] RFC 3261SIP: Session Initiation Protocol June 2002 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. > Regards, > Jitendra. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > JEEVANANDHAM KARTHIC KUMAR > Sent: Wednesday, May 07, 2008 3:05 PM > To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] 200 OK Retransmission > > Hi, > > UAS should retransmit 200 OK at the interval of Timer G(initially T1 > then 2*T1) up to the timer H (64*T1). > Ref RFC 3261: A Table of Timer Values > Timer G - INVITE response retransmit interval > Timer H - Wait time for ACK receipt > > Regards, > Karthic > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jitendra Singh Bhadoriya > Sent: Wednesday, May 07, 2008 2:40 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] 200 OK Retransmission > > Hi, > > > > When a UAS receives INVITE, it responds with 200 OK. But in case, the > UAC does > > > > Not sends an ACK for the 200 OK, then how many times the 200 OK is > retransmitted and > > > > At what interval this re-transmission happens (Assuming non-reliable > transport such as UDP). > > > > >From RFC-3261 I am only able to find out the following > > > > Section : 17.2.1 or RFC - 3261 says > > > > "If, while in the "Proceeding" state, the TU passes a 2xx response to > > the server transaction, the server transaction MUST pass this > > response to the transport layer for transmission. It is not > > retransmitted by the server transaction; retransmissions of 2xx > > responses are handled by the TU." > > > > > > So please tell me how many times the TU will retransmits 2xx for which > it has not an ACK. > > > > Thanks & > > Regards, > > Jitendra > > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
Hi karthic, The Timers G and Timer H are used in case the INVITE Server Transaction has received 3xx-6xx response from TU and it has to retransmit these response until it gets an ACK. In the RFC 3261 nowhere it is given that for 200 OK also the Same retransmission process is applicable. Only what it says is - "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So can you please let me know from where I can confirm that the same Processing is true for 200 OK also. Regards, Jitendra. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JEEVANANDHAM KARTHIC KUMAR Sent: Wednesday, May 07, 2008 3:05 PM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 200 OK Retransmission Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So please tell me how many times the TU will retransmits 2xx for which it has not an ACK. Thanks & Regards, Jitendra ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
Also see: http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-01.txt On Wed, May 7, 2008 at 3:04 PM, JEEVANANDHAM KARTHIC KUMAR <[EMAIL PROTECTED]> wrote: > Hi, > > UAS should retransmit 200 OK at the interval of Timer G(initially T1 > then 2*T1) up to the timer H (64*T1). > Ref RFC 3261: A Table of Timer Values > Timer G - INVITE response retransmit interval > Timer H - Wait time for ACK receipt > > Regards, > Karthic > > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jitendra Singh Bhadoriya > Sent: Wednesday, May 07, 2008 2:40 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] 200 OK Retransmission > > Hi, > > > > When a UAS receives INVITE, it responds with 200 OK. But in case, the > UAC does > > > > Not sends an ACK for the 200 OK, then how many times the 200 OK is > retransmitted and > > > > At what interval this re-transmission happens (Assuming non-reliable > transport such as UDP). > > > > >From RFC-3261 I am only able to find out the following > > > > Section : 17.2.1 or RFC - 3261 says > > > > "If, while in the "Proceeding" state, the TU passes a 2xx response to > > the server transaction, the server transaction MUST pass this > > response to the transport layer for transmission. It is not > > retransmitted by the server transaction; retransmissions of 2xx > > responses are handled by the TU." > > > > > > So please tell me how many times the TU will retransmits 2xx for which > it has not an ACK. > > > > Thanks & > > Regards, > > Jitendra > > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK Retransmission
Hi, UAS should retransmit 200 OK at the interval of Timer G(initially T1 then 2*T1) up to the timer H (64*T1). Ref RFC 3261: A Table of Timer Values Timer G - INVITE response retransmit interval Timer H - Wait time for ACK receipt Regards, Karthic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jitendra Singh Bhadoriya Sent: Wednesday, May 07, 2008 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK Retransmission Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So please tell me how many times the TU will retransmits 2xx for which it has not an ACK. Thanks & Regards, Jitendra ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] 200 OK Retransmission
Hi, When a UAS receives INVITE, it responds with 200 OK. But in case, the UAC does Not sends an ACK for the 200 OK, then how many times the 200 OK is retransmitted and At what interval this re-transmission happens (Assuming non-reliable transport such as UDP). >From RFC-3261 I am only able to find out the following Section : 17.2.1 or RFC - 3261 says "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU." So please tell me how many times the TU will retransmits 2xx for which it has not an ACK. Thanks & Regards, Jitendra ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
