sip-ua timers on CUBE

[Lee Marson]

Hello,

Hopefully  a simple question but I can't find any good documentation on the use of sip-ua timers with in the CUBE config and wondered if anyone had the answer please. With regards to the following timers

sip-ua

 retry response 3

 timers connect 100

From debugs it seems that a 200 OK is sent out with a T1 timer of 100ms (timers connect 100) so if no ACK is returned the CUBE will send another (retry response) 3 x 200 OK messages at 100ms, 200ms and 400ms.

So how long is the total time allowed to receive the ACK for the original 200OK ?

Is it 100+200+400 = 700ms or is it 100+200+400+800 = 1.5secs

Had some issues with sessions timing out but wanted a better understanding of the window.

So I guess my question is does the forth and final 200OK response wait another Time interval (800ms) or does it send but clear down the session right away?

The default connect timer is 500ms which should improve things if there are delays in the network.

Thanks

Lee.

[Mohammed al Baqari]

Hi,

Based on your config, this what will happen:

Initial 200 OK .... wait for 100 msec

1st Retry 200OK ... wait for 100 msec

2nd Retry 200 OK .... wait for 200 msec

3rd Retry 200 OK .... Wait for 400 msec

The total time to wait will be 100 + 100 + 200 + 400 = 800 msec

[Lee Marson]

Hi Mohammed,

Thanks for the quick response however from my debugs are showing:

Initial 200 OK .... wait for 100 msec

1st Retry 200OK ... wait for 200 msec

2nd Retry 200 OK .... wait for 400 msec

3rd Retry 200 OK .... Wait for 800 msec

Which would be 1.5s ?

thanks

Lee.

[Mohammed al Baqari · Accepted solution]

Hi,

You are right. It should be 1.5 sec (100+200+400+800). I think I repeated 100 twice by mistake.

[Lee Marson]

Thanks

[Saiyed Anjum Bukhari]

Can someone tell me why the duration gets doubled on every retry? If the retry timer is 100 msec shouldn't it send the 200 OK every 100 msec ?

[Saiyed Anjum Bukhari]

ok did some digging and found out that it uses the concept of exponential back-off. If a response is not received it sends the next invite after 2 times the last timeout.

For Example

Assuming the default T1 of 500ms, the first INVITE message is sent at time zero.  The second is sent 500ms after the first.  The third is sent 2 times 500ms (1 second) after the second.  The fourth is sent 2 times 1 second (2 seconds) after the third.  The fifth at 4 seconds, the sixth at 8 seconds, the seventh at 16 seconds, and the eighth and final INVITE would be sent at 32 seconds.  I say final because at 32 seconds we’ve reached Timer B.

taken from this blog:

https://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/