Skip to content
SIP Mastery

Part 0 · Orientation / Module 00

Anatomy of one phone call

Watch one complete SIP call, from the moment Alice's phone starts to the moment Bob hangs up. Every later module zooms into one part of this call.

BasicNOC coreDEV coredraft

After this module, you can

  • Name the elements of a SIP call — user agents, a registrar, and proxies — and say what each one does.
  • Tell signaling from media, and name the protocol that carries each.
  • Follow one call from registration to hang-up, in seven chapters.
  • Read the diagrams in this course — colours, shapes, and controls.

0.1 One call in seven chapters

This course follows one small cast through every module. Meet them first.

Who What it is Where
Alice A user agentuser agent. An endpoint that sends and receives SIP, such as a phone, a softphone, or a gateway.: the phone that makes the call sip:alice@atlanta.example
Registrar The server that remembers where each user of atlanta.example is atlanta.example
Proxy A The server that handles calls for atlanta.example atlanta.example
Proxy B The server that handles calls for biloxi.example biloxi.example
Bob The phone that receives the call sip:bob@biloxi.example

Now watch the whole call. Press ▶ to play it, or step through it with ← and →. The chapters at the top jump to each part of the call. Under the player, each chapter links to the module that explains it in detail.

The whole call

One phone call, from registration to hang-up

  • SIP signaling
  • RTP media
atlanta.examplebiloxi.exampleREGISTERAlice192.0.2.10● RegisteringRegistraratlanta.exampleProxy A198.51.100.10Proxy B203.0.113.10Bob203.0.113.20
01/28

REGISTER · Alice → Registrar

Alice's phone starts. It tells the Registrar the address where Alice is now.

Learn this part in
All steps as text
  1. Alice → Registrar: REGISTER. Alice's phone starts. It tells the Registrar the address where Alice is now.
  2. Registrar → Alice: 401 Unauthorized. The Registrar asks the phone to prove that it knows Alice's password.
  3. Alice → Registrar: REGISTER (credentials). The phone sends REGISTER again with proof of the password. The password itself never travels.
  4. Registrar → Alice: 200 OK. The Registrar stores Alice's current address. Alice can now receive calls.
  5. Alice → Proxy A: INVITE. Alice dials Bob. The phone sends an INVITE to Proxy A, the server for atlanta.example.
  6. Proxy A → Alice: 407 Proxy Auth Required. Proxy A asks for proof of identity before it connects the call.
  7. Alice → Proxy A: ACK. The phone confirms that it received the 407.
  8. Alice → Proxy A: INVITE (credentials). The phone sends the INVITE again, now with credentials.
  9. Proxy A → Alice: 100 Trying. Proxy A accepts the credentials. It answers 100 Trying, which means "I am working on it".
  10. Proxy A → Proxy B: INVITE. Proxy A forwards the INVITE to Proxy B, the server for biloxi.example.
  11. Proxy B → Proxy A: 100 Trying. Proxy B also answers 100 Trying.
  12. Proxy B → Bob: INVITE. Proxy B knows where Bob's phone is, because the phone registered earlier. It forwards the INVITE.
  13. Bob → Proxy B: 180 Ringing. Bob's phone rings and answers 180 Ringing.
  14. Proxy B → Proxy A: 180 Ringing. The proxies pass the 180 back toward Alice.
  15. Proxy A → Alice: 180 Ringing. Alice hears the ringback tone.
  16. Bob → Proxy B: 200 OK. Bob answers. The 200 OK describes the media that Bob's phone can receive.
  17. Proxy B → Proxy A: 200 OK. The 200 OK travels back along the same path.
  18. Proxy A → Alice: 200 OK. Alice's phone now knows where to send audio, and what format to use.
  19. Alice → Proxy A: ACK. The phone confirms the 200 OK with an ACK. The call setup is complete.
  20. Proxy A → Proxy B: ACK. Both proxies asked to stay in the path, so the ACK goes through them.
  21. Proxy B → Bob: ACK. Bob's phone receives the ACK.
  22. Alice → Bob: RTP audio. Alice and Bob talk. Audio travels directly between the phones as RTP, not through the proxies.
  23. Bob → Proxy B: BYE. Bob hangs up. Bob's phone sends BYE through the same proxies.
  24. Proxy B → Proxy A: BYE. Proxy B forwards the BYE to Proxy A.
  25. Proxy A → Alice: BYE. Alice's phone receives the BYE and stops the audio.
  26. Alice → Proxy A: 200 OK. Alice's phone confirms with 200 OK. For Alice, the call is over.
  27. Proxy A → Proxy B: 200 OK. Each proxy removes its own Via and passes the 200 OK on.
  28. Proxy B → Bob: 200 OK. Bob's phone receives the 200 OK. Both phones are idle again.

