"Why does our caller ID show the wrong number?" is one of the most common Direct Routing complaints — and one of the most misunderstood, because what the callee sees and what the network routes on are two different things, controlled in different places. In Teams Direct Routing there are three layers: Teams configuration, SBC header manipulation, and the carrier's CNAM database. Fixing caller ID means knowing which layer is wrong.
Layer 1: Teams — Where the Number Is Assigned
Every Teams voice user has a LineURI — their E.164 phone number. That number, plus the tenant's CallingLineIdentity policy settings, determines what Teams puts in the call's caller-ID fields when the call leaves toward your SBC. For shared and service scenarios (conference rooms, lobby lines, call queues, auto attendants), resource accounts carry their own numbers, and the policy can be set to display a service number instead of the calling user's DID.
What Teams sends downstream is well-defined. The problems almost never start here.
Layer 2: The SBC — P-Asserted-Identity vs. From
Between your SBC and the carrier, two SIP headers carry caller identity:
- From header — the identity as presented by the caller; user-modifiable in principle
- P-Asserted-Identity (PAI) — the network-trusted identity, asserted after authentication; this is what carriers actually route and bill on
Your SBC's header manipulation rules decide what your carrier receives: pass Teams' values through, rewrite the From to a masked main number, set the PAI to a billing DID, add or remove the Privacy header. The classic enterprise patterns:
- Mask to main number — agents' calls present the company's public number instead of individual DIDs
- Per-user DIDs — every user presents their own direct number (default, and what most companies actually want now that mobile callers don't answer unknown numbers)
- Service numbers for queues — auto-attendant and callback lines present a single published number
Layer 3: CNAM — The US-Specific Trap
In the United States, the name your callee sees usually doesn't come from your call at all. It comes from the terminating carrier dipping a CNAM database (LIDB records) keyed to the calling number. Two consequences:
- Your PAI must be a number you own — the dip is against that number, so presenting a number with no CNAM record shows a bare number or "Unknown Caller"
- CNAM is registered per-number through your carrier, not configured on the SBC — if names display wrong or missing, fix the registration, not the headers
This is why "we set the caller ID on the SBC but the name still shows wrong" is the standard help-desk ticket: header manipulation and CNAM registration are separate fixes. Outside the US, presentation conventions differ (often no CNAM equivalent at all), which matters for multinational deployments.
The Security Side: Caller ID Is an Attack Surface
Whatever flexibility you give the SBC to assert identity, an attacker who reaches it gets too. Two disciplines are non-negotiable:
- Number inventory enforcement — the SBC should only be permitted to present numbers from your owned inventory; reject or rewrite anything else at the carrier edge, and your carrier should enforce this too
- Strict SIP ACLs — only Microsoft 365 signaling IPs inbound, only your carrier's IPs on the trunk side, TLS on everything, with certificate validation
Unrestricted PAI manipulation plus an exposed SBC is the classic recipe for toll fraud: a weekend of calls to premium-rate numbers, billed to you. For the trust-store and certificate side of SBC hardening, see our SBC trust-store audit.
The E911 Interplay
Emergency calls are the exception to every caller-ID rule: they must present the real callback number and, with dynamic location, the dispatchable location (PIDF-LO). Masking rules must never apply to emergency patterns, and Kari's Law front-desk notification applies on top. Getting the emergency path right while also getting commercial presentation right is the acid test of a caller-ID configuration. The details are in our E911 compliance guide.
A Practical Test Plan
- Call your own mobile from a representative user in each policy group — check number and displayed name
- Test a masked service number and a per-user DID on the same carrier, and one cross-carrier call (CNAM behavior differs by terminating carrier)
- Test an emergency call path with your PSAP's non-emergency line (never test by dialing 911 directly)
- Verify international calls present +E.164 correctly
If your caller ID is wrong in a specific, repeatable way, the layer tells you the fix: wrong number → Teams (LineURI/policy); wrong name → CNAM registration with your carrier; inconsistent across carriers → SBC header manipulation. If it's wrong in a general way, that's a configuration audit — we do those.