What Is Rich Call Data (RCD)? Branded Call Display Explained

Answer rates for business calls have collapsed. When a legitimate call shows up as an unfamiliar 10-digit number, or worse, as “Spam Likely,” most people let it ring out. Rich Call Data is the industry’s answer to that problem: a way for a verified business to deliver its name, its logo, and the reason it’s calling straight to the recipient’s screen, cryptographically tied to the call so it cannot be faked.

Rich Call Data (RCD), rich call display, and branded call display all describe the same shift, moving caller identity from a bare 15-character name field to a verified, visual business identity. In this article, we’ll walk you through what RCD actually is, how it rides on top of STIR/SHAKEN, how it differs from CNAM and from the proprietary branded calling programs carriers already sell, and where the Session Border Controller (SBC) fits when you deliver it in a real voice network. If you operate or resell voice service, this is particularly useful for understanding what your infrastructure has to pass through as these standards mature.

What Is Rich Call Data?

Rich Call Data is verified information about the caller (their business name, a logo, and the reason for the call) delivered alongside the call and bound to it cryptographically. Instead of the recipient seeing a bare number or a truncated name, they see the calling organization presented the way that organization intends, with proof that the identity is genuine.

The important word is verified. Anyone can put any name in a SIP display field, which is exactly why “Spam Likely” labels and unanswered calls became the norm. RCD closes that gap by carrying the identity content inside the signed STIR/SHAKEN token, so a downstream network can confirm the logo and name were placed there by the authenticated originating provider and were not altered in transit.

Three terms circulate around this idea, and they describe different slices of the same system. Rich Call Data is the data itself and the standard that carries it. Rich call display is the recipient-side rendering of that data on the device. Branded call display, or branded calling, is the commercial packaging that voice providers and analytics partners sell to businesses that want their calls to arrive branded. A given branded calling product may deliver identity through the standards-based RCD path, through a carrier-specific program, or through both.

Why RCD Exists: The Limits of CNAM

For decades, the name on a caller ID display came from CNAM. When a call arrived, the terminating carrier took the calling number and queried a database to retrieve up to 15 characters of associated name. That model carried the industry a long way, but it has three structural limits that RCD is designed to remove. Our guide to CNAM lookups covers the legacy mechanism in depth.

CNAM offers no proof. The name comes from a database, not from the caller, and nothing binds it to the specific call. A spoofed number can return a perfectly legitimate-looking CNAM entry, because the lookup only asks “what name is on file for this number,” never “did the party who owns this number actually place this call.”

CNAM is fifteen characters and text only. “JOHNSONVILLE MED” is what a hospital gets to work with. There is no room for a full legal business name, no logo, and no way to tell the recipient why the call is happening.

CNAM is fragmented and terminating-side. Multiple databases hold different records, the name shown depends on which one the terminating carrier queries, and the calling business has limited control over what any given recipient sees.

Capability	CNAM	Rich Call Data
Name length	15 characters, text only	Full business name
Logo	Not supported	Supported
Call reason	Not supported	Supported
Cryptographic proof	None	Signed with the call
Controlled by	Terminating-side database	Originating (verified caller)

How Rich Call Data Works with STIR/SHAKEN

RCD is not a separate protocol bolted onto the call. It is an extension of the same STIR/SHAKEN machinery that already authenticates the calling number, which is why understanding the signing flow matters. Our explainer on STIR/SHAKEN and call authentication covers the underlying signing and verification flow.

When an originating provider signs a call, an Authentication Service builds a PASSporT: a JSON Web Token holding the calling number, the called number, a timestamp, and the attestation level, all bound by a digital signature. RCD adds a claim to that same token. The signed PASSporT now also carries the caller’s display name, a reference to a hosted logo, and an optional call reason. That rich-data claim is defined by the IETF PASSporT RCD extension (still an Internet-Draft) and the ATIS-1000094 industry standard, both building on the base PASSporT defined in RFC 8225. Because the identity content lives inside the signature, it inherits STIR/SHAKEN’s core guarantee: a downstream network can verify it was placed there by the authenticated provider and was not tampered with along the way.

The end-to-end sequence looks like this:

1. The business registers its brandThe calling organization provides its verified name, logo, and identity details to its voice service provider or a branded calling authority, which validates that the business is who it claims to be and controls the numbers it will call from.
2. The originating provider signs the call with RCDOn an outbound call, the provider’s SBC hands the call to the Authentication Service, which builds a PASSporT that includes the rcd claim (name, logo reference, call reason) and returns a signed Identity header.
3. The Identity header travels with the callThe signed Identity header rides in the SIP INVITE across the interconnect, through each SBC, to the terminating network. The rich data is carried inside it.
4. The terminating provider verifiesA Verification Service validates the signature and the certificate chain, confirming the attestation level and that the RCD content is authentic and unaltered.
5. The device renders the branded displayOnce verified, the terminating carrier or the handset presents the business name, logo, and call reason to the recipient. This rendering is rich call display.

