VoIP.info Reference

SIP ACK: why answering is not the end of call setup

Distinguish ACK handling for successful and failed INVITEs and diagnose repeated final responses.

Reviewed 2026-09-07SIP standards; extension support depends on both peersIntermediateDocumentation based · not lab tested

Two ACK cases

ACK completes the INVITE exchange, but its handling depends on the final response. For a non-2xx final response, ACK belongs to the INVITE transaction machinery. For a 2xx response, the user agent generates an end-to-end ACK with routing determined by the established dialog. That distinction matters when a proxy path and a Contact address differ. The numeric CSeq value matches the INVITE being acknowledged; its method becomes ACK. Do not treat ACK as a new ordinary transaction that should receive its own 200 OK.

Cancel an attempt or end an answered call
A pending INVITE can be canceled, producing a 487 response and ACK. An answered INVITE receives ACK before BYE ends the established call. A racing answer follows the answered path.

Simplified caller-side decision. The CANCEL and BYE requests also receive their own responses; a successful answer racing with cancellation still needs ACK and dialog cleanup.

Diagnosing repeated 200 OK responses

A callee can keep retransmitting its successful INVITE response when it does not receive ACK. Look for the original INVITE, each final response and the corresponding ACK on both sides of the border. Compare Contact, Record-Route, Route and the actual destination address. A packet visible leaving the caller does not establish that the callee received it. A private Contact address or an incorrect route set can send ACK somewhere different from the INVITE. A B2BUA introduces independent call legs, so matching only a single Call-ID across the whole system can mislead the investigation.

Forks and delayed offers

Forking can produce multiple successful responses with different To tags. These create distinct dialogs requiring correct acknowledgment and cleanup; they are not necessarily duplicate packets. When an INVITE has no SDP offer, a successful response can carry the offer and ACK the answer. Use offer/answer to interpret that media negotiation. For a call that connects and then drops, first establish whether ACK reached the answering endpoint, then investigate session timers and media inactivity separately.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.