ACK is the most misunderstood method in SIP. It looks like a normal request but follows different routing rules, never gets a response of its own, and is part of the INVITE transaction in some cases but not others. Understanding ACK is essential for diagnosing call setup failures, ghost dialogs, and retransmission storms.
SIP ACK acknowledges a final response to an INVITE. Without ACK, the original INVITE transaction does not complete, and the responder will keep retransmitting its final response until a timer expires.
ACK is the third leg of what is loosely called the SIP three-way handshake:
Unlike TCP's three-way handshake, SIP's ACK serves a slightly different purpose. It acknowledges the response, but the dialog is established with the 2xx, not with the ACK. The ACK is required for transaction completion but is not what creates the call.
SIP defines two distinct kinds of ACK with different routing and retransmission behavior:
Sent end-to-end from the caller's UA directly to the callee's UA, bypassing intermediate proxies (except those in the Route set). It is part of a new transaction, not the INVITE transaction. The caller's UA must keep retransmitting ACK if the 2xx is retransmitted, but the ACK never gets a response itself.
Sent hop-by-hop, processed by every intermediate proxy. It is part of the same INVITE transaction. Stops INVITE retransmission and confirms transaction completion. After this ACK, the transaction is closed and any further messages need to be a new transaction.
This dual behavior is one of the more confusing parts of RFC 3261. The same method name does very different things depending on the response code being acknowledged.
The routing rules for the two ACK types diverge:
The Route header in the ACK is built from the Record-Route headers in the 200 OK response, in reverse order. This sends the ACK through the same proxy path the response took (in reverse). The Request-URI is set to the Contact in the 200 OK.
If proxies in the path did not Record-Route, the ACK goes directly from caller to callee. This is why some SIP networks rely on Record-Route everywhere — without it, ACK can fail to reach the callee through firewalls or NAT that only opened on the inbound INVITE path.
The ACK is sent to the same destination as the original INVITE. Each proxy in the path receives and forwards it. The transaction state at each proxy is closed when the ACK is processed.
Mixing these up is a common source of failure. ACK to 200 OK that is routed hop-by-hop hits proxies that don't expect it. ACK to 4xx that is routed end-to-end skips proxies that need to update their state.
The consequences of a missing ACK depend on which type was missed:
The callee retransmits 200 OK at increasing intervals (T1, 2T1, 4T1, ...) up to T2 (4 seconds default). If the caller's ACK never arrives within Timer H (64 * T1, default 32 seconds), the callee considers the dialog broken and sends BYE.
The user experience: the callee answered, expects audio, but heard silence and then the call dropped after 30 seconds. From the caller's side, the call was successful but unexpectedly ended. This is the classic 30-second call drop pattern.
The proxy retransmits the final response until Timer H expires. The proxy keeps INVITE transaction state alive longer than expected, consuming memory. Eventually the transaction is cleared, but during that window, retransmissions add load.
Other SIP methods (REGISTER, OPTIONS, MESSAGE, SUBSCRIBE, etc.) do not have ACK. The reason is timing:
INVITE responses, especially 2xx, can arrive after a long delay (seconds while the user picks up the phone). The transaction layer cannot keep retransmitting INVITE indefinitely waiting for a response. ACK closes the gap: the responder retransmits the response (which is small) at increasing intervals, the requester acknowledges with ACK, and the transaction completes.
Other methods get fast responses (typically under a second). The standard transaction retransmission rules (T1=500ms, doubling, capped at T2) handle reliability without needing a separate ACK. The response itself is the acknowledgment.
This is also why CANCEL, although it is a separate transaction, does not get an ACK either. CANCEL is fast; the response (200 OK to CANCEL or 481 if too late) is enough.
Most ACK issues show up as retransmissions of 200 OK or 4xx final responses. The signal:
The SIP three-way handshake refers to the INVITE, response, ACK exchange that establishes a call. The caller sends INVITE, the callee responds with a final response (typically 200 OK for success), and the caller sends ACK to confirm receipt. Unlike TCP's three-way handshake, the dialog is created by the 2xx response, not by the ACK — but the ACK is required for the transaction to complete.
ACK to 2xx is end-to-end — it goes directly from caller to callee bypassing proxies that did not Record-Route. It is part of a new transaction, not the INVITE transaction. ACK to non-2xx (3xx, 4xx, 5xx, 6xx) is hop-by-hop — every proxy processes it. It is part of the same INVITE transaction. The dual behavior reflects different needs: 2xx ACK confirms the dialog is established, while failure ACK closes a failed transaction at every hop.
If ACK to a 2xx response is missing, the callee retransmits 200 OK at increasing intervals until Timer H (32 seconds) expires, then sends BYE. The user experiences this as a call that connects, has no audio, and drops at exactly 30 seconds. If ACK to a non-2xx response is missing, the proxy keeps retransmitting the response until Timer H expires, increasing load but not affecting user experience as much.
Paste your SIP trace into SIPSymposium. The analyzer detects missing ACK patterns, ACK routing issues, and Record-Route mismatches that cause silent call drops.