The SIP INVITE Lifecycle: 100 Trying through 200 OK ACK, with the retransmission rules that actually matter

Every SIP call starts the same way, with an INVITE leaving one endpoint and threading its way to another. Every engineer who has worked with SIP has drawn the ladder diagram on a whiteboard. And yet when something goes wrong mid-setup — an INVITE retransmitting forever, a 200 OK repeating every two seconds, a call that answers in the traces but never makes audio — the same engineers often reach for hand-waving explanations rather than the transaction state machine that would tell them the answer cleanly.

RFC 3261 §17 is the section most SIP engineers read once and never revisit. It defines two client transactions (INVITE and non-INVITE), two server transactions (ditto), and a set of timers — T1, T2, T4, Timer A through Timer K — that govern retransmission, timeout, and transaction persistence. The state machine is not decorative. It is the contract that every compliant SIP endpoint must honour, and the values it produces are visible directly in a Wireshark trace. This post walks the INVITE lifecycle end to end, calls out the three places engineers most often misread a trace, and gives you the timer values to memorise.

The INVITE goes out

The User Agent Client (UAC) builds the INVITE, opens or reuses its transport (UDP, TCP, or TLS), and hands the request to the transaction layer. At that instant the INVITE client transaction enters the Calling state.

Two things start happening in parallel. First, if the transport is unreliable (UDP), Timer A fires at T1 (default 500ms) and the UAC retransmits the INVITE. Timer A then doubles — 1s, 2s, 4s, 8s, 16s — until it is cancelled by the arrival of a provisional or final response, or until Timer B fires. Second, Timer B starts at 64×T1 (32 seconds by default). When Timer B fires, the transaction gives up and informs the Transaction User that the far end is unreachable. Over TCP or TLS, Timer A is not used at all — the transport takes responsibility for reliable delivery — but Timer B still applies, because a SIP-layer timeout must exist even when the TCP connection is healthily keeping a silent call alive.

100 Trying: the response that should always appear first

The moment the first hop receives the INVITE, it is required by RFC 3261 §21.1.1 to stop the upstream UAC's retransmissions, which it does by emitting a 100 Trying. The 100 is always hop-by-hop — it exists only to silence the peer that sent the INVITE — and it never has a To-tag, because it does not establish or progress a dialog. Crucially, 100 Trying is never forwarded by a stateful proxy. If a trace taken at the UAC shows no 100 and the INVITE keeps retransmitting, the next-hop element has not generated one. That is almost always an SBC or B2BUA doing something unusual, or a proxy processing synchronously against a slow downstream that has exceeded its own inter-hop retransmit budget.

On receipt of a 1xx, the INVITE client transaction moves from Calling to Proceeding. Timer A is cancelled. The UAC now waits — for up to Timer B — for a final response. You can sit in Proceeding for hours in the case of long-ring scenarios, and nothing on the wire will fire. That is by design: once a provisional has arrived, the far end is known to be alive at the transaction level.

180, 183, and the PRACK question

Beyond 100, the provisional responses you see most often are 180 Ringing and 183 Session Progress. These are not hop-by-hop: they carry a To-tag and they are forwarded end-to-end. Under base RFC 3261 they are unreliable — they may be retransmitted by a proxy that lost its upstream path, and the UAC has no acknowledgement mechanism for them. This is fine for 180, which is essentially informational, but becomes a real problem for 183 Session Progress carrying an SDP answer for early media. If that 183 is lost, the UAC has no way to know, and the early-media RTP will be sent to an address the UAC never heard.

RFC 3262 (PRACK) solves this by introducing the 100rel option tag. A UAC that supports PRACK signals it with Supported: 100rel (or Require: 100rel) on the INVITE. The UAS then marks each reliable provisional with an RSeq header; the UAC must acknowledge each with a PRACK, which carries an RAck echoing both RSeq and the CSeq of the corresponding INVITE. Until PRACK arrives, the UAS retransmits the provisional using the same T1-based exponential backoff as an INVITE retransmit on the server side.

What to look for in a trace: a 183 with SDP, followed by a second identical 183 one second later, followed by a third two seconds after that, is the fingerprint of a missing PRACK — either the UAC does not implement it, or the Require: 100rel negotiation failed and the UAS retransmitted anyway. Either way, early media will be unreliable and the call will often look healthy through to 200 OK while the user is complaining that the announcement didn't play.

The 200 OK and the end-to-end ACK

A final response (2xx, 3xx, 4xx, 5xx, 6xx) moves the client transaction from Proceeding into either Completed (for non-2xx) or Terminated (for 2xx). This is the single most counter-intuitive piece of RFC 3261, and the place where engineers most often misread a trace. ACK for a 2xx and ACK for a non-2xx are different messages, produced by different layers, with different routing.

For a non-2xx final response, the ACK is part of the INVITE transaction. It is hop-by-hop, it is absorbed by each stateful proxy on the path, and each proxy generates its own ACK upstream. The transaction enters Completed and stays there for Timer D, which is ≥32s over UDP and 0 over TCP — this is the interval during which additional retransmissions of the final response may arrive and must be matched to the existing transaction so that the UAC can re-ACK them.

