# SIP transactions dialogs and call setup

Canonical: https://warmtransfer.net/knowledge/sip-transactions-dialogs

Last verified: 2026-09-16

The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges[^10]. 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[^12].

## 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[^11]. The sequence header identifies and orders transactions and consists of a number and a method that must match the request[^14].

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[^15]. 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[^13].

## INVITE lifecycle and retransmissions

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

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[^17]. 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[^19].

## See also

- See also [SIP retransmission timers and transaction state](https://warmtransfer.net/knowledge/sip-retransmission-timers).
- See also [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes).

## Applicability

Applies to: IETF Session Initiation Protocol. Sources checked 2026-09-15.

## What remains uncertain

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

## Sources

[^1]: An agent must not generate a new offer while it has an offer outstanding in either direction, and an offer arriving after one has been sent but before its answer is the condition RFC 3264 calls glare, which the higher layer protocol has to resolve. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 4 Protocol Operation. Checked 2026-09-15.
[^2]: Cisco states that terminating service providers convey verification results in the verstat parameter of the SIP P-Asserted-Identity header, with 3 values: TN-Validation-Passed for a successful validation carrying an A, B or C attestation, TN-Validation-Failed where the caller could not be verified, and No-TN-Validation for a verification failure for other reasons such as a malformed E.164 number. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Understanding the STIR/SHAKEN standard, verstat options. Checked 2026-09-16.
[^3]: A 488 Not Acceptable Here means the request may succeed elsewhere and applies only to the resource addressed and may carry a body describing the media capabilities the responder does support. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 21, 488 Not Acceptable Here. Checked 2026-09-15.
[^4]: A SIP dialog is a peer-to-peer relationship between two user agents that persists over time, identified by a Call-ID value plus a local and remote tag, and it is used to sequence and route messages between the two agents. Source: [SIP: Session Initiation Protocol (RFC 3261)](https://www.rfc-editor.org/rfc/rfc3261), section-12. Checked 2026-09-04.
[^5]: A 1xx response is provisional and every other class is final and a final response completes the transaction. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 sections 17 and 21. Checked 2026-09-15.
[^6]: For every 2xx response the UAC receives to an INVITE, the UAC core generates a separate ACK sent directly by the transport layer rather than the transaction layer, reusing the INVITE's CSeq number but with the method changed to ACK. Source: [SIP: Session Initiation Protocol (RFC 3261)](https://www.rfc-editor.org/rfc/rfc3261), section-13.2.2.4. Checked 2026-09-04.
[^7]: Because all four retransmission timers are 0 on a reliable transport, a capture taken over TCP or TLS contains no request retransmission at all, so the absence of retransmissions in such a capture is a property of the transport and is not evidence about the network or the peer (inferred). Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 17 timer table, transport column. Checked 2026-09-15.
[^8]: Timer H sets the wait for an acknowledgement at 64 times the round trip estimate and its expiry is what ends a server transaction that never received one. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 sections 17.2.1 and appendix A. Checked 2026-09-15.
[^9]: Four timers are scoped to an unreliable transport and become 0 on a reliable one: A and E do not retransmit at all and D I J and K wait 0 seconds instead of their unreliable values. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 appendix A, the timer table. Checked 2026-09-15.
[^10]: The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 6 terminology and section 13. Checked 2026-09-15.
[^11]: A branch identifier written by an implementation of this specification must begin with the 7 characters z9hG4bK so that a server can tell it was constructed to this specification. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 8.1.1.7. Checked 2026-09-15.
[^12]: The branch parameter on the topmost routing header is the transaction identifier and must be unique across space and time for every request a user agent sends. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 8.1.1.7. Checked 2026-09-15.
[^13]: Two 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. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 sections 9.1 and 17.1.1.3. Checked 2026-09-15.
[^14]: The sequence header identifies and orders transactions and consists of a number and a method that must match the request. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 8.1.1.5. Checked 2026-09-15.
[^15]: 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 (inferred). Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 sections 8.1.1.5 8.1.1.7 and 17.1.1.2. Checked 2026-09-15.
[^16]: An INVITE is not retransmitted over a reliable transport and retransmissions cease altogether once a provisional response arrives. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 17.1.1.2. Checked 2026-09-15.
[^17]: 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. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 13.3.1.4. Checked 2026-09-15.
[^18]: The INVITE transaction timeout is 64 times the round trip time estimate whose default is 500 milliseconds giving 32 seconds. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 17.1.1.2 and the timer table in appendix A. Checked 2026-09-15.
[^19]: 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. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 13.2.2.4. Checked 2026-09-15.
[^20]: Webex Calling ignores the registration expiry value sent by the Local Gateway and enforces a value of 120 seconds, refreshing at approximately half that lifetime. Source: [Cisco Preferred Architecture for Webex Calling — Design Overview](https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf), Registration-based Local Gateway, pages 22-23. Checked 2026-09-04.
[^21]: The Dual Identity Support setting on a trunk decides whether Webex Calling may populate different values in the From and P-Asserted-Identity headers of an initial outbound INVITE; with it disabled, P-Asserted-Identity is set identical to From. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Add a registration-based trunk to a location, step 5. Checked 2026-09-15.
[^22]: RFC 7647 makes a Globally Routable User Agent URI mandatory for a notifier: a user agent accepting a REFER that creates a subscription must populate its Contact header field with one, and a user agent that might become a notifier needs to include one in the Contact of dialog-forming and target-refresh methods such as INVITE. Source: [RFC 7647 — Clarifications for the Use of REFER with RFC 6665](https://www.rfc-editor.org/rfc/rfc7647.html), RFC 7647 section 3 Use of GRUU Is Mandatory. Checked 2026-09-16.
[^23]: RFC 8217 updates RFC 3515 and RFC 3892 to require that where a SIP header field grammar allows a choice between the name-addr and addr-spec forms, the addr-spec form must not be used if its value would contain a comma, a semicolon or a question mark, and that any URI parameters are contained within angle brackets. Source: [RFC 8217 — Clarifications for When to Use the name-addr Production in SIP Messages](https://www.rfc-editor.org/rfc/rfc8217.html), RFC 8217 sections 3 and 4. Checked 2026-09-16.