CNAM Lookup: What It Is and How It Works

Every time a phone displays a caller’s name instead of just a number, a CNAM lookup made that happen. For end users, it looks automatic. For service providers, carriers, and VoIP operators, CNAM is real infrastructure that runs on real equipment, and the Session Border Controller (SBC) is typically where the lookup executes.
This guide explains how CNAM works from the service-provider perspective, where the SBC fits in the process, how CNAM relates to STIR/SHAKEN, and what to consider when deploying CNAM in a production voice network.

What Is CNAM?

CNAM stands for Calling Name Delivery. It is a telephony service that associates a name, up to 15 characters long, with a telephone number. When a call arrives, the terminating carrier looks up the calling number in a CNAM database and delivers the associated name to the recipient’s phone, where it appears alongside the number on the caller ID display.
The name can identify an individual (“John Smith”) or an organization (“Acme Corp”). CNAM is primarily a North American service, used in the United States and parts of Canada. Other regions use different caller identification mechanisms, such as CNAP (Calling Name Presentation) in some European networks.
Unlike telephone numbers, which are managed through a centralized North American Numbering Plan, CNAM data is not stored in a single, authoritative database. Multiple Line Information Databases (LIDBs) and third-party CNAM providers maintain their own records. This means the name displayed for the same number can vary depending on which database the terminating carrier queries. It also means that keeping CNAM records accurate requires active maintenance by the number’s owner or their service provider.

How a CNAM Lookup Works

The CNAM lookup process, commonly called a “CNAM dip,” follows a consistent pattern regardless of the underlying protocol.
When an originating caller dials a number, their carrier sends the call toward the terminating carrier. The signaling includes the calling party’s number (CLID, or Calling Line Identification) but does not include the caller’s name. The name is not carried in the call setup; it must be retrieved separately.
Before presenting the call to the recipient, the terminating carrier’s equipment performs a CNAM dip. It takes the calling number and queries a CNAM database to retrieve the associated name. If a match is found, the name is attached to the call and displayed on the recipient’s device. If no match is found, the phone typically shows “Unknown” or just the bare number.
This entire lookup happens in milliseconds, completing before the recipient’s phone begins to ring. The query methods vary by implementation:

SIP

A modern integration method where the terminating equipment sends a SIP request to a CNAM provider, such as TransNexus ClearIP, which returns the caller name in the SIP response. This approach leverages existing SIP infrastructure, requires no additional protocol stacks, and integrates naturally into IP-based voice networks. SIP-based CNAM is increasingly adopted by carriers migrating away from legacy SS7 dependencies.

HTTP/HTTPS

Another modern approach where the terminating equipment sends a REST-style query to a CNAM provider’s API, passing the calling number and receiving the name in the response. This method is widely used in VoIP and SIP-based networks and is straightforward to implement, requiring only standard HTTP client capabilities.

TCAP over SS7

The traditional method where the terminating switch sends a Transaction Capabilities Application Part (TCAP) query over SS7 signaling to a CNAM database. This is the method used by legacy PSTN carriers and remains present in hybrid networks where SS7 infrastructure is still operational. However, the industry trend is moving away from TCAP-based CNAM toward IP-based query methods (SIP and HTTP/HTTPS) as carriers modernize their networks.
Other methods include ENUM (DNS-based lookup), SIP SUBSCRIBE/NOTIFY, and SOAP/XML APIs, though these are less common in production deployments.
CNAM dips carry a per-query cost. Typical rates range from $0.002 to $0.006 per lookup. For high-volume carriers processing millions of calls per month, these costs add up, making selective CNAM querying (deciding which calls require a dip and which do not) an important operational consideration.

CNAM, CLID, and STIR/SHAKEN: How They Fit Together

CNAM is one component in a broader caller identity stack. Understanding how it relates to the other pieces helps service providers design a coherent identity and trust framework.

CLID (Calling Line Identification)

CLID refers to the phone number itself. In SIP, it is carried in the From header or the P-Asserted-Identity (PAI) header. CLID tells you the number that originated the call.

CNAM

CNAM is the name associated with that number. It is retrieved by the terminating side via a database lookup. CNAM tells you who that number supposedly belongs to.

STIR/SHAKEN

