What SIP Actually Is (and What It Isn't)

SIP Signaling From the Wire Up: Part 1 of 12

If you work with VoIP systems in any capacity, you've heard the term SIP. It shows up in configuration screens, in error messages, in conversations with providers, and in the names of products. SIP trunks. SIP phones. SIP credentials. The term is everywhere, but what SIP actually does, and more importantly what it doesn't do, is something a surprising number of people who work with voice systems every day couldn't explain clearly.

That's not a criticism. SIP is one of those technologies that works well enough most of the time that you can configure phones and trunks without ever understanding what's happening underneath. But when something goes wrong, and it will, understanding SIP is the difference between staring at a problem helplessly and knowing exactly where to look.

This series is going to take you from "I know SIP has something to do with phone calls" to "I can read a packet capture and figure out why this call isn't working." We'll go step by step, starting here with the basics, and by the end of the series you'll be reading raw SIP messages and diagnosing real problems.

SIP is only the signaling

Here's the most important thing to understand about SIP, and the thing that clears up the most confusion: SIP does not carry voice. Not even a little bit. SIP's job is signaling. It handles the setup, modification, and teardown of communication sessions. Think of it like the host at a restaurant. The host greets you, finds you a table, and seats you. The host does not cook your food. That's someone else's job.

In VoIP, the "cooking" is done by RTP, which stands for Real-time Transport Protocol. RTP is the protocol that actually carries the voice audio between the two parties on a call. RTP runs on completely different ports than SIP, uses a completely different message format, and operates independently once the call is established.

This distinction is not just academic. It's the key to understanding a huge category of VoIP problems. When someone says "the call connected but there's no audio," what they're describing is a situation where SIP did its job perfectly (the session was established, both phones agreed to the call) but RTP failed (the audio packets aren't flowing). These are two separate systems, and they can succeed or fail independently.

A call connects but nobody can hear anything? That's an RTP problem, probably a NAT or firewall issue preventing the audio packets from reaching their destination. The SIP side worked fine.

A call never rings at all? That's a SIP problem. The signaling never reached the destination, or it was rejected somewhere along the way. RTP never even gets a chance to start because SIP didn't set up the session.

Understanding which protocol is responsible for which part of the call is the foundation everything else in this series builds on.

Where SIP came from

SIP was designed in the mid 1990s by the Internet Engineering Task Force, the same group responsible for most of the core internet protocols. It was formally specified in RFC 2543 in 1999 and significantly revised in RFC 3261 in 2002, which is the version that essentially defines modern SIP.

The designers of SIP made a deliberate choice to model it after HTTP, the protocol that powers the web. This wasn't an accident. HTTP had proven that a simple, text based request/response protocol could scale to enormous adoption. The SIP designers wanted the same characteristics: human readable messages, a familiar request/response pattern, and extensibility through headers.

This design decision has real practical consequences. Because SIP messages are plain text, you can read them. Open a packet capture of SIP traffic and you'll see actual words, not binary data that needs specialized decoding. You'll see "INVITE" when someone is placing a call. You'll see "200 OK" when the other end answers. You'll see phone numbers, IP addresses, and header names that mostly describe what they contain. This readability is what makes SIP troubleshooting possible without expensive proprietary tools.

The HTTP influence also shows up in the way SIP handles responses. SIP uses the same numeric response code scheme as HTTP. A 200 response means success, just like on the web. A 404 means the address wasn't found. A 500 means something broke on the server. If you've ever seen an HTTP status code, you already have a rough mental model for SIP responses. Our SIP response code reference covers every code you'll encounter in practice and what each one means for troubleshooting.

SIP's role in a call

When you pick up a VoIP phone and dial a number, here's what SIP is responsible for:

Finding the destination. SIP takes the number you dialed and figures out where to send the call. This might involve querying a registrar to find out where a particular extension is currently located, or routing the call through a proxy server that knows how to reach the outside world.

Negotiating the terms. Before any audio flows, the two endpoints need to agree on how they're going to communicate. What audio codec will they use? What IP addresses and ports will they send audio to? This negotiation happens through SDP (Session Description Protocol), which travels inside SIP messages. We'll cover SDP in detail in post 5.

Establishing the session. SIP manages the handshake that both parties agree to. The caller says "I want to talk." The callee says "OK, I accept." SIP carries these messages back and forth.

Modifying the session if needed. If someone presses the hold button, or if the call needs to be transferred to another party, SIP handles those changes to the session while it's in progress.

Tearing down the session. When someone hangs up, SIP carries the "goodbye" message and ensures both sides know the call is over.

That's it. Everything else, the actual voice audio, is handled by RTP. Once SIP has set up the session and the two sides know where to send audio, SIP's job is largely done until something needs to change or the call ends.

The key players

SIP involves several types of entities, and understanding their roles helps make sense of how calls flow through a network.

A User Agent (UA) is anything that sends or receives SIP messages on behalf of a user. Your desk phone is a user agent. A softphone application on your computer is a user agent. The user agent that initiates a call is called the User Agent Client (UAC), and the one that receives it is the User Agent Server (UAS). These roles can switch during a single call: the phone that initiated the call becomes the UAS when the other end sends a request to it.

A Proxy Server is an intermediary that routes SIP messages between user agents. When your phone sends an INVITE, it usually doesn't send it directly to the other phone. It sends it to a proxy, which figures out where the call should go and forwards it. Proxies can chain together, with each one forwarding the message to the next hop. Your PBX (whether it's in your office or in the cloud) acts as a SIP proxy, among other things.

A Registrar is a server that handles registration. When your phone boots up and says "I'm extension 101, and you can reach me at this IP address," the registrar records that information. When someone calls extension 101, the system consults the registrar to find out where to send the call. In practice, the registrar function is usually built into the same server as the proxy.

A Session Border Controller (SBC) sits at the edge of a network and manages SIP traffic crossing network boundaries. SBCs handle security, NAT traversal, codec translation, and a bunch of other functions that we'll get into later in the series. Most SIP trunk providers put an SBC between their network and yours.

Your first look at a SIP message

We'll tear apart SIP messages in detail starting in the next post, but here's a preview of what you'll be learning to read. This is an actual SIP INVITE, the message that initiates a call:

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.50
s=Phone Call
c=IN IP4 192.168.1.50
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 opus/48000/2

Right now, that probably looks like a wall of somewhat cryptic text. By the end of the next post, you'll be able to read every line of it and know exactly what it's doing. By the end of this series, you'll be able to look at a sequence of these messages and diagnose why a call is failing.

That's where we're headed. Let's start taking it apart.

Next up: Anatomy of a SIP Message: Reading the Headers, where we take a single SIP message and walk through it line by line.