01-29-2016 01:37 AM - edited 03-17-2019 05:39 AM
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.
Solved! Go to Solution.
01-29-2016 03:01 AM
Hi,
You are right. It should be 1.5 sec (100+200+400+800). I think I repeated 100 twice by mistake.
01-29-2016 02:07 AM
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
01-29-2016 02:31 AM
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.
01-29-2016 03:01 AM
Hi,
You are right. It should be 1.5 sec (100+200+400+800). I think I repeated 100 twice by mistake.
01-29-2016 03:06 AM
Thanks
12-31-2020 02:54 AM
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 ?
12-31-2020 05:38 PM
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/
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide