RFC 9796 — SIP Call-Info Parameters for Rich Call Data — library

RFC 9796 (Wendt, Peterson — July 2025) is the IETF specification that defines how a terminating network conveys its normalized, authenticated view of Rich Call Data to the SIP UA over the authenticated User-Network Interface. I am first author. The document gives the network a single conveyance path for caller-identity content it has already vetted, and gives the SIP UA a structured, trust-tagged view it can rely on for display — with room for endpoint-side additional rules layered on top.

The document is a SIPCORE WG product (not STIR), reflecting that the work concerns SIP header field syntax and UNI conveyance rather than the STIR identity protocol itself.

The network-normalization model

The framing that defines 9796 is that the terminating network acts as a normalizer and validator across multiple potential sources of RCD information. Any of the following — separately or in combination — may inform the terminating provider’s view of who the calling party is and what should be displayed:

A fully validated RFC 9795 RCD PASSporT carried in an Identity header field. The strongest-trust input — content cryptographically signed by an authorized originator and verified through the STIR certificate hierarchy.
Legacy SIP signaling — display name, P-Asserted-Identity, From header field content. Unsigned, lower trust, but still the signal that’s actually present on most calls in current deployment.
A terminating-side CNAM dip — a database lookup at the provider layer that returns calling-party name information from the provider’s CNAM source. Pre-STIR-era mechanism, but still operationally significant.
Any combination of the above with provider-side policy applied (priority rules, conflict resolution, fraud-flag overrides).

The terminating provider normalizes these into a single RCD view and conveys that view to the SIP UA through the Call-Info parameters this document defines. The verified parameter signals the trust posture the network has assigned; the integrity parameter ensures the conveyed content hasn’t been tampered with as it crosses the UNI.

The model deliberately leaves the network’s normalization logic out of scope. Different providers will have different policies about how to weight the various input sources, when to apply provider-side overrides, and how to handle conflicts between them. What 9796 specifies is the conveyance — what the SIP UA sees over the authenticated UNI.

What it specifies

The mechanism extends the SIP Call-Info header field with RCD-specific parameters and a new purpose token:

A new purpose token — jcard. Indicates that the Call-Info URI points at a jCard JSON object representing the calling party — name, organization, contact details, optionally logo and other rich content. The receiving device fetches the jCard from the URI and renders it as caller identity.
A new call-reason parameter. Carries a description of the reason for the call — useful in B2C contexts (delivery notification, appointment reminder, fraud alert) where the reason itself helps the called party decide whether to pick up.
A new verified parameter. Indicates that the content pointed at by the Call-Info URI has been verified by the terminating network. The provider sets this parameter to signal trust to the endpoint device.
A new integrity parameter. Carries a cryptographic digest of the resource the URI points at, so the receiving device can verify the content hasn’t changed in transit between the provider and the endpoint.

Endpoint-side additional logic

The network-validated view conveyed via 9796 is what the SIP UA sees, but the UA isn’t bound to display it as-is. Endpoint-side additional logic is common and expected:

Mobile operating systems — iOS and Android — have their own logic beyond what the terminating carrier does. STIR-overlay validation, contact-list integration, third-party caller-identification services, on-device anti-spam scoring. The carrier’s verified indicator informs the UA but doesn’t determine what the user ultimately sees.
Enterprise environments — PBX systems, call-center applications, agent desktop tools — frequently add their own validation and display rules. A call center might apply customer-specific routing logic; a PBX might surface particular RCD elements to specific agents; a call-recording system might tag calls based on the network-provided trust posture.

The split is intentional: the network’s job is to provide a normalized, authenticated baseline; the endpoint’s job is to apply its own context. 9796 defines the conveyance protocol that bridges the two.

Why this work was needed alongside RFC 9795

RFC 9795 defines a signed PASSporT extension that the originating side (or a third-party RCD authority on its behalf) creates and the terminating network verifies. PASSporTs travel between authentication and verification services — typically network elements, not endpoints. Most endpoint devices don’t process PASSporTs directly; they consume SIP signaling at the UNI.

9796 is the bridge from network-side verification to endpoint-side delivery — but the framing isn’t simply “9795 → 9796 chain.” The terminating network may be acting on a verified 9795 PASSporT, on legacy signaling alone, on a CNAM dip, or on some combination. Whatever path produced the network’s view of caller identity, 9796 is the conveyance mechanism for that view.

The split between the two documents also reflects the WG split: RFC 9795 is a STIR document (about the signed token); RFC 9796 is a SIPCORE document (about SIP header field syntax). Each working group handled the layer it owns.

Where this document is referenced

RFC 9795 is one of the input sources to the network normalization that 9796 conveys — the strongest-trust input, the cryptographically-signed RCD PASSporT.
Rich call data is the topic page covering RCD across the framework — the IETF specs, the SHAKEN operational profile (ATIS-1000094), the verification and trust story, and the regulatory work (FCC’s Ninth FNPRM) that’s pulling RCD into deployment.
SHAKEN is the broader operational framework that profiles RCD into deployable US infrastructure.