The attestation level still matters here. Branded display is generally reserved for calls signed at full (A-level) attestation, because that is the level at which the originating provider vouches for both the identity of the caller and its right to use the number. A call signed at gateway (C-level) attestation carries far less trust and is unlikely to earn a branded display downstream. If you need the detail on what each level claims, see our breakdown of STIR/SHAKEN attestation levels.

RCD, Branded Calling Programs, and How They Differ

In practice, “branded calling” reaches the market through two broad approaches, and the distinction matters when you plan infrastructure.

Standards-based RCD

The identity content is carried inside the signed PASSporT and travels with the call over the SIP interconnect. This is the approach described above, and it is where the industry is heading because the branding is bound to the call itself rather than reconstructed at the far end. It depends on the whole path (originating provider, transit, and terminating provider) supporting RCD in the Identity header.

Analytics and carrier-hosted branded calling

Several branded calling products predate widespread RCD deployment. A business registers its brand with an analytics provider or a program run by the major mobile carriers, and the terminating network displays the branded card by matching the incoming number against that pre-registered data. Here the branding is delivered by the terminating side rather than carried in the signature, so coverage depends on which display partners and carriers a given recipient’s device uses.

These approaches are converging. STIR/SHAKEN attestation and RCD provide the verification backbone, while the carrier and analytics programs provide the display surface on the handset. For a voice provider, the practical takeaway is that you rarely control the recipient’s screen directly. What you control is whether your network signs calls at A-level attestation and passes RCD-bearing Identity headers cleanly, which is the prerequisite for any of these programs to trust and display your customers’ brands.

Where the SBC Fits in RCD Delivery

Rich Call Data lives in SIP signaling, and the SBC is the element that processes that signaling at the network edge. That makes the SBC the practical control point for RCD in three distinct roles.

Signing on the way out

On outbound calls, the SBC is where signing happens. It hands the call to the Authentication Service and applies the returned Identity header to the outgoing INVITE. When that PASSporT carries an rcd claim, the SBC is the element placing the verified brand data onto the wire. The identity treatment can be applied per trunk group, so a provider can sign one customer’s traffic at A-level with full RCD and treat wholesale transit traffic differently.

Verifying on the way in

On inbound calls, the SBC hands the Identity header to a Verification Service and acts on the result. This is where the terminating network establishes that the RCD content is authentic before anything is shown to a subscriber. The verification result can then drive routing and presentation decisions downstream.

Preserving identity across the interconnect

An SBC operating as a Back-to-Back User Agent (B2BUA) fully terminates and re-originates every call, which gives it complete control over SIP headers on each leg. That control is a double-edged requirement for RCD. Header manipulation is essential for multi-vendor interoperability, but a signed Identity header must be preserved intact, because any modification to the signed content invalidates the signature. A properly configured SBC normalizes the headers it needs to normalize while carrying the Identity header through untouched.

How ProSBC Handles Signing, Verification, and Rich Data

ProSBC implements STIR/SHAKEN through its programmable Ruby routing engine rather than as a fixed per-trunk toggle, which is what makes per-call and per-customer identity policy possible. Signing and verification are filters in the call routing chain, and the same chain that authenticates the number is where identity content is applied.

In production, ProSBC connects to its STI Authentication and Verification service over SIP. The two deployed signing partners, TransNexus ClearIP and Neustar, both operate as SIP redirect servers. ProSBC routes the call to a NAP whose service type is set to authentication, sends the INVITE to the signing service (for example, sip.clearip.com), and the service returns a SIP 302 carrying the Identity header in the P-Asserted-Identity. ProSBC then route-advances with that signed Identity header attached to the outbound call. Failover is expressed through route ordering and Reason Cause Mapping, so a signing-service outage advances to a bypass route and never blocks call completion.

Attestation as a per-call decision

Because a single SBC often carries mixed traffic (retail customers who qualify for A-level, wholesale traffic that does not), attestation cannot be a blanket setting without either overstating trust or damaging completion rates. ProSBC’s routing engine assigns attestation per call, which is precisely the control that determines whether a given call can carry a branded display downstream.

Carrying rich identity data cleanly

ProSBC’s SIP header manipulation engine normalizes signaling for multi-vendor interoperability while preserving the signed Identity header that carries RCD content. As branded calling standards mature, the operative capability is passing the enriched, signed Identity header through the network edge without breaking the signature, which is a function of B2BUA architecture and configurable, per-NAP header handling.

The Regulatory Backdrop

Caller identity sits inside an active regulatory environment. The FCC’s Truth in Caller ID Act prohibits transmitting misleading caller ID information with intent to defraud, and the STIR/SHAKEN framework the FCC enforces provides the authentication layer that branded calling builds on. Verified branding is only meaningful because the underlying number authentication makes spoofing detectable.

The FCC has also examined caller identity beyond the legacy name field. Rulemaking proceedings have explored frameworks for delivering verified business identity (logos and full business names) to consumers, which is the regulatory expression of what RCD delivers technically. For a voice provider, the durable implication is that authenticated identity is becoming an expectation rather than a differentiator, and that the SBC-level ability to sign, verify, and carry identity data is foundational to meeting it. Providers moving from partial to full attestation will find our A-level attestation guide directly relevant, since A-level signing is the gate to branded display.

Frequently Asked Questions