VoIP uses a layered set of protocols: SIP (Session Initiation Protocol) handles call setup and teardown; SDP (Session Description Protocol) negotiates media parameters within SIP messages; RTP (Real-time Transport Protocol) carries the actual audio. TLS encrypts SIP signaling; SRTP encrypts RTP media. Understanding how these interact explains most VoIP troubleshooting patterns.
How a VoIP call works — the 7-step sequence
- DNS SRV/NAPTR lookup: caller's device resolves the SIP server address (RFC 3263 — DNS SRV for transport discovery).
- SIP INVITE: caller sends INVITE to SIP server containing SDP offer (proposed codecs, media IP:port).
- SIP 100 Trying: server acknowledges receipt, begins routing.
- SIP 180 Ringing: destination is alerting (you hear ringback generated locally or remotely).
- SIP 200 OK: destination answers; contains SDP answer (accepted codec, destination media IP:port).
- SIP ACK: caller confirms; RTP media stream begins between the two media IP:port addresses in SDP.
- Call in progress: RTP carries audio; RTCP carries quality stats; SIP dialog remains open until BYE.
SIP — Session Initiation Protocol (RFC 3261)
Text-based signaling protocol (like HTTP for calls).
Request methods: INVITE (new call), ACK (confirm), BYE (end call), CANCEL (cancel in-progress call), REGISTER (register endpoint), OPTIONS (probe/capability check).
Response codes: 1xx Provisional, 2xx Success, 3xx Redirect, 4xx Client error (401 Auth, 403 Forbidden, 404 Not Found), 5xx Server error (503 Unavailable), 6xx Global failure.
SIP URI format: sip:user@domain or sips:user@domain (TLS).
See SIP response codes for a complete code reference.
SDP — Session Description Protocol (RFC 4566)
Not a standalone protocol — carried inside SIP messages (in INVITE and 200 OK bodies).
Negotiates: codec list (in order of preference), media IP address, RTP port, other parameters.
Offer/answer model: caller proposes in INVITE SDP offer; callee selects one codec and responds in 200 OK SDP answer; codec negotiation is complete.
Why it matters for troubleshooting: codec mismatch (both sides in different codecs) produces robotic audio; wrong media IP in SDP produces one-way audio.
RTP — Real-time Transport Protocol (RFC 3550)
Carries audio (and video) packets over UDP.
Packet structure: sequence number (detects loss and reordering), timestamp (enables jitter buffer synchronization), SSRC (identifies the media stream).
Jitter buffer: compensates for variable packet arrival time by buffering and reordering packets before playback; too small → gaps/choppy; too large → added latency.
Why UDP not TCP: TCP retransmits lost packets, adding latency that makes voice unintelligible; lost UDP packets produce brief audio artifacts (less damaging than retransmit delay).
RTCP — RTP Control Protocol (RFC 3550)
Companion to RTP; shares same port (typically RTP port +1).
Reports: packet loss rate, jitter, round-trip time, SSRC mapping.
Used for: real-time quality monitoring, MOS estimation, diagnosing one-way audio (if RTCP from one side is absent, that side's media isn't arriving).
TLS and SRTP — encrypting VoIP
- TLS (Transport Layer Security): encrypts SIP signaling; uses TCP (SIP/TLS); standard for enterprise UCaaS; URI prefix
sips:. - SRTP (Secure RTP, RFC 3711): encrypts RTP media; session keys exchanged via SDP or DTLS-SRTP; prevents eavesdropping on the audio stream.
- SIP over TLS + SRTP = encrypted signaling AND encrypted media; both required for truly private calls.
- SIP over TLS without SRTP: signaling is encrypted but audio is still in cleartext RTP.
UDP vs TCP for SIP
- UDP: connectionless, lower overhead, standard for SIP; packets can be lost; suitable for LAN/controlled environments.
- TCP: connection-oriented, reliable delivery, required for large SIP messages (TCP path MTU vs UDP); used for SIP over TLS (SIP/TLS must use TCP or TLS over TCP).
- UDP SIP reliability issue: large SIP messages (with many SDP attributes or long header lists) can exceed 1500-byte path MTU; fragments may be lost, causing INVITE failure — fix is to use TCP or reduce SDP size.
DNS SRV and NAPTR (RFC 3263)
SIP clients use DNS SRV records to discover SIP servers and preferred transports.
- SRV records:
_sip._tcp.domain→ TCP SIP server;_sip._udp.domain→ UDP SIP server;_sips._tcp.domain→ TLS. - NAPTR records: priority-ordered list of services; SIP clients query NAPTR first, then SRV.
- Why it matters: SIP trunk providers specify SBC hostnames; client resolves via SRV; if SRV is missing or returns wrong records, registration fails; use
dig SRV _sip._udp.provider.comto verify.
SIP infrastructure components
- SIP Proxy: routes SIP messages; doesn't maintain dialog state.
- SIP Registrar: accepts REGISTER messages; maps SIP URI → current contact address (IP:port).
- SIP B2BUA (Back-to-Back User Agent): terminates one SIP dialog and originates another; maintains full call state; most SBCs are B2BUAs.
- SBC (Session Border Controller): sits at network edge; provides NAT traversal, security (SIP normalization, IP ACL), topology hiding, transcoding, and recording integration.
Common protocol-level problems
| Symptom | Protocol layer | Likely cause |
|---|---|---|
| Call drops at 30s | SIP | ACK not received — NAT/firewall blocking response |
| One-way audio | SDP/RTP | Wrong media IP in SDP, SIP ALG rewrote it |
| Registration fails with 401 | SIP | Auth challenge — wrong credentials |
| No audio (both directions) | RTP | RTP ports blocked; media proxy misconfigured |
| Codec mismatch (robotic) | SDP | SDP answer selected incompatible codec |
| Call fails with 503 | SIP | Provider SBC down or unreachable |
