SIP timers

The timer table

RFC 3261 defines two kinds of timer. The doubling ones (A, E, G) pace retransmissions over UDP; the fixed ones either decide when to give up (B, F, H) or how long to hang around absorbing stragglers (D, I, J, K). Appendix A collects them into one table — here it is with the arithmetic done:

Two things to notice. Timer C is the odd one out — a proxy timer, not derived from T1, and why a call can sit in limbo for three minutes rather than 32 seconds once a 100 Trying has been seen. And every "0 s on TCP" entry exists only to absorb UDP retransmissions; a reliable transport produces none, so the state evaporates. (RFC 6026 later added Timers L and M, both 64 × T1, to repair 2xx handling — you will meet them in stack source, not traces.)

Where the 32 seconds comes from

An INVITE over UDP is retransmitted on a doubling ladder: 500 ms after the first copy, then 1 s, 2 s, 4 s, 8 s, 16 s. After the seventh transmission the sender has waited 63 × T1; RFC 3261 rounds the give-up point to 64 × T1 and calls it Timer B. Non-INVITE requests hit the same wall as Timer F. Either way the transaction layer reports a timeout, and most stacks log it as a locally minted 408 — which is why the 408 page on this site is mostly about missing packets.

The third 32 arrives after answer. A UAS retransmits its 200 OK — starting at T1, doubling up to T2 — until the ACK arrives; if 64 × T1 passes without one, RFC 3261 §13.3.1.4 has it keep the dialog but end the call with a BYE. Timer H (§17.2.1) is the same rule for non-2xx final responses. Between them they produce the signature complaint: "the call connects and drops after exactly 32 seconds." That is not a media problem — it is an ACK that never made it, usually a NAT or a broken Contact or Record-Route.

One saving grace: a provisional response stops the INVITE clock. Once a 100 Trying arrives the client transaction leaves the Calling state, Timer B no longer applies, and responsibility passes to the proxy's Timer C — required by §16.6 to exceed three minutes. Dying after 32 seconds of silence and dying after three minutes of ringing are failures of different timers, in different boxes.

INVITE vs non-INVITE transactions

The two state machines pace their retransmissions differently. The INVITE retransmit timer (A) doubles without a cap — a human is being waited for, and hammering helps nobody. The non-INVITE retransmit timer (E) doubles only until it reaches T2 = 4 s, then repeats at that rate, so a dead peer receives eleven copies of your OPTIONS or REGISTER rather than seven before Timer F fires at the same 32 s.

The difference that bites: a provisional response rescues an INVITE indefinitely but rescues a non-INVITE not at all. A 100 Trying to a REGISTER merely slows the retransmissions to one every T2 — Timer F keeps running regardless (§17.1.2.2). If the final response takes longer than 32 seconds, the transaction fails however much Trying was received; slow non-INVITE work — registration bursts, heavy NOTIFY bodies, a sluggish registrar database — therefore fails in a way no provisional can fix.

What changes over TCP

Less than people hope. The retransmit timers A and E never start — TCP redelivers on its own — and the absorb-the-stragglers timers D, I, J and K drop to zero, because there are no stragglers. But the give-up timers survive intact: B, F and H all still fire at 64 × T1. TCP guarantees delivery to the next hop, not an answer from it; a peer that accepts the connection and says nothing still costs you 32 seconds. And a UAS retransmits its 200 OK even over TCP — that rule lives end-to-end at the UA core, because the ACK must cross every hop and any hop may be UDP.

Session timers are a different thing

RFC 4028's session timers share the word and nothing else. They work in minutes, not milliseconds: a Session-Expires header (commonly 1800 s) is negotiated in the INVITE, one side is elected refresher, and it must re-INVITE or UPDATE before the interval runs out — conventionally at the halfway mark — or the other side is entitled to hang up. Min-SE sets the floor a UAS will accept (never below 90 s), and 422 Session Interval Too Small is that negotiation visibly failing. The diagnostic split is clean: death at 32 seconds is a transaction timer; death at a suspiciously round wall-clock time — fifteen minutes, thirty — is a session timer, almost always a refresh being lost or rejected.

Tuning, and why the defaults usually win

Most stacks expose T1 and Timer B under some name, and there is one genuinely good reason to touch them: failover. Waiting the full 32 seconds before hunting to the next trunk is an eternity, so a Timer B of four to six seconds toward a carrier you already probe with OPTIONS is defensible.

Lowering T1 instead is the classic mistake. T1 scales everything — the retransmit pacing, all three 64 × T1 walls, the absorb states — and a T1 shorter than the real round trip to some peer means retransmitting INVITEs that were already going to be answered; the copies are where duplicate calls and double billing come from. The defaults are sized for the worst path you will ever cross, not the average; being unilaterally faster than the network mostly manufactures duplicates. Change Timer B where failover demands it; leave T1 alone unless every peer is on your own LAN.

What timer trouble looks like in a trace

1. The same request at 0.5 / 1 / 2 / 4 / 8 / 16 s gaps, then nothing — Timer A pacing, Timer B expiry, seven copies. The 408 page covers what makes the replies vanish.
2. The same non-INVITE every 4 seconds — Timer E pinned at T2, roughly eleven copies before Timer F. A trunk whose OPTIONS look like this is already down.
3. A 200 OK repeating with no ACK, then a BYE about 32 s after answer — the ACK path is broken. Check Contact, Record-Route and the NAT between them.
4. A non-2xx final response repeating (Timer G) with no ACK — the same disease on the failure path; Timer H ends it quietly.
5. A response arriving after the ladder stopped — a late answer to a transaction that no longer exists. What happens next is usually a 481.
6. A CDR full of durations of exactly 32.0 s — the 64 × T1 signature. Round wall-clock failures are session timers; 32-second failures are transaction timers.