Calling line identification travels through several systems before a phone renders caller ID. Each system can authorize, normalize, restrict, replace, verify, or enrich the identity. Technical teams need to know which value they set, which value a carrier trusts, and which value the recipient finally sees.
What is calling line identification?
Calling line identification (CLI) is the number information associated with the party that starts a telephone call, together with a status that controls whether the number may be presented to the recipient. The everyday result is caller ID: a phone shows a number, a name, “Private,” or “Unknown” while the call is being established.
CLI identifies a line or number. It does not authenticate the person speaking, prove a call is legitimate, or guarantee what appears on the recipient’s device. A shared line can represent several people. An authorized business may present a central callback number instead of an agent’s extension. A bad actor may submit a false number where the network does not validate the claim.
The term also needs one qualifier. In some standards and markets, CLI can mean either calling line identification or connected line identification. Calling CLI describes the originating side. Connected line identification describes the line that ultimately answers, which can differ from the number dialed after forwarding. The ICO’s line-identification guidance makes this distinction explicit.
For a production voice application, CLI sits at the boundary between application configuration and telecom policy. You select an authorized number and presentation preference. Your SIP provider decides whether that identity is permitted. Intermediate and terminating networks carry and evaluate it. The receiving carrier and device determine the final display.
Accurate CLI does not establish permission to place the call. Consent, suppression, disclosure, and timing requirements remain separate campaign controls and depend on jurisdiction and purpose.
We make that boundary explicit in Dasha. You can connect a carrier over SIP and link an authorized phone number to an agent, while the carrier retains control of its downstream CLI policy. Use that control boundary when you compare SIP trunk providers: number authorization, identity signing, trace access, route coverage, and support belong in the evaluation.
The two identities behind one caller-ID display
A useful model separates the number that identifies the network origin from the number intended for presentation. UK telecom guidance calls these the Network Number and Presentation Number:
- Network Number: identifies the call’s origin within the provider chain.
- Presentation Number: identifies the caller to the recipient and supports a return call.
- Privacy marking: states whether presentation is allowed, restricted, or unavailable.
The two numbers are often equal. They can differ for legitimate reasons. A company may originate calls from several sites while displaying one published support number. A contact center may call on behalf of several businesses. A professional may use a business callback number rather than expose a private line. Ofcom’s CLI guidance describes this separation and requires UK providers to handle valid, dialable CLI data and privacy choices. Those requirements are UK-specific. Other jurisdictions define their own permitted numbers, privacy rules, and provider duties.
In a Session Initiation Protocol (SIP) call, these roles often map to different headers:
Fromcarries the initiator’s logical identity and can include a display name. RFC 3261 allows a user agent to populate it, so its contents alone are only a claim.P-Asserted-Identitycarries an identity asserted by a trusted network element. RFC 3325 defines it for trusted SIP networks and allows proxies to add or remove it.Privacyand related provider policy determine whether asserted identity may leave the trusted domain or reach the called user.
This mapping is common rather than universal. Carriers publish their own SIP profiles, and a session border controller can normalize headers at the interconnection boundary. Treat the provider’s profile and an actual SIP trace as the contract.
How calling line identification works in VoIP
CLI moves in signaling while the call is being set up. Audio usually takes a separate Real-time Transport Protocol (RTP) path after both sides negotiate media.
1. The application selects an outbound identity
The application or private branch exchange (PBX) selects a business number for the call. The number might belong to the provider, arrive through number porting, or be authorized for use with a bring-your-own-carrier setup. The application places it in the provider-supported outbound field, often as the user part of From.
2. The originating provider authenticates the customer
The provider authenticates the trunk by source IP, SIP credentials, registration, or another contracted method. It checks whether the account may present the requested number. A verified relationship between the customer and the number is separate from SIP authentication. Valid trunk credentials do not grant permission to use every telephone number.
3. The provider constructs the network identity
The originating provider can accept, normalize, replace, or reject the application’s value. It may create an asserted identity for the trusted network, preserve a separate presentation identity, and attach the applicable privacy state. Number normalization often converts a national format into the provider’s expected international format.
4. Intermediate networks apply interconnection policy
SIP trunks, gateways, and older circuit-switched segments can translate identity fields. Headers may be rewritten or stripped when a trust boundary changes. A transfer or forwarded call can also add diversion history, leaving several relevant numbers in the trace.
5. The terminating provider evaluates the call
The recipient’s provider checks number syntax, privacy state, call-authentication results where available, routing context, and its own abuse controls. It may block the call, label it, withhold the number, or pass identity data to the device.
6. The device renders caller ID
The phone receives the presentation result. A contact match, carrier name lookup, caller-name database, or branded-calling service can enrich that result. The screen is therefore a rendered experience, not a raw copy of one SIP field.
The practical lesson is simple: seeing the expected value in your outbound From header proves only what your application sent. It does not prove what the originating carrier accepted or what the destination displayed.
CLI, CLIP, and CLIR
Three related terms describe identity and its treatment:
| Term | Meaning | What happens at the recipient |
|---|---|---|
| CLI | Calling Line Identification, the calling party’s line or number identity plus presentation status | Supplies the identity data that may be presented |
| CLIP | Calling Line Identification Presentation | Permits the called party to receive the calling identity when policy allows |
| CLIR | Calling Line Identification Restriction | Requests that the calling identity stay hidden from the called party |
ITU-T defines CLIP and CLIR signaling as separate number-identification supplementary services. CLIR affects presentation. Provider systems may still retain the originating identity for routing, billing, abuse investigation, or emergency handling according to the network and applicable law.
“Presentation restricted” and “number unavailable” also mean different things:
- Presentation restricted means an identity exists, but policy or the caller’s privacy choice prevents the recipient from seeing it.
- Number unavailable means the terminating side has no usable number to present. The cause may be missing data, an interworking limitation, invalid formatting, or a network policy decision.
Do not collapse these states into an empty string. They have different operational and privacy meanings.
CLI compared with other caller identity terms
CLI is one input to a larger caller-identification system.
| Term | What it represents | What it does not prove |
|---|---|---|
| Caller ID | The recipient’s rendered number, name, privacy state, and sometimes a warning or brand cue | The raw value sent by the originating application |
| Calling Name (CNAM) | A caller-name lookup used in parts of the North American ecosystem | Number ownership, universal name display, or call legitimacy |
| Branded calling | Enriched identity such as a verified name, logo, or call reason through participating providers and devices | Universal support or permission to place the call |
| Automatic Number Identification (ANI) | A distinct network service historically used to carry a billing or originating number for toll and access calls | The same presentation and privacy behavior as caller ID |
| Dialed Number Identification Service (DNIS) | The number the caller dialed, used to identify the destination, campaign, queue, or service | The caller’s identity |
| Secure Telephone Identity Revisited and Signature-based Handling of Asserted information using toKENs (STIR/SHAKEN) | A framework that signs and verifies information about a caller-ID claim and the originating provider’s relationship to it on supported IP paths | That the caller’s purpose is lawful or that the call is safe |
The distinction between ANI and caller ID matters. The FCC described ANI as a similar but distinct service that carried a billing telephone number for toll and access calls. Modern products sometimes use the label more loosely, so check the carrier’s data contract before mapping an “ANI” field into customer identity.
STIR/SHAKEN strengthens number authentication. It uses a signed SIP Identity header so a terminating service can validate what an originating service provider attested about the calling number. The underlying SIP identity standard also states that an unsigned From value is vulnerable to impersonation. RFC 8224 defines the cryptographic mechanism.
Authentication still has a narrow meaning. It says something about the provider, call origin, and right to use a number at a given attestation level. It does not bless the conversation or the caller’s intent. The FCC’s STIR/SHAKEN guidance warns that improved caller-ID information does not mean the call itself is legitimate.
How CLI works in an AI calling application
An AI voice product needs CLI in both directions, with different trust rules.
Outbound calls
For outbound calls, link each agent, tenant, or campaign to an authorized callback number. Keep the authorization record outside the model. The model should never invent or select an arbitrary From value.
Apply policy before call creation:
- Choose the destination and calling jurisdiction.
- Select a number the organization has the right to use.
- Confirm that the carrier permits that number on the selected trunk and route.
- Set the requested privacy behavior.
- Store the campaign, tenant, number, and trunk relationship with the call record.
Number masking is a separate application pattern in which an intermediate number protects one or both parties’ real numbers. It still depends on authorized CLI and carrier policy.
Inbound calls
For inbound calls, CLI is useful for a tentative customer relationship management (CRM) lookup, language selection, routing, and callback context. Treat a match as a hint. A shared family line, recycled number, forwarded call, or spoofed presentation number can point to the wrong record.
Require a separate verification step before revealing private data or taking a sensitive action. Good controls include a knowledge factor, possession check, authenticated application session, or another workflow approved for the use case. “The number matched the CRM” is insufficient authentication.
Transfers need extra care. The new call leg may present the original caller, the transferring system, or a business callback number. Preserve the original call ID, application call ID, asserted identity, presentation identity, and diversion history so an operator can reconstruct what happened without trusting one field.
Why CLI does not display as expected
Start troubleshooting with evidence from each boundary. Compare the application request, the first outbound SIP message, the provider’s call detail record, a trace near termination when available, and the actual device display.
| Symptom | Likely causes | Check first |
|---|---|---|
| Recipient sees “Private” or “Restricted” | CLIR or a privacy flag is active; provider policy withholds presentation | Privacy, anonymized From, account-level privacy settings |
| Recipient sees “Unknown” or “Unavailable” | Identity is missing, malformed, rejected, or lost during interworking | From, asserted identity, number syntax, carrier rejection details |
| Recipient sees a different number | Provider default, unauthorized submitted number, trunk rewrite, transfer, or forwarded call | Number authorized on the trunk, first carrier trace, diversion headers |
| Correct number appears, but the name is wrong or absent | CNAM or another name source differs from the number presentation path | Carrier name-registration status and destination carrier behavior |
| One carrier displays the number and another does not | Terminating policy, regional interworking, route selection, or device support differs | Test matrix by destination network and device type |
| Call is rejected before ringing | Invalid or non-dialable number, unauthorized identity, route policy, or authentication failure | SIP response code, provider error, number ownership and formatting |
| Inbound CRM lookup selects the wrong customer | Shared, ported, recycled, forwarded, or spoofed number; duplicate records | Normalized number, match cardinality, separate identity check |
| Application trace is correct, device display is wrong | A downstream network rewrote, suppressed, or enriched the identity | Originating provider record and a destination-side test |
Formatting bugs deserve special attention. Store public numbers in an unambiguous canonical form such as E.164 where the provider supports it. Keep the leading + if the carrier profile requires it. Normalize for comparison, then retain the original received value for diagnostics. Emergency numbers, short codes, extensions, and private numbering plans need explicit exceptions.
Production checklist for accurate CLI
- Use owned or authorized numbers. Keep evidence of the organization’s right to use each number and the trunks on which it is permitted.
- Document every identity field. Record which field controls presentation, which field the carrier asserts, and which fields carry privacy or diversion data.
- Normalize at one boundary. Convert numbers according to the carrier’s SIP profile and reject ambiguous input before dialing.
- Preserve privacy states. Model “allowed,” “restricted,” and “unavailable” explicitly rather than treating all three as a missing value.
- Keep CLI out of authentication decisions. Use it to find a possible account, then run the approved identity check.
- Trace the complete setup path. Correlate the application call ID, SIP
Call-ID, provider record, and recipient observation. - Test representative routes. Cover mobile and fixed networks, multiple carriers, transfers, forwarding, voicemail, withheld identity, and invalid numbers.
- Monitor changes after launch. Alert on unexpected CLI rewrites, increased rejection codes, privacy-state changes, and mismatches between configured and presented numbers.
Calling line identification with Dasha
We let technical teams connect an existing carrier through SIP, create phone-number records, and link a number to an agent for inbound routing or outbound calling. The phone-number configuration keeps the number, SIP credentials, and agent link as separate objects. That separation makes the carrier boundary visible.
When presentation fails, we expose SIP traces for a call, including ordered messages and raw SIP content. You can inspect the outbound INVITE, relevant identity and privacy headers, response codes, addresses, and transport, then compare that evidence with the carrier record. Our SIP trunking guide provides the broader setup and testing workflow.
We control the fields we send on supported call paths. We cannot force a downstream carrier, name database, spam-analytics service, or recipient device to render a specific number or name. Production acceptance therefore requires real calls through the intended carrier routes.
If you are building a production voice AI product, connect an authorized number to Dasha and test its complete identity path before you scale traffic.
Calling line identification FAQ
What is the difference between CLI and caller ID?
CLI is the signaling data and presentation state associated with the calling line. Caller ID is the result rendered to the recipient after carriers, databases, and the device process that data.
What are CLIP and CLIR?
CLIP is the service that presents calling-line identity to the called party. CLIR restricts that presentation. A restricted number may remain available inside provider systems even though the recipient cannot see it.
Can CLI be spoofed?
Yes. An application can submit a false From value where the provider does not validate authorization. Provider screening and STIR/SHAKEN can strengthen the chain, but CLI remains unsuitable as sole authentication for sensitive actions.
Why does the recipient see a different number or no number?
Common causes include privacy settings, invalid formatting, an unauthorized number, provider normalization, trunk defaults, transfer or diversion behavior, interworking loss, and terminating-network policy.
Is CNAM part of CLI?
CNAM supplies a caller name in parts of the North American ecosystem. It is separate from the calling number and its presentation status. A correct number can appear with an absent, stale, or carrier-specific name.
