SIP & Voice for Messaging Teams

SIP — the Session Initiation Protocol, RFC 3261 — is the application-layer signalling protocol that creates, modifies, and tears down real-time media sessions over IP, most commonly voice and video. Crucially, SIP does not carry the media itself: it negotiates and controls the session, and the audio or video then flows separately over RTP.

Its design is deliberately HTTP-like — human-readable text messages, request methods, three-digit response codes, and URI addressing (sip:alice@example.com) — which makes it approachable for teams already fluent in web protocols. This is why voice fits naturally alongside messaging in a CPaaS: it is another API-driven channel with a familiar request/response shape underneath.

The main actors are User Agents (a UAC that sends requests and a UAS that answers), plus infrastructure: registrars record where a user is reachable, and proxies route requests toward them. For a messaging team, voice is most often the OTP fallback channel and the urgent-alert channel — so understanding SIP is understanding how that channel actually connects.

SIP defines a small set of request methods. INVITE starts or modifies a session, ACK confirms a final response to an INVITE, and BYE ends an established call. REGISTER tells a registrar where a user can be reached, CANCEL aborts a pending request, and OPTIONS queries capabilities. Later RFCs add methods such as INFO, MESSAGE, SUBSCRIBE/NOTIFY, and UPDATE.

Responses mirror HTTP's three-digit scheme in six classes. 1xx are provisional (100 Trying, 180 Ringing); 2xx succeed (200 OK); 3xx redirect; 4xx are client errors (404 Not Found, 486 Busy Here, 407 Proxy Authentication Required); 5xx are server errors; and 6xx are global failures (603 Decline). Reading the class first, then the code, is how you triage a failing call quickly.

The classic quirk to internalise is the three-way handshake for call setup: INVITE, then a 200 OK, then a separate ACK — unlike most request/response protocols, the ACK for an INVITE is its own transaction. Mishandling that ACK is one of the most common causes of calls that ring but never connect.

Because SIP only signals, the actual media parameters are described by SDP (Session Description Protocol, RFC 4566), carried inside SIP message bodies. SDP is where each side advertises the codecs it supports, the IP address and port it will receive media on, and other media attributes.

SIP uses an offer/answer model (RFC 3264): the caller's INVITE carries an SDP offer listing its capabilities, and the callee's response carries an SDP answer selecting the common subset. This negotiation is what lets two endpoints agree on a codec and a media path before any audio flows.

The negotiated media then travels over RTP (Real-time Transport Protocol), which carries the audio/video packets with sequence numbers and timestamps, alongside RTCP for quality feedback. When the media must be confidential, SRTP (Secure RTP) encrypts and authenticates those packets. The mental model to keep: SIP+SDP set up the call, RTP/SRTP carry it — two separate paths that can even take different routes across the network.

Follow a simple call. The caller's UAC sends INVITE (with an SDP offer) toward the callee, possibly through one or more proxies. The callee's side answers 100 Trying, then 180 Ringing while the phone alerts, and finally 200 OK carrying the SDP answer once the callee accepts.

The caller replies with ACK, and at that moment the session is established: RTP media flows directly between the endpoints per the negotiated SDP, independent of the proxies that set the call up. Mid-call changes — putting a call on hold, adding video, switching codecs — use a re-INVITE or UPDATE carrying fresh SDP.

Either party ends the call by sending BYE, answered with 200 OK, which tears down the session and stops the media. Failures short-circuit the flow: a 486 Busy Here or 408 Request Timeout instead of 200 OK means the call never reaches the ACK stage. Seeing this whole sequence is what makes SIP logs legible when a call misbehaves.

A SIP trunk is a SIP-based connection between a private phone system (PBX) or an application and a carrier, replacing legacy physical trunks and carrying calls to and from the public network over IP. It is how programmatic voice reaches the PSTN at scale.

At the border sits the Session Border Controller (SBC) — the element that secures and controls SIP at the network edge. It performs topology hiding, NAT traversal, protocol interworking and normalisation between differing SIP dialects, admission control and rate limiting, and often media anchoring and transcoding. The SBC is to SIP roughly what the signalling firewall is to SS7/Diameter: the controlled checkpoint at the trust boundary.

VoLTE (Voice over LTE) is voice carried as an IMS service over the LTE data network, and its call control is SIP running inside IMS — the same protocol you have just learned, framed by the Cx/HSS and policy interfaces of the mobile core. So the SIP a messaging team uses for programmable voice and the SIP that controls a VoLTE call are the same protocol, differing in the surrounding network, not the signalling itself.