SIP transactions and dialogs

Verified 2026-09-15 · 16 claims · sources tier 1–2

Also known as PAI, RPID, branch parameter, z9hG4bK.

The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges 6. The branch parameter on the topmost routing header identifies the transaction and must be unique across space and time for every request a user agent sends 8.

Transaction identification and ordering

A branch identifier written by an implementation of this specification must begin with the 7 characters z9hG4bK so a server can tell it was constructed to this specification 7. The sequence header identifies and orders transactions and consists of a number and a method that must match the request 10.

WarmTransfer's reading of the sources is that a request repeated with the same branch identifier and the same sequence number is the same transaction retransmitting rather than a new request, except in the 2 cases where the protocol reuses both by design 11. Specifically, 2 requests reuse the branch and sequence number of the request they refer to by design: a cancellation must carry a single routing header matching the top one of the request being cancelled and the identical numeric part of the sequence header, and an acknowledgement of a non-2xx response must carry a routing header equal to the top one of the original request and the same sequence number with the method set to acknowledge 9.

INVITE lifecycle and retransmissions

An INVITE is not retransmitted over a reliable transport, and retransmissions cease altogether once a provisional response arrives 12. The INVITE transaction timeout is 64 times the round trip time estimate whose default is 500 milliseconds, giving 32 seconds 14.

The INVITE server transaction is destroyed as soon as it passes a 2xx final response to the transport, so retransmitting that response is the responsibility of the user agent rather than the transaction layer 13. The originating user agent must generate an acknowledgement for each 2xx it receives with the same sequence number as the INVITE and the method set to acknowledge 15.

See also

• See also SIP retransmission timers and transaction state.
• See also SIP response codes and failure interpretation.

Applicability

Across the claims in this article, the evidence covers IETF Session Initiation Protocol, verified as of 2026-09-15. The deployment model is not covered by any claim in this article.

What remains uncertain

Why an acknowledgement is absent from a capture in a given case is not covered by any claim in this article. How a dialog route set is built and how it changes which messages a capture point sees is not covered by any claim in this article. What a capture looks like when more than 1 endpoint answers a forked request is not covered by any claim in this article.

WarmTransfer. (2026, September 15). SIP transactions and dialogs. WarmTransfer. https://warmtransfer.net/knowledge/sip-transactions-dialogs

@misc{warmtransfer-sip-transactions-dialogs,
  title  = {SIP transactions and dialogs},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-transactions-dialogs},
  note   = {Verified 2026-09-15}
}