You do not need to understand every message yet. Look for the pattern:

  1. Register. Alice’s phone tells the RegistrarRegistrar. The server that accepts REGISTER requests for a domain and stores the bindings in its location service. In most examples it serves atlanta.example; in Module 12, biloxi.example. where Alice is. Without this, nobody can find Alice.
  2. Prove identity. Proxy A will not connect a call for a stranger. Alice’s phone proves that it knows the password — without sending it.
  3. Find Bob. Proxy A passes the call to Proxy B, and Proxy B finds Bob’s phone.
  4. Ring and answer. Bob’s phone rings (180 Ringing), then Bob answers (200 OK). The answer also says how Bob’s phone wants to receive audio.
  5. Confirm. Alice’s phone confirms the answer with an ACK. Now the call is set up.
  6. Talk. The audio flows — and it takes a different path from all the messages before it.
  7. Hang up. Bob’s phone sends BYE. Alice’s phone confirms with 200 OK. Both phones are idle again.

This shape — two phones, two proxies — is so common that RFC 3261 gives it a name: the SIP trapezoid. The RFC’s own first example in §4 is this same call between Alice and Bob.

RFC 3261 §4 · Overview of Operation
“SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response.”
Read the section ↗

0.2 Two paths: signaling and media

A phone call needs two different things:

  • Signalingsignaling. The messages that set up, change, and end a call. In SIP calls, signaling is SIP.: messages that find the other person, ring the phone, and end the call. In this course, signaling is SIP.
  • Mediamedia. The audio or video itself. In SIP calls, media travels as RTP, on a different path from signaling.: the voice itself. In this course, media is RTP.

The two travel on different paths. Switch between them:

Two paths

Signaling and media take different routes

atlanta.examplebiloxi.exampleSIP signaling: through the proxiesRTP media: directly between the phonesAlice192.0.2.10Registraratlanta.exampleProxy A198.51.100.10Proxy B203.0.113.10Bob203.0.113.20

Two separate paths. SIP sets up the call; RTP carries the voice.

RFC 3261 §4 · Overview of Operation
“In general, the end-to-end media packets take a different path from the SIP signaling messages.”
Read the section ↗

Why separate them? SIP messages need decisions: which server handles biloxi.example? Which phone is Bob’s? The proxies make these decisions. Audio needs speed: fifty small packets every second, in each direction. Sending them through every proxy would add delay and load, and nothing needs to decide anything about them.

Signaling Media
Protocol SIP (with SDP inside) RTP (and RTCP)
Path Phone → proxies → phone Phone → phone, directly
How many packets A few dozen per call About 50 per second, each way
Typical port 5060 (UDP or TCP), 5061 (TLS) A random even port, for example 49170

0.3 The protocol family

SIP never works alone. A complete call uses a family of protocols. Each one does one job.

Signaling: setting up the callMedia: the voice itself
Description

SDP

The body of an INVITE or 200 OK. It lists the IP address, port, and codecs for the media.

15

Codecs

G.711, G.722, Opus, AMR-WB… The format of the audio inside each packet.

16

Protocol

SIP

Finds the other user, sets up the call, changes it, and ends it.

03040506

RTP + RTCP

RTP carries the audio in small packets. RTCP reports loss, delay, and jitter.

1617

Security

TLS

Encrypts SIP between two hops. Port 5061.

1419

SRTP

Encrypts and authenticates each RTP packet.

18

Transport

UDP · TCP · WebSocket

SIP runs over any of these. UDP is the most common; port 5060.

19

UDP

Audio needs speed more than perfect delivery, so RTP uses UDP.

16

Network

IP

Both stacks run over IP. NAT routers change IP addresses and ports on the way, which causes many SIP problems.

0220

RFC 3261 §2 · Overview of SIP Functionality
“SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls.”
Read the section ↗
RFC 3261 §2 · Overview of SIP Functionality
“SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.”
Read the section ↗