STIR/SHAKEN provides a cryptographic framework that attests whether the calling number is legitimate. The originating carrier signs the call with a digital certificate, and the terminating carrier verifies the signature. STIR/SHAKEN does not provide a name; it provides an attestation level (A, B, or C) indicating how much the originating carrier can vouch for the call’s authenticity.
The practical distinction matters: CNAM tells you the name, and STIR/SHAKEN tells you whether to trust it. A spoofed call could carry a legitimate-looking CLID that returns a valid CNAM name, but STIR/SHAKEN verification would flag it with a low attestation level (or fail verification entirely). Used together, CNAM and STIR/SHAKEN give the terminating carrier both identity information and a trust signal.
Looking ahead, Rich Call Data (RCD) and Branded Calling initiatives are extending beyond CNAM’s 15-character limit. These technologies, still in early deployment, allow verified callers to deliver logos, business names, and call-reason descriptions directly to the recipient’s device. Service providers building voice infrastructure today should account for all three layers: CNAM for baseline name delivery, STIR/SHAKEN for authentication, and a path toward branded calling for enhanced trust displays.

Where the SBC Fits in CNAM Delivery

For service providers, the Session Border Controller (SBC) is the natural execution point for CNAM lookups. The SBC sits at the network edge, processing every inbound and outbound call. It has access to the call’s signaling data (including the calling number), and it can modify the call’s SIP headers before forwarding it downstream.

Peering SBC Deployment

The SBC receives calls from interconnected carriers. When operating as the terminating carrier, the SBC performs the CNAM dip before routing the call to the next hop, whether that is an IP-PBX, a softswitch, or a subscriber endpoint. The SBC queries the CNAM database, receives the caller name, and writes it into the SIP display name field so downstream equipment and end-user devices can present it.

Access SBC Deployment

The SBC sits between the service provider’s core network and the subscriber edge. CNAM information may already be present in the call’s signaling (populated by an upstream element), or the access SBC may perform the lookup itself if the network architecture places that responsibility at the edge.
The key advantage of performing CNAM at the SBC is control. The SBC can decide, on a per-trunk or per-call basis, whether to perform a CNAM dip, which database to query, and how to handle lookup failures. This granularity matters for cost management (skipping dips on trusted internal trunks) and for quality (falling back gracefully when a CNAM provider is unreachable).

How ProSBC Handles CNAM Lookups

ProSBC integrates CNAM lookups directly into its programmable Ruby routing engine. Rather than treating CNAM as a static configuration toggle, ProSBC exposes it as a filter in the call routing chain, giving operators fine-grained control over when, how, and for which calls CNAM dips occur.
ProSBC supports IP-based CNAM query methods: SIP, HTTP, and HTTPS. ProSBC does not support CNAM dipping via TCAP over SS7, as it is a fully IP-native platform designed around modern signaling protocols.

SIP-Based CNAM with TransNexus ClearIP

ProSBC’s primary CNAM integration uses SIP to query TransNexus ClearIP. When a call hits the routing engine, the filter sends a SIP-based CNAM query to ClearIP, which returns the caller name in the SIP response. On receiving the response, the filter writes the returned caller name into the call’s calling_display field, which maps to the SIP display name seen by downstream equipment. The filter uses an asynchronous return-to-script mechanism so that routing does not block while waiting for the database response. This SIP-based approach leverages existing SIP infrastructure and requires no additional protocol stacks.

HTTP/HTTPS CNAM Queries

ProSBC also supports CNAM lookups via HTTP/HTTPS REST APIs. This is a straightforward integration method where the routing engine sends an HTTP request to a CNAM provider’s API endpoint, passing the calling number and receiving the caller name in the response. HTTP-based CNAM is easy to implement and works with any CNAM provider that offers a REST API.

TNS Dip Integration

For carriers that use Transaction Network Services (TNS), ProSBC’s routing engine supports combined database dips via SIP. A single routing script can handle LNP (Local Number Portability), Toll-Free, and CNAM queries together. The NAP-level dip configuration column controls which dip types are active for each trunk group. Setting it to CNAME triggers only CNAM queries; setting it to ALL triggers LNP, Toll-Free, and CNAM in sequence. Setting it to NONE skips dips entirely. Note: TNS currently supports CNAM dipping via TCAP over SS7 only; SIP-based CNAM support from TNS is planned but not yet available.

