Re: [Sip-implementors] 200 OK Retransmission

2018-01-03 Thread Dale R. Worley
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

2018-01-03 Thread Paul Kyzivat

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


Re: [Sip-implementors] 200 Ok retransmission

2014-04-29 Thread Brett Tate
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

2014-04-29 Thread ankur bansal
 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 br...@broadsoft.com 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

2014-04-28 Thread Aditya Kumar
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

2014-04-21 Thread Aditya Kumar
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 br...@broadsoft.com 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

2014-04-17 Thread Brett Tate
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

2008-05-08 Thread Jitendra Singh Bhadoriya

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.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 200 OK Retransmission

2008-05-08 Thread sanjay.dhand
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 this

response to the transport layer for transmission

Re: [Sip-implementors] 200 OK Retransmission

2008-05-08 Thread JEEVANANDHAM KARTHIC KUMAR
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 response to

the server transaction, the server transaction MUST

Re: [Sip-implementors] 200 OK Retransmission

2008-05-07 Thread [EMAIL PROTECTED]
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