The other members of the family:

  • SDP describes the media: the IP address, the port, and the codecscodec. The method that turns sound into data and back, such as G.711 or Opus. that a phone can use. SDP travels as the body of a SIP message. In our call, it is in the INVITE and in the 200 OK.
  • RTP carries the audio in small packets. Each packet has a sequence number and a timestamp, so the receiver can play the sound in the right order and at the right speed.
  • RTCP travels next to RTP and reports quality: lost packets, delay, and jitter.
  • TLS and SRTP add encryption — TLS for SIP, SRTP for the media.
RFC 8866 §1 · Introduction
“SDP is purely a format for session description -- it does not incorporate a transport protocol, and it is intended to use different transport protocols as appropriate”
Read the section ↗
RFC 3550 §1 · Introduction
“This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video.”
Read the section ↗

0.4 How to read this course

Every diagram in this course uses the same visual language. One colour, one shape, or one mark always has the same meaning.

Colour means protocol

  • SIP signalingRequests and responses that set up, change, and end calls
  • SDPThe media description inside a SIP message
  • RTP mediaAudio and video packets. Always a dashed line.
  • RTCPQuality reports and keepalives
  • DNS, STUN, ICEFinding servers and finding a path through NAT
  • TCP / IPLower-layer packets, such as a TCP handshake
  • ErrorA failed path, a problem, or a warning (⚠)

Shapes and marks

  • Rounded boxA user agent: a phone or a softphone
  • Square boxA proxy, registrar, or other server
  • Double borderA B2BUA or SBC
  • White outlineWhat the current step is about
  • ✕Red crossA lost packet, or an element that is down

Ladder diagrams

Most modules draw a call as a ladder: one vertical line for each element, time running down, and one arrow for each message. The caller is always on the left. Here is the same call as a ladder:

The same call, as a ladder

One phone call, from registration to hang-up

  • SIP
  • RTP media
Alice192.0.2.10Registraratlanta.exampleProxy A198.51.100.10Proxy B203.0.113.10Bob203.0.113.2001REGISTER02401 Unauthorized03REGISTER (credentials)04200 OK05INVITE06407 Proxy Auth Required07ACK08INVITE (credentials)09100 Trying10INVITE11100 Trying12INVITE13180 Ringing14180 Ringing15180 Ringing16200 OK17200 OK18200 OK19ACK20ACK21ACK22RTP audio23BYE24BYE25BYE26200 OK27200 OK28200 OK
01/28

Alice's phone starts. It tells the Registrar the address where Alice is now.

All steps as text
  1. Alice → Registrar: REGISTER. Alice's phone starts. It tells the Registrar the address where Alice is now.
  2. Registrar → Alice: 401 Unauthorized. The Registrar asks the phone to prove that it knows Alice's password.
  3. Alice → Registrar: REGISTER (credentials). The phone sends REGISTER again with proof of the password. The password itself never travels.
  4. Registrar → Alice: 200 OK. The Registrar stores Alice's current address. Alice can now receive calls.
  5. Alice → Proxy A: INVITE. Alice dials Bob. The phone sends an INVITE to Proxy A, the server for atlanta.example.
  6. Proxy A → Alice: 407 Proxy Auth Required. Proxy A asks for proof of identity before it connects the call.
  7. Alice → Proxy A: ACK. The phone confirms that it received the 407.
  8. Alice → Proxy A: INVITE (credentials). The phone sends the INVITE again, now with credentials.
  9. Proxy A → Alice: 100 Trying. Proxy A accepts the credentials. It answers 100 Trying, which means "I am working on it".
  10. Proxy A → Proxy B: INVITE. Proxy A forwards the INVITE to Proxy B, the server for biloxi.example.
  11. Proxy B → Proxy A: 100 Trying. Proxy B also answers 100 Trying.
  12. Proxy B → Bob: INVITE. Proxy B knows where Bob's phone is, because the phone registered earlier. It forwards the INVITE.
  13. Bob → Proxy B: 180 Ringing. Bob's phone rings and answers 180 Ringing.
  14. Proxy B → Proxy A: 180 Ringing. The proxies pass the 180 back toward Alice.
  15. Proxy A → Alice: 180 Ringing. Alice hears the ringback tone.
  16. Bob → Proxy B: 200 OK. Bob answers. The 200 OK describes the media that Bob's phone can receive.
  17. Proxy B → Proxy A: 200 OK. The 200 OK travels back along the same path.
  18. Proxy A → Alice: 200 OK. Alice's phone now knows where to send audio, and what format to use.
  19. Alice → Proxy A: ACK. The phone confirms the 200 OK with an ACK. The call setup is complete.
  20. Proxy A → Proxy B: ACK. Both proxies asked to stay in the path, so the ACK goes through them.
  21. Proxy B → Bob: ACK. Bob's phone receives the ACK.
  22. Alice → Bob: RTP audio. Alice and Bob talk. Audio travels directly between the phones as RTP, not through the proxies.
  23. Bob → Proxy B: BYE. Bob hangs up. Bob's phone sends BYE through the same proxies.
  24. Proxy B → Proxy A: BYE. Proxy B forwards the BYE to Proxy A.
  25. Proxy A → Alice: BYE. Alice's phone receives the BYE and stops the audio.
  26. Alice → Proxy A: 200 OK. Alice's phone confirms with 200 OK. For Alice, the call is over.
  27. Proxy A → Proxy B: 200 OK. Each proxy removes its own Via and passes the 200 OK on.
  28. Proxy B → Bob: 200 OK. Bob's phone receives the 200 OK. Both phones are idle again.