Per-NAP Control

Network Access Points (NAPs) in ProSBC represent trunk groups or SIP peers. CNAM behavior is configurable per NAP, so operators can enable CNAM dips on trunks carrying external traffic while disabling them on internal or trusted trunks where the caller identity is already known. This keeps query costs under control without sacrificing coverage where it matters.

Duplicate Query Prevention

The routing engine automatically disables the CNAM service for a call after the first successful response, preventing unnecessary repeat queries if the call passes through multiple routing stages.
ProSBC’s approach differs from SBCs that offer CNAM as a binary on/off switch at the system level. The per-NAP, per-call programmability means operators can implement nuanced policies: query CNAM for calls arriving on carrier interconnects, skip it for calls from known enterprise customers, and apply different CNAM providers to different trunk groups based on cost or coverage.

Best Practices for Service Providers

Choose Your CNAM Database Provider Based on Coverage

Because no single CNAM database contains every number, the provider you query directly affects the percentage of calls that return a valid name. Some providers aggregate data from multiple LIDBs for broader coverage. Evaluate providers based on match rate for your traffic profile, not just per-dip cost.

Monitor Dip Costs at Scale

At $0.002 to $0.006 per query, a carrier handling 10 million calls per month could spend $20,000 to $60,000 annually on CNAM dips alone. Use per-trunk CNAM control (as ProSBC provides) to avoid querying on trunks where it is unnecessary. Negotiate volume-based pricing with your CNAM provider.

Be Deliberate About Caching

Some providers cache CNAM results locally to reduce the number of external queries. Caching lowers cost but introduces staleness: a subscriber who changed their name or ported their number may still show the old CNAM entry until the cache expires. Set cache TTLs based on your tolerance for stale data.

Combine CNAM with STIR/SHAKEN

CNAM without authentication is a name without proof. If your network supports STIR/SHAKEN signing and verification, pairing it with CNAM gives your subscribers both a name and a trust indicator. ProSBC supports both STIR/SHAKEN (via its signing/verification modules) and CNAM in the same routing chain.

Plan for the Evolution to Branded Calling

CNAM’s 15-character limit was designed for an era of small phone screens and circuit-switched networks. Rich Call Data and branded calling platforms deliver logos, full business names, and call-reason text. While CNAM remains the baseline, service providers should ensure their SBC and downstream infrastructure can pass through enhanced caller identity data as these standards mature.

Keep CNAM Records Accurate for Your Own Subscribers

As an originating service provider, you are responsible for maintaining the CNAM entries associated with the numbers you assign. Inaccurate CNAM data erodes trust in the entire system and can lead to your numbers being flagged by downstream analytics engines.

CNAM and FCC Regulations

The FCC’s Truth in Caller ID Act prohibits transmitting misleading or inaccurate caller ID information with the intent to defraud. While this primarily targets spoofing, it underscores the regulatory environment around caller identity, of which CNAM is a key component.
The STIR/SHAKEN mandate, which the FCC began enforcing in 2021, complements CNAM by requiring service providers to authenticate calling numbers using digital certificates. STIR/SHAKEN does not replace CNAM, but it provides the authentication layer that CNAM lacks.
More recently, the FCC has explored extending caller identity beyond CNAM through call branding initiatives. A 2025 Further Notice of Proposed Rulemaking examined frameworks for delivering verified business identity information (including logos and business names longer than 15 characters) to consumers. Service providers should monitor these proceedings, as future rules may require SBC-level support for richer caller identity data.

Conclusion

CNAM is foundational voice infrastructure. For service providers and carriers, it is not a feature to toggle on and forget. It is a per-call operation that affects subscriber experience, operating costs, and regulatory compliance.
The SBC, as the network edge element processing every call, is the right place to execute CNAM lookups. ProSBC makes this practical with its programmable routing engine, where CNAM queries are filters in the call chain, configurable per trunk group, combinable with LNP and Toll-Free dips, and integrated alongside STIR/SHAKEN attestation.
Whether you are deploying CNAM for the first time or optimizing an existing implementation, ProSBC’s per-NAP control and Ruby-based routing scripts give you the flexibility to match your CNAM strategy to your traffic profile and cost targets.

Frequently Asked Questions