The ACK for a non-2xx is hop by hop inside the INVITE transaction, and the ACK for a 2xx is a new end-to-end transaction.
A final response from 300 through 699 is acknowledged by the INVITE client transaction. That ACK uses the INVITE's branch, the INVITE's CSeq number, and the method token ACK. Each hop generates its own ACK. A proxy does not forward the caller's ACK downstream.
The ladder below is that case. The proxy ACKs the peer with branch z9hG4bKproxy01, the same branch it put on the forwarded INVITE. The caller ACKs the proxy with branch z9hG4bKalice01. Neither ACK is a new transaction.
The ACK for a 200 OK is sent by the UAC using the dialog route set and the remote target. It carries a new branch because it is a different transaction. The CSeq number still matches the INVITE. Proxies that record-routed forward this ACK as they would any other mid-dialog request.
RFC 3261's overview describes INVITE as a three-way handshake, and that sentence is too small for the 2xx case. RFC 6026 corrects the state machine so a late 2xx is absorbed by the transaction, while the ACK remains the UAC's end-to-end request. The UAS retransmits the 200 OK until that ACK arrives.
Room: Two different ACK rules
© 2026 CypherMonkeyLabs 🐒