SIP protocol explained: what it is, how it works

SIP, the Session Initiation Protocol, is how phone calls get set up on the internet. When one device wants to call another, SIP carries the negotiation: who is calling, where the other side can be reached, which audio codecs both support, and when someone hangs up. The voice itself never travels over SIP. Once the two sides agree, the audio flows as a separate stream, almost always RTP.

That split is the one thing to take from this guide: SIP is the conversation about the call, not the call. Everything else, the methods, the response codes, the ports, follows from it. The guide covers how a SIP call works message by message, what the vocabulary means, and the places SIP shows up when the thing answering your calls is an AI voice agent.

What SIP is, and what it is not

SIP is an application-layer signaling protocol defined by the IETF. It first appeared as RFC 2543 in 1999 and was revised as RFC 3261 in 2002, which is still the standard every SIP phone, PBX, and carrier implements. Its designers borrowed the request-response model and text syntax of HTTP, so a SIP message is something you can read in a packet capture without special tooling.

Three things SIP is not:

• Not the audio. SIP negotiates the session, then steps aside. Voice and video travel as RTP packets, described below.
• Not a service. Nobody sells you “SIP.” What carriers sell is SIP trunking: a service that uses the SIP protocol to connect your phone system to the public phone network.
• Not the only way to signal a call. H.323 predates it, WebRTC handles calls inside browsers, and proprietary protocols run inside closed apps. SIP won the business telephony world because it is open, text-based, and simple enough that every vendor could implement it.

How a SIP call works

A SIP call is a short exchange of text requests and numbered responses. Here is a typical inbound call, from ringing to hangup:

1. INVITE. The caller’s side sends an INVITE to the callee’s address. Its body carries an SDP (Session Description Protocol) block listing the caller’s IP, the port where it wants audio, and the codecs it supports.
2. 100 Trying. Proxies along the path acknowledge receipt, so the caller stops retransmitting.
3. 180 Ringing. The called device is alerting its user. This is when the caller hears ringback tone.
4. 200 OK. The called party answers. The response carries its own SDP block, completing the codec negotiation.
5. ACK. The caller confirms the final response. The session is now established, and RTP audio starts flowing in both directions.
6. BYE. Whoever hangs up sends a BYE. The other side replies 200 OK, and the session ends.

Mid-call, either side can send a new INVITE, called a re-INVITE, to change the session: put it on hold, add video, or switch codecs. A REFER request asks the other side to call somewhere else, which is how transfers work.

Here is what an INVITE actually looks like on the wire, lightly trimmed:

INVITE sip:+14155550132@sip.example.com SIP/2.0
Via: SIP/2.0/TLS client.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
To: <sip:+14155550132@sip.example.com>
Call-ID: 3848276298220188511@client.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.example.com;transport=tls>
Content-Type: application/sdp
Content-Length: 213

v=0
o=alice 2890844526 2890844526 IN IP4 client.example.com
s=-
c=IN IP4 client.example.com
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

The last three lines of the SDP offer are the codecs on the table: payload 0 is G.711 μ-law, payload 8 is G.711 A-law, and payload 101 is telephone-event, the out-of-band way to send DTMF keypresses inside the audio stream. A phone call over the public network will usually settle on one of the two G.711 variants, which is why phone audio sounds the way it does.

SIP methods worth knowing

SIP requests are named methods. These are the ones you will meet in a capture:

Every request gets responses with three-digit codes, grouped by first digit:

Two of these earn their keep during setup. A 401 or 407 is not a failure; it is an authentication challenge, and the sender is expected to retry with digest credentials. A 488 Not Acceptable Here means the two sides share no codec, which is the polite way a call says you never agreed on how to encode the audio.

Addresses, registration, and the boxes in between

SIP addresses look like email addresses: sip:alice@example.com, optionally with a port or transport, as in sip:alice@example.com:5061;transport=tls. A phone number becomes a SIP URI by attaching the carrier’s domain, which is why sip:+14155550132@sip.example.com is a complete dialable address.