Every interactive diagram has the same controls:

Control Key What it does
▶ / ❚❚ Space Play or pause
◀ and ▶| ← → One step back or forward
⏮ Home Go to the first step
Expand Esc to close Open the diagram full screen
Select an arrow — Jump to that step
Select a line in the inspector Enter Pin the explanation of that line

Other building blocks

  • RFC quotes. Rules come with the exact sentence from the RFC that defines them, and a link to that section. Words such as MUST and SHOULD are highlighted: they have a precise meaning in RFCs (RFC 2119).
  • Terms. A word with a dotted underline, such as proxyproxy. An element that forwards requests and responses. It does not start or end calls., shows its definition when you point at it.
  • Broken / Fixed. Every module ends with common mistakes. Where possible, a switch shows the call going wrong, and then going right. See the end of Module 13 for an example.
  • Path badges. NOC core and DEV core at the top of a module show whether it is essential for the support path, the developer path, or both.

Common mistakes

“SIP carries the voice”

SIP only sets up, changes, and ends the call. The voice travels as RTP, on its own path. When a call connects but has no audio, the SIP messages are often perfect — look at the media path instead.

Remember: signaling and media are two separate problems, with two separate paths.

“The proxies carry the audio”

In a plain SIP network, proxies handle only SIP. The audio goes directly between the phones. Some networks do put a box in the media path — a session border controller or a media relay — but that is a choice, not part of SIP. Module 25 shows these designs.

Remember: to find where audio goes, read the IP address and port in the SDP, not the list of proxies.

“One request, one response”

Alice’s second INVITE received three responses: 100 Trying, 180 Ringing, and 200 OK. Then Alice’s phone sent an ACK for the 200 OK. SIP has provisional responses (1xx) that report progress, and one final response (2xx to 6xx) that ends the request.

Remember: look for the final response. Module 6 explains every response class.

“Registration lets the phone make calls”

Registration lets other people reach you: it stores your current address. It does not, by itself, allow outgoing calls. In our call, Proxy A challenged the INVITE separately, even though Alice had just registered.

Remember: REGISTER problems break incoming calls first. Modules 12 and 13 cover registration and authentication.

Learning SIP from very old examples

SIP was first defined in RFC 2543 (1999). RFC 3261 replaced it in 2002 and changed important details. Many old guides and traces still show the old behaviour.

Remember: check that examples follow RFC 3261. One quick sign: every Via branch value starts with z9hG4bK.

Summary

  • A SIP call involves user agents (the phones), a registrar (which remembers where users are), and proxies (which route the call).
  • One call has seven chapters: register, prove identity, find the callee, ring and answer, confirm, talk, hang up.
  • Signaling (SIP) goes through the proxies. Media (RTP) goes directly between the phones.
  • SIP works with a family of protocols: SDP describes the media, RTP carries it, RTCP reports on it, and TLS and SRTP protect it.
  • In every diagram, colour means protocol, dashed means media, and a white outline marks what the current step is about.