A SIP dialog is the peer-to-peer relationship between two user agents that exists for some time and is identified by Call-ID, From-tag, and To-tag. RFC 3261 defines three dialog states — early, confirmed, and terminated. Understanding which state a dialog is in is essential for diagnosing complex SIP issues.
A SIP dialog is the persistent context of a SIP session between two user agents. It is identified by three values that, together, uniquely identify the dialog:
Until the To-tag exists, the dialog cannot be fully identified by both sides. The originating UA knows the Call-ID and From-tag from the start; the To-tag is added when the responder generates it (usually in the first response with a To-tag, which is normally a 1xx response with that tag or the 2xx response).
The dialog carries state across multiple SIP transactions — INVITE, re-INVITE, OPTIONS, INFO, NOTIFY, BYE all happen within a dialog once it is established. Without dialog state, each transaction would have to negotiate the relationship from scratch.
An early dialog is created when the UAS sends a 1xx provisional response with a To-tag (typically 180 Ringing or 183 Session Progress with a tag). The dialog now has all three identifiers (Call-ID, From-tag, To-tag) but is not yet confirmed.
What you can do in an early dialog:
What you cannot do in an early dialog:
Forking creates an interesting case: a single INVITE can produce multiple early dialogs, one per branch. Each has the same Call-ID and From-tag but different To-tags. When one branch wins (sends 200 OK), its early dialog confirms; the others are canceled.
A dialog confirms when a 2xx response is received and acknowledged. For an INVITE dialog, this means 200 OK followed by ACK. The dialog is now stable and can carry mid-dialog requests.
What you can do in a confirmed dialog:
The CSeq number must increment monotonically across all in-dialog requests from the same side. If both sides send requests, each side maintains its own CSeq sequence.
Route Sets are established at confirmation. The set of proxies through which the dialog is being routed (from Record-Route headers in the 200 OK) becomes the Route header for all subsequent in-dialog requests. This ensures continuity through the same proxy path.
A dialog terminates in one of several ways:
Once terminated, the dialog identifiers (Call-ID, From-tag, To-tag triplet) cannot be reused. Any later request matching that triplet should be rejected with 481 Call/Transaction Does Not Exist.
If the caller sends CANCEL at almost the same instant as the callee sends 200 OK, the dialog state depends on which is processed first. If 200 OK arrives first, the dialog confirms; the CANCEL is too late and gets 481. The caller, having sent CANCEL, must now ACK the 200 OK and immediately send BYE.
If reliable provisional responses are required (Require: 100rel), the early dialog requires PRACK acknowledgment before subsequent provisional or final responses. Missing or rejected PRACK can leave the dialog in an indeterminate state.
UPDATE works in both early and confirmed dialogs. It is the recommended way to renegotiate session parameters before answer (where re-INVITE is not allowed). After answer, both UPDATE and re-INVITE are valid, with re-INVITE being more widely supported.
When forking produces a winner, the proxy CANCELs other branches. Each canceled branch's early dialog terminates. The winning branch's dialog confirms. The proxy must track which dialogs are which through their To-tags.
Reading dialog state from a SIP trace is straightforward once you know what to look for:
A SIP dialog is the persistent context of a SIP session between two user agents, identified by Call-ID, From-tag, and To-tag. It carries state across multiple SIP transactions (INVITE, re-INVITE, BYE, INFO, etc). RFC 3261 defines three dialog states: early (after a 1xx with To-tag), confirmed (after 2xx and ACK), and terminated (after BYE, failure response, or CANCEL/487).
An early dialog is created when the UAS sends a 1xx provisional response with a To-tag. It supports CANCEL, PRACK, UPDATE, and early media but cannot carry re-INVITE or BYE. A confirmed dialog requires a 2xx response and ACK. Once confirmed, re-INVITE, INFO, NOTIFY, REFER, and BYE all become valid mid-dialog requests.
Look for the From-tag and To-tag pair. If neither is present, no dialog yet. If From-tag only, the request is in flight but no dialog created. If both tags present and the latest message is a 1xx, the dialog is early. If the latest exchange includes a 2xx and ACK, the dialog is confirmed. If a BYE has been sent and acknowledged, the dialog is terminated.
Paste your SIP trace into SIPSymposium. The analyzer tracks dialog state transitions, identifies forking, and shows the exact messages that move dialogs between early, confirmed, and terminated states.