Because devices move and sit behind NAT, a SIP phone tells the network where it is: it sends a REGISTER to its registrar, which records “alice@example.com is currently at this IP.” When an INVITE for Alice arrives, a proxy server looks up that record and forwards the request to wherever Alice actually is. In front of most real deployments sits a session border controller (SBC), a bouncer for SIP traffic that terminates signaling, hides the internal network, enforces security policy, and normalizes the odd things different vendors’ SIP stacks do.

SIP vs RTP vs SDP

Three protocols divide the work of every SIP call:

This is why a call can ring perfectly and deliver silence. The SIP half worked, so both phones agree a call exists, but the RTP half is broken, usually by a firewall or NAT that lets signaling through and drops media. When you debug a call with no audio, look at the media path, not the signaling. The same separation is what makes jitter an RTP problem: the sequence and timestamp fields on every RTP packet, defined by RFC 3550, are exactly what a receiver measures to compute it.

SIP vs VoIP vs SIP trunking

The three terms get used interchangeably, and they are not the same:

If VoIP is the idea of calling over the internet, SIP is the grammar the two ends speak, and a SIP trunk is the subscription that gets your call onto the public phone network. The SIP trunking guide covers the service side: providers, channels, and setup.

Transports, ports, and encryption

SIP signaling runs over UDP or TCP on port 5060, or over TLS on port 5061. UDP is the traditional default and avoids head-of-line blocking, but large messages fragment, so TCP is common for anything sizable. TLS encrypts the signaling and authenticates the far end, and it is what carriers expect for anything production.

Plain SIP encrypts nothing: anyone on the path can read the signaling, and the media rides unencrypted RTP. The standard fix is TLS for signaling plus SRTP, defined by RFC 3711, for media. Both ends have to agree, because enabling encryption on one side only is a reliable way to produce calls that connect and carry no audio.

One warning that has survived every decade of SIP: do not expose an open SIP endpoint. Scanners sweep the internet for port 5060 within minutes of it appearing, looking for trunks that will place free calls. Authenticate senders with digest credentials, allowlist your carrier’s signaling IPs, or both.

Where SIP meets a voice agent

If you put an AI voice agent on the phone network, SIP is the protocol doing the work at both edges of the call: the carrier delivers inbound calls to the agent platform as SIP INVITEs, and the platform sends outbound calls and transfers back the same way. A few protocol details stop being trivia the moment you own that stack:

• Transfers are REFERs. When the agent hands a caller to a person, the platform sends a SIP REFER asking the carrier to ring a new destination. A plain REFER is a cold transfer; making it warm, where the human hears the context first, is the agent’s job before the REFER goes out.
• Keypresses have three transports. DTMF digits can ride in-band as audio, out-of-band as RFC 4733 telephone-events (the payload 101 in the INVITE above), or inside SIP INFO messages. A mismatch between what the phone sends and what the agent listens for is why “press 1” menus silently eat digits.
• The media is 8 kHz. Phone calls negotiate G.711, so the agent’s speech recognition sees narrowband audio whether it likes it or not. Test on real phone audio before tuning anything else; the G.711 guide covers what the codec cuts.
• Browser calls are a different world. WebRTC has its own signaling-agnostic model, mandatory encryption, and adaptive jitter buffers. The WebRTC vs WebSocket guide maps the differences for voice agents that live in a browser instead of on the phone network.

On Cartesia, Managed Agents accept calls from your own SIP trunk over TCP or TLS, with SRTP media encryption set to disabled, allowed, or required, and authenticate inbound calls with digest credentials or an IP allowlist. Transfers go out as SIP REFERs to phone numbers or SIP URIs. The SIP trunking integration walks through pointing a carrier at Cartesia’s SIP endpoint, and the SIP trunking guide covers the setup in full, including the API fields and the failure table.

Related guides

• What is SIP trunking?
• G.711 codec: μ-law, A-law, and 8 kHz phone audio
• What is DTMF? Tones, frequencies, and voice AI
• What is jitter in VoIP? How to measure and fix it
• WebRTC vs WebSocket for real-time voice AI
• What is a warm transfer? Warm vs cold transfer