What is caller ID, and how does it work on my trunks?

Most people think caller ID is “whatever shows on the screen”. On a PBX, it is a set of numbers, names, and headers that must line up correctly.

Caller ID is the calling party identity your PBX sends or receives on trunks, mainly as a number (ANI/CLI) and sometimes a name (CNAM), carried in SIP or legacy signaling and shaped by your routing and provider policies.

When caller ID is clean, agents know who is calling, VIP rules work, STIR/SHAKEN call authentication ¹ holds up better, and return calls connect. When it is broken, you see “Unknown”, calls get flagged as spam, or carriers silently rewrite your numbers. So it is worth understanding how it really works inside the PBX and on your SIP trunks.

How do CNAM, ANI, and CLI differ for me?

Most documentation throws three or four acronyms at you and assumes they are obvious. They are not, especially when different carriers use different terms.

ANI/CLI is the caller’s number that drives routing and billing. CNAM is the display name the far end looks up. On SIP trunks, your PBX mostly controls the number, while the callee’s side controls the name.

Breaking down the identities

In day-to-day work, I map the terms like this:

In the US and Canada, Calling Name (CNAM) databases ³ are typically controlled by carriers and analytics ecosystems, not by whatever label you type into your PBX.

For your PBX and SIP trunks, the number is king. Routing, fraud checks, and STIR/SHAKEN all care about the number. The name is a nice bonus that usually arrives later.

How this plays out on SIP trunks

On SIP:

• Your PBX puts the caller number in the SIP From header ⁴ and, for trusted networks, in the P-Asserted-Identity (PAI) header ⁵.
• The trunk provider reads PAI as the “real” CLI if you are authenticated.
• The provider may rewrite From to follow their policies.

On inbound calls:

• Your PBX reads the number from From or PAI and shows it to phones.
• CNAM is often added by the terminating carrier via a database dip. Your PBX does not send the name; the far side does.

So if someone asks, “Why does the caller name look wrong when we call US mobiles?” the answer is usually: their carrier looked up our number in their CNAM database, not whatever label we put on the PBX.

Why this matters for routing and analytics

Once I see ANI/CLI as “the truth” and CNAM as “decoration”, design decisions get easier:

• Block or prioritize callers by number, not name.
• Normalize CLI to E.164 (+country) format ⁶ inside the PBX.
• Treat CNAM as something that may differ per country and carrier.

A simple internal rule like “all outbound numbers should look like +CCNNNN…” avoids so many weird reports, especially when I have multiple SIP trunks and regions involved. The PBX then adapts to each carrier, but internally, caller IDs stay consistent.

Can I set caller ID per extension, queue, or DOD?

If every outbound call shows the same main number, sales lose local presence and support loses context. If every extension shows its raw DID, brand control suffers.

Yes. You can set caller ID per extension, queue, or DOD by combining per-user settings with outbound routes and trunk rules, as long as your provider approves those numbers.

Where caller ID can be set

A typical PBX has several layers that can touch outbound CLI:

In practice, the trunk’s policy is the last word. If you send a number that is not on your account or not verified, the provider can replace it or block the call.

Per-extension and DOD-based caller ID

For normal users, I often tie caller ID to:

• Their DID when personal callbacks matter.
• A department number (sales, support) when I want a shared identity.
• A brand or tenant number in multi-company deployments.

Direct Outward Dialing (DOD) settings ⁷ help lock this down: when an extension uses a certain route, the PBX forces its outbound CLI to a specific number. This is perfect when you run multiple brands or tenants on one system and want each extension to present the right company number.

A simple mapping table:

Queue and campaign level caller ID

For contact center work, queues and campaigns become the main handle:

• Outbound campaigns use local numbers per region or per ad source.
• Queue callbacks show the same number customers just saw in SMS or on the website.
• VIP queues can show more familiar numbers to increase answer rates.

The PBX can stamp caller ID based on which queue or campaign owns the call, not just which agent pressed dial. That keeps brand and compliance rules under central control, while agents just work.

I also keep a special emergency caller ID in the PBX. For 911 or local emergency codes, that number overrides everything else and points to a location-appropriate DID, even if the user’s normal DOD says otherwise.

