Understanding SIP Timers Part I

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.


  1. 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!

  2. Andrew Prokop · · Reply

    Thank you! That means a lot to me.

  3. Thank you for good explanation!

    // VG

    1. You’re welcome. Thank you for stopping by!

  4. Thank you for keeping is so simple. Great article!

    1. Thanks for reading and taking the time to comment, Steve!

  5. Its greatly written. I have understood very well. Thanks.

  6. Mangnus · · Reply

    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?

  7. 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.”

  8. 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.

  9. 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

  10. Oliver__twisted · · Reply

    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

    1. 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.

    2. Hi mate..
      Can you explain your calaculation in bit details.its confusing me.thanks

  11. 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.

  12. 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 ?

    1. Once the 180 is received, there will be no more retransmissions of the INVITE.

  13. actually, the 180 is provisional as well so there should be no retransmission.

  14. 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

  15. 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”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: