SIP Dialogs and Transactions — Understanding State

Why State Management Matters

SIP is fundamentally a stateful protocol, but its state is distributed across multiple entities. Unlike the PSTN where a central switch owns the call state, SIP distributes state between endpoints and intermediaries. When this state gets out of sync — when one side thinks a call exists but the other doesn't — you get ghost calls, hung sessions, and billing errors. Understanding transactions and dialogs is the key to preventing and diagnosing these problems.

Transactions: The Atomic Unit

A transaction is a single request-response exchange. It's the smallest unit of SIP interaction. Every SIP request creates a transaction that lives until a final response (2xx-6xx) is received.

Transaction Identification

A transaction is uniquely identified by:

The Via branch parameter (a unique token the client generates)
The CSeq method (because a CANCEL and its INVITE share a Via branch but are separate transactions)

When a response arrives, the transaction layer matches it to the original request using these identifiers. If no match is found, the response is dropped — this is a common source of "response not processed" bugs when SIP ALGs or intermediaries rewrite Via headers incorrectly.

Client vs. Server Transactions

The entity that sends the request runs a client transaction. The entity that receives and responds runs a server transaction. A proxy runs both — a server transaction for the incoming request and a client transaction for the forwarded request.

INVITE vs. Non-INVITE Transactions

SIP has two types of transactions with fundamentally different state machines:

Non-INVITE transactions (REGISTER, BYE, OPTIONS, etc.) are simple:

Request → Final Response. Done.
Timer F = 32 seconds. If no response, transaction fails with 408.

INVITE transactions are complex because calls take time to set up:

INVITE → Provisional (1xx) → Final Response → ACK
Timer B = 32 seconds for the initial response
The ACK is part of the INVITE transaction for error responses (4xx-6xx) but forms a separate transaction for 2xx (success)

This asymmetry is one of the most confusing aspects of SIP. Why? Because a 2xx to an INVITE can be retransmitted by the UAS (it's critical — it means "answer the call"), and the ACK must be generated by the UAC, not the transaction layer. For error responses, the transaction layer handles ACK automatically.

🔒 Full Course Content Available

This is a preview of the Telephony Mastery Course. The complete lesson includes:

✅ Detailed technical explanations
✅ Advanced configuration examples
✅ Hands-on lab exercises
✅ Real-world troubleshooting scenarios
✅ Practice quizzes and assessments

🚀 Unlock Full Course Access

Preview shows approximately 25% of the full lesson content.