In comedy they say that timing is everything. While it’s not quite everything for SIP, timing is still very important. In fact, there are several aspects of SIP that ensure that messages are delivered on time.
In this blog article I will deal with the three basic SIP timer parameters – T1, Timer B, and Timer F. T1 is the estimated round trip time of an IP packet. By default, T1 is set to 500 milliseconds which for many networks can be a little on the high side. However, the SIP standard allows you to ignore the default and set it to something that better matches your network characteristics.
The second SIP timer parameter is Timer B. Timer B is the maximum amount of time that a sender will wait for an INVITE message to be acknowledged — i.e. a SIP response message is received.
Timer F is the maximum amount of time that a sender will wait for a non INVITE message to be acknowledged. SIP messages such as REFER, INFO, MESSAGE, BYE, and CANCEL fall into this category.
Just the Facts
The way that Timer B and Timer F function is pretty straightforward. Both timers default to 64 times T1. If you take the T1 default of 500ms, Timer B and Timer F will be 32 seconds. In other words, if an INVITE is sent and no response message is received, that INVITE will timeout in 32 seconds. Seems like a long time, doesn’t it? It is and that is why some installations will set T1 to something a little more reasonable.
If a SIP message is sent and no response is received, the sender doesn’t keep pounding away at the destination. Overwhelming an unresponsive SIP endpoint with a barrage of messages will only make matters worse. Instead, the sender does something called exponential back-off.
Let’s look again at that INVITE. If an INVITE is sent and no response is received, the INVITE is resent T1 later. If a response is still not received, the INVITE is sent 2 times the last timeout value. This doubling goes on until Timer B is reached.
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.
It’s as Easy as 1, 2, 3
That isn’t too hard to understand, is it? You send the first, you send the second at T1, and you keep doubling until you reach Timer B.
Some SIP solutions make it even easier. Instead of specifying Timer B/F as 64 times T1, Avaya Aura allows you specify the final timeout value. In other words, you are asked for Timer B/F (Avaya only uses one timer for all SIP message types) in System Manager and that value is used along with T1 (which for Avaya appears to be the default of 500ms).
If you set Timer B/F to 4 seconds, the timeouts would look like this:
First INVITE at zero, second INVITE at 500ms, third INVITE at 1 second, fourth INVITE at 2 seconds, fifth and last INVITE at 4 seconds. This is far more reasonable than waiting the default of 32 seconds before deciding that a SIP endpoint is not going to respond.
There are other aspects of SIP timing that I will address in later blogs, but understanding T1, Timer B and Timer F are crucial to becoming a SIP guru.
For a further look, please read my Understanding SIP Timers Part II.
Tao, Zen, and Tomorrow 
Thanks for explaining it simple. I find that alot of people in technology tend to make things sound so complicated when they really aren’t. Great article!
Thank you! That means a lot to me.
Thank you for good explanation!
// VG
You’re welcome. Thank you for stopping by!
Thank you for keeping is so simple. Great article!
Thanks for reading and taking the time to comment, Steve!
Its greatly written. I have understood very well. Thanks.
simple and straight.
I have a query related
What is the use of Timer K in non-invite client transaction flow diagram.
Any example in which we can see re transmission of response for non-INVITE transaction.
Do we really need to wait for T4 secs? Why can’t we move to terminated state immediately after completed for non reliable transport?
Mangnus. All I can do is quote RFC 3261. As you can see, T4 is there to account for retransmissions on unreliable networks.
“Once the client transaction enters the “Completed” state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The “Completed” state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, the client transaction MUST transition to the “Terminated” state.
Once the transaction is in the terminated state, it MUST be destroyed immediately.”
Hello, great article! I have a question though.
Let’s take the sixth INVITE message for example. It is sent after 8 seconds have passed since the fifth INVITE has been sent out, right ? Having this progression in mind and the fact that Timer B is 64*T1 (32 seconds), the maximum number of INVITE messages to be sent out is 7 (0+0.5+1+2+4+8+16=31.5 seconds since the first INVITE was sent). The eight INVITE message would not have the chance to be sent out because Timer B will expire. Please correct me if I misunderstood. Thanks.
Hi great article. In order to make it simple for myself:
T1 = 500ms
Timer B and Timer F = T1 * 64
First invite sent
2nd Invite is sent after 500 ms
3rd Invite is sent after 2 * 500 ms = 1 second
4th Invite is sent after 2 * 1 second = 2 seconds
5th Invite is sent after 2 * 2 seconds = 4 seconds
6th Invite is sent after 2 * 4 seconds = 8 seconds
7th Invite is sent after 2 * 8 seconds = 16 seconds
8th Invite is sent after 2 * 16 seconds = 32 seconds
You got it!
I’ll disagree with shahhussain, and agree with sleifer on the timing. It may be the semantics of how you say it, but the way its described in the article, the 3rd Invite is sent at time = 1.5sec from the start not 1 sec.
therefor the 8th invite will never be sent, because timer B expires shortly after the 7th attempt.
Invite attempt # Wait after last cumulative time (sec)
before sending (sec)
1 0 0
2 0.5 0.5
3 1 1.5
4 2 3.5
5 4 7.5
6 8 15.5
7 16 31.5
8 32 63.5
The way I sent it was confusing and I apologize for that. I was trying to refer to the wait times between messages.
The first message is sent (time zero). The second message is sent 500ms later. The third message will wait a full second after that to resend. So, yes it is 1.5 seconds on a linear timeline.
I will go back to the text and make is clearer.
Hi mate..
Can you explain your calaculation in bit details.its confusing me.thanks
Thanks Andrew, for the Exponential back-off concept.
What i feel is the timing is always referred from the 1st INVITE and not from the previous INVITEs sent.So INVITE requests will trigger at
1st message—>0 sec,
2nd message—->0.5, difference from 1st msg=0.5 sec
3rd message —>1, difference from 2nd msg=0.5 sec
4th message—> 2, difference from 3rd msg=1 sec
5th message —->4, difference from 4th msg=2 sec
6th message—> 8 sec, difference from 5th msg=4 sec
7th message—–> 16 sec, difference from 6th msg=8 sec
request timeout, Timer B expires—–>32sec ,difference from 7th msg= 16 sec.
So the 8 th message is not sent at 32 sec, rather we can say the UE waits for another 16 sec after the 7 th message for the response to come and then the timer B expires.
So the sum of the differences (0.5+0.5+1+2+4+8+16=32)
Please correct me if i am wrong.
You are absolutely correct. I’ve seen this scenario practically. Only 7 INVITES.
RFC 3261 states 100trying, like any other provisional response, will stop invite retransmissions. If a 180 is sent instead of a 100 trying and there’s never a 200ok, is it safe to assume the invite will be re-transmitted ?
Once the 180 is received, there will be no more retransmissions of the INVITE.
actually, the 180 is provisional as well so there should be no retransmission.
I’m so lucky i came across your blog! You explain things in a very easy way, as one of the comments up there said, people in technology make things sound so difficult when they really arent. Thank you
again, great post Andrew, thank you.
I like very much the bit of story telling before getting technical:
“In comedy they say that timing is everything. While it’s not quite everything for SIP”
Nice clear explanation of Timer B. I have a question – If an invite is being sent to the SM and the sending party (say Communication Manager) is waiting for a response from SM, wIll the TImer B control that time as well. Or is it that Timer B is only applicable for the invite being sent by the SM?
Timer B applies to every SIP element.
Hello Andrew, Which timer will fire if there is a timeout after 100 trying.
Thank you in Advance
Suvransu
Went through part 2 and understood
I knew you would. 🙂
You have always been a savior! Wonderful article! absolutely love your posts, helps me understand SIP so much better! Thank you! 🙂
Hi,Andrew
While analyzing VoLTE call fail log, I found TAS retransmit 183 with SDP as exponetial back-off.
Do you have any idea about the related timer regarding the retransmission of a provisional response?
Hi, Thanks for your explanation.
can you tell me what is the timer between the first response SIP 100 and the SIP 180 (or SIP 183) ?
Thanks.
There is no timer. 180 and 183 are not required response messages.
Hi Andrew,
I was following your thread. thanks.
You mean, after the UAS side receive 180/183 from the UA, there is no timeout value defined according to standards ? It is up to the UAS to define it ?.
What about Timer F, is it valid in this scenario ?
thanks.
Timer F is valid when non INVITE messages are sent, but once the session is established and new messages are sent, it is up to the client and server (or components in between — such as a firewall) to establish further timers.
Thanks Andrew..!
When there is no response for an INVITE even after Timer B fires, what will be the UAC behavior
How SIP signaling knows that media is disconnected and it needs to be also end its session?
SIP signalling does not know when the media has been disconnected. That has to occur via RTP, an intermediate server (e.g. SBC), or the UA saying that the session is over.
After first invite send get response 100 trying but after some time other invite request send why ??????????
Make sure that the 100 Trying matches the INVITE.
How many Retry of Invite can be sent . if UAS responding 500/503.
is any logic at UAC side or configuration dependency
Since each new INVITE would be a new transaction, there are no rules. You could send as many as you want. I would assume you would want to figure out what is causing the error condition, though.
Thanks for feedback! I understand numberof retries depends on UAC side its mangeable.
but each will have same call ID . so transaction should be same .
likely we use DNS-SRV for routing..if 2 IP’s within DNS-SRV, then if fsrt IP resopnding 500/503 then next Invite will be retried but call id will be same .
+++++++
If an INVITE transaction ends with a 5xx response, you will not reuse call-ids. You will start the next INVITE with a new one.
Thank you!
well explained if invite is lost re transmission of invite will comes in picture right ?
Yes.
Hi Andrew , Nice article and explanation. I have question, What if the timer B fires during proceeding state ie already received 180 or 183, but yet get a 200 OK. ? Should A party sent CANCEL. Is there any way to extend this time. I mean more ringing time giving B party more time to answer the call.
One a 1xx is received, Timer B is cancelled.
What is timer between sending an INVITE message and receiving 180 /183 ?
Timer B