SIP and the protocol foundations of modern voice

SIP, the Session Initiation Protocol, is the signaling that sets up, modifies, and tears down nearly every modern voice call, video call, and real-time session. It is the layer underneath everything else in this library: caller authentication, call routing, attestation, and the whole trust framework are things that happen to SIP signaling, so reasoning about them without grounding in how a call is actually established is reasoning in the dark. This section is the ground floor.

SIP is deliberately modeled on the web. It is a text-based request/response protocol whose designers borrowed HTTP’s shape — methods, status codes, headers, URIs — and pointed it at establishing media sessions rather than fetching documents. That lineage is why SIP feels legible to anyone who knows HTTP, and it is also why identity in SIP ended up looking the way it does: the same instinct that produced signed web tokens produced the signed PASSporT that STIR carries in a SIP header. I have served on the SIP Forum board and spent fifteen-plus years building products that ride on SIP, so this section pairs the spec-level detail with practitioner notes on where the protocol’s clean model meets the messy reality of interconnected networks.

The protocol model

SIP is a request/response protocol. A client sends a request naming a method — the verb — and a server answers with one or more responses carrying a three-digit status code borrowed straight from HTTP’s grammar (1xx provisional, 2xx success, 3xx redirection, 4xx/5xx/6xx failure). The core methods are few: INVITE starts a session, ACK confirms the final response to an INVITE, BYE ends a session, CANCEL withdraws a pending request, REGISTER binds a user’s address to a location, and OPTIONS queries capabilities. Later extensions added SUBSCRIBE/ NOTIFY for event notification, MESSAGE for instant messaging, INFO, UPDATE, and PRACK among others — but the whole protocol still turns on that small set of verbs.

Two structures organize the flow. A transaction is a single request and its responses. A dialog is the longer-lived relationship between two endpoints — established by an INVITE transaction, identified by the Call-ID plus the From and To tags, and lasting until a BYE. The distinction matters because identity, billing, and media all attach to the dialog, while retransmission and routing decisions happen per transaction. SIP itself only handles signaling; the actual media — the audio and video — flows separately over RTP, and the two are negotiated but not carried together, which is a design choice with consequences that echo all the way up into the trust framework.

The roles

The SIP architecture is a small cast of logical roles, and a single box on the network often plays several. A user agent client (UAC) issues requests and a user agent server (UAS) answers them; an endpoint is both, depending on the direction. A registrar records where a user can currently be reached (the REGISTER binding). A proxy forwards requests toward their destination, making routing decisions without terminating the dialog — it sees the signaling but stays out of the media. A redirect server tells the caller to try somewhere else rather than forwarding on its behalf.

The role that matters most in practice, and the one the specs talk about least, is the back-to-back user agent (B2BUA). A B2BUA terminates one call leg and originates another, presenting itself as a UAS to one side and a UAC to the other. Almost every real deployment — PBXs, softswitches, application servers, and the session border controllers below — is a B2BUA, because sitting in the full path of both signaling and media is what lets an operator control, transcode, bill, and secure a call. It is also why identity is hard: every B2BUA in the path is a place where the original signed assertion can be preserved, altered, or dropped.

Anatomy of an INVITE

The INVITE is where a call begins, and its headers are worth knowing because so much of the trust framework is expressed in them. The request-URI names who is being called. To and From carry the logical parties (each gaining a tag that helps identify the dialog); From is the field a caller populates with its own number, which is exactly why an unauthenticated From is the spoofing problem STIR/SHAKEN exists to solve. Via records the path the request took, so responses can retrace it. Call-ID uniquely identifies the call; CSeq orders requests within it; Contact gives a direct address for follow-up; Max-Forwards prevents loops. The message body, described by a Content-Type, typically carries an SDP (Session Description Protocol) offer: the codecs, addresses, and ports for the media the two sides will negotiate.

The identity-bearing headers are the ones this library cares about most. The older P-Asserted-Identity carries a network-asserted identity but only within a trusted administrative domain — it is an assertion by convention, not by cryptography, and it does not survive crossing into an untrusted network. The Identity header defined by RFC 8224 replaced that trust-by-convention model with a signature: it carries a PASSporT, a signed token attesting the calling number, verifiable by anyone holding the right certificate. That header is the hinge between raw SIP and the entire STIR/SHAKEN framework — everything the trust layer does is, mechanically, about putting a verifiable assertion into SIP signaling and getting it to survive the trip.

The real-world ecosystem

The clean protocol model meets a messier reality at network borders. A session border controller (SBC) is the B2BUA that sits at the edge of a provider’s network, and it exists because the open protocol needs policing where two networks meet: the SBC hides internal topology, enforces security and admission control, fixes up NAT traversal, transcodes between incompatible codecs, and increasingly signs or verifies STIR PASSporTs. It is the practical control point for caller-identity policy.

SIP trunking is how an enterprise or provider connects its phone system to a carrier over IP instead of legacy circuits, and interconnection is how carriers connect to each other. Trunk setup has been a bilateral, out-of-band affair; RFC 10006, Automatic SIP Trunking and Peering, published August 2026 from the IETF ASAP working group, specifies a capability document an enterprise fetches from its provider over HTTPS — transport, codecs, call routing, and a secure-telephony-identity container reporting whether the provider is STIR compliant, whether it will delegate certificate authority over the enterprise’s allocated number ranges, and the ACME directory that issues those delegate certificates. The RFC names no implementers. Interconnection profiling is the domain of the ATIS/SIP Forum IP-NNI Task Force, which writes the profiles that make one provider’s SIP interoperate with another’s — including the SHAKEN profiles that carry verified identity across the boundary. The hard, recurring problem across all of it is the TDM gap: where an IP call crosses a legacy time-division segment in the middle, the SIP signaling — and the signed identity riding in it — is torn down and rebuilt, and the assertion is lost. Much of the current policy energy around the all-IP transition is, at bottom, about closing that gap so identity can travel end to end.

SIP and WebRTC

WebRTC is the other way real-time media reaches an endpoint, and the two are complementary rather than competing. WebRTC standardizes the media path — the codecs, encryption, and NAT traversal for browser-to-browser audio and video — but deliberately leaves signaling unspecified, so applications choose their own. In practice a great many WebRTC deployments carry SIP over WebSockets as that signaling layer, and gateways bridge WebRTC endpoints into the SIP world so a browser can place a call into the telephone network. The dividing line is clean: SIP answers “how do the parties find each other and agree to talk,” WebRTC answers “how does encrypted media flow between them once they have.” The identity questions this library cares about live on the SIP side.

The institutional context

SIP is an IETF protocol — RFC 3261 and a large family of descendants refine and extend it — but its practical evolution happens across several bodies. The SIP Forum is the industry organization where implementers coordinate on interoperability and profiles, and it co-sponsors the IP-NNI Task Force with ATIS, which is where the SHAKEN specifications were actually written. I serve on the SIP Forum board, and much of the caller-identity work in this library traces back through that IETF-and-SIP-Forum lineage: the protocol comes from the IETF, and the profiles that make it interoperate at carrier scale come from the joint task force.

Where this fits

This section is the substrate beneath the rest of the library. The STIR protocol layer is defined as an extension to SIP; RFC 8224 specifies the SIP Identity header that carries the signed assertion; the telephone numbers SIP routes to have their own structure and governance; and the whole STIR/SHAKEN framework is, mechanically, a set of things done to SIP signaling. The planned sub-pages will take the core RFCs, the INVITE anatomy, the SBC role, trunking and interconnection, the SIP/WebRTC boundary, and the SIP Forum each to the depth a working engineer needs.