Fundamentals
What Is SIP? The Protocol Under Every Call
SIP — the Session Initiation Protocol, defined by RFC 3261 — is the text-based protocol that sets up, manages and tears down most of the world's VoIP calls. It does not carry voice (that is RTP's job); it is the conversation about the conversation: invitations, answers, transfers, registrations and goodbyes, written in a human-readable format deliberately modeled on HTTP.
You do not need to memorize SIP to fix phones. But a working mental model of its requests, responses and dialogs turns captures from noise into narrative — which is why every serious VoIP engineer reads SIP the way mechanics read engine notes.
The vocabulary: methods, responses, headers
SIP messages are either requests (methods) or responses (numbered codes). The working set of methods is small:
| Method | Purpose |
|---|---|
| REGISTER | 'I am extension 204, currently reachable at this address' — renewed periodically |
| INVITE | Start a session (a call) — carries the SDP media offer |
| ACK | Confirm the final answer to an INVITE; completes the three-way handshake |
| BYE | End an established session |
| CANCEL | Abandon an INVITE that hasn't been answered yet (you hung up while it rang) |
| OPTIONS | Capability/heartbeat probe — 'are you there, what do you support?' |
| REFER / NOTIFY / SUBSCRIBE | Transfers and presence/event machinery |
| UPDATE / re-INVITE | Modify a session in progress — including the session-timer refresh |
Transactions and dialogs: SIP's two containers
A transaction is one request and its responses (with retransmissions on UDP making sure they arrive — timers A–K govern this machinery, including the ~32-second retry envelope behind 408s). A dialog is the whole relationship created by a successful INVITE: identified by the Call-ID plus the From/To tags, sequenced by CSeq numbers, and routed by the Route/Record-Route headers. Dialogs explain otherwise puzzling behavior: why a mid-call request must follow a specific path, why a BYE references identifiers from an hour ago, and why session refresh (re-INVITE inside the dialog) failing kills a healthy-sounding call. Headers do the administrative work: Via traces the path, Contact states where to reach the sender, Max-Forwards limits loops, and the SDP body (technically separate, carried inside) negotiates the media.
How to start reading SIP today
- Open any capture and find one complete call; list its messages in order and name each method/response aloud — fluency starts with twenty calls.
- For every failed call you meet, write down three fields before reading further: the method, the final response code, and who sent it. That trio is 80% of triage.
- Learn the response classes (1xx–6xx) as families first; individual codes (this site's code library) attach to families you already understand.
- Read one ladder diagram a day from real traffic (yours or the examples in the ladder guide) until the INVITE→180→200→ACK→BYE rhythm is automatic.
Frequently asked questions
- Is SIP a voice codec or a transport?
- Neither: SIP is signaling. It rides over UDP, TCP or TLS transports and negotiates the media (codecs, addresses) that a separate protocol (RTP) then carries. Confusing these three layers is the root of many misdiagnoses.
- Why is SIP text-based instead of binary?
- By design inheritance from HTTP/SMTP: human-readable protocols are debuggable with generic tools, extensible with new headers, and teachable — which is why a Wireshark capture of a call is legible to you right now.
- SIP vs H.323 vs proprietary protocols?
- H.323 is the older ITU family, now largely legacy; proprietary protocols survive inside some vendors' endpoints. SIP won the industry through openness and the web's architectural style — nearly all modern trunks, carriers and platforms speak it.