For a 2xx, the ACK is a new transaction, generated by the Transaction User (not the transaction layer), and it is routed end-to-end using the dialog's Route set. Stateful proxies on the path do not forward the 2xx ACK — they see it only if they placed themselves in the Route set via Record-Route. This is why a 2xx can retransmit for 30 seconds while the ACK is stuck at one end: the ACK is not travelling the INVITE's signalling path. It is travelling the dialog's routing path.

Note that for a 2xx, the INVITE server transaction actually terminates immediately — it does not wait for the ACK. RFC 3261 §13.3.1.4 hands the retransmission and ACK-wait responsibility to the UAS's Transaction User instead. The TU retransmits the 2xx at T1, 2×T1, 4×T1, capped at T2, for a total budget of 64×T1 (~32s). If no ACK arrives in that window, the TU declares the call failed and sends a BYE — even though the UAC believes the call is answered and may already be sending RTP. If Record-Route was not set correctly, or if a Contact URI is unreachable (a very common NAT failure mode), this is exactly how the call fails.

The retransmission timer table you actually need to know

Memorise these. Every modern SIP stack uses them as defaults unless explicitly retuned:

• T1 = 500ms. The RTT estimate. Every other timer is built from this.
• T2 = 4s. The cap for the doubling backoff on non-INVITE requests and on 2xx-server retransmits.
• T4 = 5s. The maximum time a message is expected to remain in the network.
• Timer A (INVITE client retransmit, UDP): starts at T1, doubles on each retransmission. Cancelled on first response, or superseded by Timer B.
• Timer B (INVITE client timeout): 64×T1 = 32s. Fires in Calling state if no response.
• Timer D (INVITE client Completed→Terminated): ≥32s UDP, 0 TCP. Absorbs retransmitted non-2xx.
• Timer E (non-INVITE client retransmit, UDP): starts at T1, doubles to T2 cap.
• Timer F (non-INVITE client timeout): 64×T1 = 32s.
• Timer G (INVITE server non-2xx retransmit, UDP): starts at T1, doubles to T2 cap. Applies only in the Completed state, which is only entered for non-2xx final responses.
• Timer H (INVITE server wait-for-ACK on non-2xx): 64×T1 = 32s. Fires if ACK for a non-2xx never arrives at the server transaction.
• Timer I (INVITE server Confirmed→Terminated): T4 UDP, 0 TCP. Absorbs duplicate ACKs after one has been received.
• Timer J (non-INVITE server Completed→Terminated): 64×T1 UDP, 0 TCP.
• Timer K (non-INVITE client Completed→Terminated): T4 UDP, 0 TCP.

The 32-second rule appears four times (B, D, F, H) and is the single most-quoted number in practical SIP operations. If a call isn't going to happen, it is going to not-happen within 32 seconds.

What to look for in a trace

• INVITE retransmitting 5 times, no 100 Trying, final timeout at ~32s. First hop is not stateful, or the SBC is dropping the INVITE silently. Take a capture one layer below — pcap the SBC's inside and outside simultaneously and compare.
• 200 OK retransmitting every 0.5s, 1s, 2s, 4s, capped at 4s. The ACK is not reaching the UAS. Three suspects: Record-Route missing, Contact URI unreachable (NAT), or the UAC's transaction layer is confused about which socket to send on. Check the Contact header of the 2xx against the reverse-path routing.
• 180 Ringing followed by a long gap followed by 487 Request Terminated. This is normal — the caller hung up during ringing, the UAS sent a CANCEL, the original INVITE completed with 487. Not a bug unless the 487 itself retransmits.
• 183 with SDP, no PRACK, no further 18x, then 200 OK. Common in IMS and some carrier SBC deployments. Early media will fight with the ring-back generator. Look for whether the UAC muted its ring-back on receipt of the 183 — if not, you have a double-audio problem.
• 100 Trying with a To-tag. Non-compliant. 100 must not carry a To-tag per §8.2.6.2. Almost always a B2BUA bug. Worth a vendor ticket.
• Timer B expiry (~32s) but the UAS is clearly alive. Authoritative test: is the UAS generating any provisional at all? If not, something in the request-path is blocking message delivery (often firewall NAT helper rewriting Via headers incorrectly, or a route that was valid at INVITE time but the UAS's response crosses a different asymmetric path).

Closing the loop

SIP feels like a simple protocol until an INVITE keeps retransmitting and no two engineers on the call can agree on whose fault it is. The transaction state machine is the unambiguous referee. Learn the state names (Calling, Proceeding, Completed, Confirmed, Terminated), learn the timers (T1, T2, T4, A through K), and internalise the end-to-end-vs-hop-by-hop distinction for 2xx ACK, and most of the "mystery" failures you see in a production VoIP estate collapse into three or four named failure modes.