How do STIR/SHAKEN impact my caller ID trust?

You can set caller ID perfectly on your side and still get “Spam Likely” labels or lower answer rates if upstream networks do not trust your identity.

STIR/SHAKEN adds a signed Identity header with an attestation level to your calls. It helps carriers and phones judge if your caller ID is real, which directly impacts how calls are labeled or blocked.

What STIR/SHAKEN actually signs

At a high level:

• The originating carrier signs the call with a private key.
• The signature includes the caller number, the called number, and an attestation level.
• Downstream carriers verify the signature with a public certificate.

The three attestation levels are usually:

Higher attestation, especially A, gives your calls a better chance to pass analytics without being flagged or downgraded.

What you control versus what the carrier controls

As a PBX admin, I do not sign the calls myself in most setups. Instead, I:

• Make sure I send clean, consistent caller IDs.
• Use numbers that belong to me and are correctly registered with the carrier.
• Avoid behavior that looks like spam (flash calls, very short high-volume bursts).

The carrier then decides:

• Which attestation level to assign to your calls.
• Whether to sign at all for a given trunk or route.

If you present numbers that do not match your account, many carriers will:

• Replace the CLI with a default main number.
• Or still send your number, but with lower attestation or more strict analytics.

How this affects what people actually see

Terminating carriers combine:

• STIR/SHAKEN verification results.
• Their fraud analytics and reputation data.
• Local laws and policies.

Based on that, they might:

• Let the call pass with normal presentation.
• Mark it as “Verified”, “Potential spam”, or “Spam likely”.
• Block it at the network level.

So, if your outbound caller ID setup causes low trust, you can see perfect CDRs on your side, while customers see almost no calls because their carriers drop them before your PBX ever hears about it on the return path.

The fix is usually:

• Align all outbound numbers with what your trunk provider has on file.
• Ask the provider about their STIR/SHAKEN support and attestation policy.
• Clean your traffic patterns so you do not look like a robocaller from the outside.

Why does my outbound caller ID show “Unknown”?

Sometimes the PBX shows everything correctly, but the far side only sees “Unknown”, “Private”, or even the wrong country. This can feel random unless you know where the ID got lost.

Outbound caller ID shows “Unknown” when your PBX sends no valid CLI, your provider rewrites or strips it, or privacy and format rules cause the terminating side to hide or drop it.

Common root causes by layer

I like to check from inside out:

On the PBX:

• Make sure the extension, queue, or route actually sets a number.
• Normalize everything to a clear format (commonly E.164) before sending it out.
• Verify in SIP traces that the desired CLI is in P-Asserted-Identity and From.

On the trunk side:

• Confirm the numbers you send are on your account and allowed for outbound use.
• Some carriers require you to explicitly register DIDs as “outbound caller IDs” before they will present them.

Special behaviors: privacy, emergency, and international

Privacy features can override everything:

• Dial prefixes like *67 (in some countries) or PBX privacy options can anonymize the call.
• In SIP, Privacy headers plus From: anonymous tell carriers to hide the number.

Emergency calling is the opposite:

• The PBX should override normal caller ID with a fixed emergency location number.
• Carriers often enforce emergency CLI policies that ignore per-extension settings.

International routes can change CLI in unexpected ways:

• Some paths do not preserve full CLI; they might replace it with a generic gateway number.
• Some countries block or modify foreign numbers that do not match local patterns.

A practical troubleshooting checklist

When someone says “Our number shows as Unknown,” I usually:

1. Capture a SIP trace on the PBX and check: what number and headers did we actually send?
2. Ask the trunk provider what they saw from us, and what they handed off.
3. Test with another destination (another mobile, another carrier) to see if the issue is local or general.
4. Check PBX privacy and class-of-service rules that may strip or replace CLI.

Most of the time, the fix is small: send the right format, use a permitted number, or turn off a local privacy override. Once those are correct, “Unknown” turns back into a proper, trusted caller ID that matches your brand and routing policies.

Conclusion

Caller ID is more than a label on the phone; it is a chain of numbers, headers, and policies that must align from your PBX through every trunk if you want calls to be trusted and answered.

Footnotes