ANI vs DNIS vs CNAM: Caller ID Signals for Forwarded Calls

ANI is the caller’s number and DNIS is the number they dialed. CNAM is the caller’s name that the receiving carrier may look up. This guide explains ANI vs DNIS vs CNAM in plain English. On forwarded calls, ANI controls whether agents see the original caller ID, and it drives caller-based rules. DNIS maps the call to the right campaign or menu, and CNAM (where supported) is only a display name on the agent’s side.

ANI vs DNIS vs CNAM: what they actually are

ANI (automatic number identification, the caller’s phone number in call signaling) is the most reliable input for any rule that cares about who is calling. You use ANI for things like duplicate-caller suppression, VIP or block lists, and routing by the caller’s state or area code.

DNIS (dialed number identification service, the number the caller dialed) links the call to the business line, ad group, brand, or IVR (an automated phone menu) entry point. If you run four campaigns, you point each to its own DNIS so reports and menus line up with the source.

CNAM (caller name, the display name pulled from a database by the receiving carrier based on the caller’s number) is not the number itself. It’s a separate lookup tied to ANI. CNAM name display is mainly a US and Canadian behavior. Many other countries show number-only on inbound calls and don’t offer a network CNAM name at all.

How these three travel through a forwarded call

Keep one picture in mind. A customer dials 888-200-1234. Your platform receives the call, then forwards it to an agent’s mobile. On the inbound leg (caller to your business number), ANI is +1 312-555-0199 and DNIS is 888-200-1234. On the outbound leg (platform to the agent), the platform tries to pass the same ANI (+1 312-555-0199), so the agent sees the original caller number. In the US and Canada, the agent’s carrier may also look up a name (a CNAM dip) based on that number. Outside those markets, the phone will likely show the number only.

Some devices show both signals. SIP phones (internet phones) and browser agents (a web phone in your browser) often display the caller number and the dialed number on screen, so an agent can see “From: +1 312-555-0199” and “To: 888-200-1234.” Many mobiles show only one number. You’ll see the original caller if ANI passthrough works, or your business number if the destination network blocks non-local caller ID.

Where does caller ID fail? The outbound leg runs through the agent’s mobile carrier or PBX (office phone system), and those networks sometimes restamp caller ID for policy or anti-spoofing reasons. If that happens, the agent will see your business number as the caller. For a deeper look at passthrough and when carriers restamp the caller ID, see cloud forwarding caller ID basics and the common fixes in forwarded caller ID shows wrong number.

Routing and analytics: which signal drives what

Use DNIS to pick the front door and context. When a call hits 888-200-1234, you already know which brand, ad group, or IVR branch it belongs to because that number is dedicated to a purpose. The platform should load the right menu and call flow based on DNIS. If you split by product line, give each a distinct DNIS so your reporting stays clean.

Use ANI for anything tied to the person who called. Caller-based routing (state or area code rules), duplicate-caller windows, daily or concurrent caps per target, VIP routing, and blocklists all work best on ANI because it is the caller’s number. If a pay-per-call buyer only wants one call per unique person over a set period, enforce that with your duplicate-caller rule on ANI. If a customer called three times today, ANI tells you it’s the same person so your suppression and caps hold.

Don’t use CNAM for routing or billing. Names are inconsistent across carriers and countries, and even in the US and Canada a mobile may show a contact or app-sourced name instead of a network dip. CNAM is for display only.

For reporting, group by DNIS to see source and campaign performance. Then analyze by ANI area code or state for geography and buyer mix. Keep both fields in your call logs. This supports clear attribution (DNIS) and clean buyer delivery (ANI) at the same time. If you’re deep into pay-per-call, buyers care about unique callers measured on ANI, while you attribute spend by DNIS. For more on reading the numbers, see call analytics that matter.

What agents see when you forward calls

You choose between two display modes. Mode one: show the original caller number (ANI) to the agent. That gives context for callbacks and matches what the customer expects. Mode two: show the business or campaign number (DNIS) to the agent. That tells them which line rang, which can help with scripts, but makes a one-tap callback tricky because the phone will try to call your own number.

