RFC 8816 — STIR Out-of-Band Architecture and Use Cases — library

RFC 8816 (Rescorla, Peterson — February 2021) is the IETF Informational specification that defines the out-of-band architecture for STIR. The motivation is structural: not every telephone call uses Internet signaling end-to-end. Some traverse TDM in the middle, some terminate on legacy networks that strip SIP headers, some originate on systems that don’t carry SIP at all. The base STIR protocol (RFC 8224) relies on an Identity header field in SIP signaling, which means those calls have no way to deliver a PASSporT to the verifier. This document defines the alternative path — storage-and-retrieval through a Call Placement Service (CPS) — and the use cases that motivate it.

The status is Informational rather than Standards Track because the document defines an architecture and use-case framing rather than a single on-the-wire protocol. The actual deployable OOB profiles came later, in RFC 9888 (formerly draft-ietf-stir-servprovider-oob) and other follow-on work.

What it specifies

The architecture has three pieces:

Call Placement Service (CPS). A network-resident service that stores PASSporTs keyed by some identifier the receiving side can use to retrieve them — typically the called number, the calling number, or a combination. The originating side publishes the PASSporT to a CPS at call-placement time; the terminating side retrieves it when the call arrives.
Two architectural variants — push vs. pull. In the push variant, the CPS forwards PASSporTs to a registered callee. In the pull variant, the callee retrieves PASSporTs from the CPS upon being notified of an incoming call (typically by the inbound PSTN call itself acting as the notification trigger). The document focuses on pull because push requires a full-time connection from the callee to the CPS, which is problematic for mobile endpoints — they can’t be expected to hold an open connection.
A retrieval model bound to call timing. The PASSporT is retrieved when the call arrives, not earlier or later. This keeps the CPS’s storage burden bounded and keeps verification contemporaneous with call setup.

Use cases the document covers

The document is more architectural than any of the other STIR specs — it spends substantial space mapping the use cases where OOB is necessary:

TDM-segment paths. A call that originates on SIP, traverses a TDM segment in the middle, and terminates back on SIP. The TDM segment strips the Identity header field; OOB lets the PASSporT reach the terminating side via the CPS.
Partial-IP paths. Similar but where the TDM segment is the terminating leg — some legacy carriers still operate TDM-only termination.
Calls into legacy systems. PSTN-originating calls that don’t carry SIP end-to-end at all but need STIR-style authentication for downstream verification.
SMS gateway scenarios. Messaging that crosses between IP and legacy SMS infrastructure, where in-band PASSporT conveyance isn’t possible. (The messaging-side STIR extensions in RFC 9475 build on this OOB substrate.)
Specialized environments. Call centers that handle high call volumes and might benefit from pre-fetching PASSporTs before each call arrives.

The document explicitly frames OOB as both transitional — useful while in-band STIR adoption ramps up — and permanent infrastructure for cases where end-to-end SIP isn’t realistic.

Where this document is referenced

Out-of-band STIR is the topic page covering OOB approaches across the various profiles (8816 architecture, ATIS-1000087/1000095/1000096 TDM-specific work, the service-provider OOB profile now in RFC 9888) and the current FCC NPRM that’s pushing OOB deployment.
RFC 8224 and RFC 8225 define the in-band STIR mechanism that OOB exists to extend reach beyond.
RFC 9888 (formerly draft-ietf-stir-servprovider-oob) is the deployable profile for service-provider OOB.
RFC 9475 extends STIR to messaging use cases that depend on the OOB architecture for cross-network conveyance.