If your agent sees your own number instead of the caller, one of three things likely happened. The terminating network blocked or rewrote non-local caller ID for policy reasons. A PBX on the agent side overwrote the display with its own rules. Or the forwarding was set at the carrier level using a star code (like *72), which can restamp caller ID to the forwarded line on some networks. In all three cases, the fix is to pass ANI from the platform and use a destination that allows it. When you need a walkthrough, start with why forwarded calls show the wrong caller ID.

CNAM names come from the agent’s carrier or the phone’s contacts, not from your forwarding platform. On many mobiles, you’ll get number-only or a name from an app. Also, “Spam Likely” is a spam score shown by the terminating carrier or app, not CNAM. If that appears, the number needs separate reputation work outside this topic.

Pass ANI to the agent for clean callbacks. Add a short whisper (a brief audio played to the agent before connect) that says the campaign or IVR info. For example, “Google Ads—Appliance Repair” or “Press 1—Sales.” If you must show DNIS to drive the script, teach agents to use the CRM pop for the caller’s number. As an aside, CallFlow lets you pass ANI to phones, SIP endpoints, or browser agents, and add an optional whisper for context; see the setup notes in call whisper messages.

Country specifics and CNAM limits

In the US and Canada, landlines often perform CNAM dips and show a name when available. Many mobiles rely on contacts or apps for names, so you may see a number-only display or a crowd-sourced label instead. Treat any name as best-effort, not a guarantee.

Outside the US and Canada, including India, the Philippines, Thailand, Bangladesh, and Pakistan, networks usually display the number only. CNAM is not a standard feature. Plan routing and QA around the numbers you can control: ANI for caller identity and DNIS for source. Teach teams to use numbers, not names, for callbacks and notes.

International forwarding adds one more wrinkle. Some carriers replace the original ANI with a verified or local number to meet policy or to raise answer rates. Expect this on certain cross-border routes, and test before launch. Where you can, use direct SIP or a browser agent to keep ANI intact.

Toll-free originations are another edge case. CNAM for toll-free outbound often shows as blank or generic on the far side. Do not rely on a toll-free CNAM name for identification. If identity matters, pass the ANI and use a whisper to give agents the campaign.

Test caller ID end to end (a quick checklist)

1. Place two test calls from different numbers to your business line (one local, one out-of-area or international if you serve cross-border traffic).
2. Watch live logs while the call rings. Confirm “caller/ANI” shows the test number and “dialed/DNIS” shows the business number. If your platform has detailed CDRs (call detail records), open them too.
3. Answer on the target device and note what it displays. If possible, grab a screenshot.
4. Compare device types: repeat to a SIP or browser agent, then to a mobile and a desk phone. Note if one shows ANI while another shows DNIS.
5. If you forward internationally, place a test from abroad and to an agent abroad. Check for ANI restamping or number replacement on the outbound leg.
6. Retry the same call flow to an alternate target type (e.g., SIP instead of mobile, or a different mobile operator). See if ANI passthrough improves.
7. Listen to the call recording and confirm any agent whisper plays as set. Make sure it’s short and clear.
8. Save screenshots and export CDRs so you can compare what the logs say (ANI and DNIS) with what the agent saw. This speeds up any escalation.

A pass looks like this. Logs show caller = ANI and dialed = DNIS for every call. The agent’s device shows the mode you picked (ANI or DNIS). Recordings include the whisper if you enabled one. If you see a persistent ANI rewrite on one destination, switch the destination type (to SIP or a browser agent, or to another mobile operator) and test again. If the issue stays on that one path, contact support with timestamps, your call logs/CDRs, and the screenshots.

Put the right caller ID on your next call

Pick your display mode: show ANI to make callbacks easy, or show DNIS when agents must see the campaign line. Add a short whisper for context, keep it under two seconds, and route with ANI for geo and duplicate suppression while using DNIS to map campaigns. Re-run the test calls across device types and, if you operate cross-border, across countries.

You can set this up in minutes: create a number, choose your display mode, and route to phones, SIP, or browser agents. If you want to try it now, you can register. If you prefer help from an engineer, reach out at contact us.