VoIP

Caller ID in Brazilian STFC: CLI, CLIR and Anatel's Rules

Understand how caller identification works in Brazil's STFC, the role of CLI, Anatel's rules on CLI and CLIR, and the relationship with STIR/SHAKEN.

SipPulse - Technical TeamMay 10, 20256 min read

Caller ID in Brazilian STFC: CLI, CLIR and Anatel's Rules

What is CLI

CLI (Calling Line Identification) is the mechanism that enables the presentation of the calling party's number in Brazil's STFC (Fixed Switched Telephone Service). Anatel, Brazil's telecom regulator, defines how this number must be generated, transmitted, and presented across the interconnection chain.

In practice, CLI is what the market calls "caller ID." For ISPs and carriers providing STFC, correctly configuring caller identification is mandatory and involves both regulatory and technical aspects.

How Caller ID Works in SIP

In the SIP protocol, the caller's identity is carried in multiple headers, each with a different purpose:

From: contains the caller's URI. It can be freely set by the endpoint, which makes it unreliable for identification purposes.
P-Asserted-Identity (PAI): inserted by a trusted network element (the carrier's softswitch or SBC). It represents the verified identity of the caller. Carried only within the trust domain.
Remote-Party-ID (RPID): an older header with a similar function to PAI. Still used by some legacy equipment.

For STFC carriers, the softswitch must insert the PAI with the subscriber's correct number and ensure this header is propagated in interconnection calls.

Anatel's Rules on Caller Identification

Anatel establishes clear rules regarding the presentation of the calling number:

Mandatory transmission: the originating carrier must send caller identification on all calls.
CLIR (Calling Line Identification Restriction): subscribers have the right to restrict the presentation of their number. When activated, the number is still transmitted between carriers (for billing and traceability), but must not be presented to the called subscriber.
Contact centers: telemarketing and collection companies must present a valid, reachable number. Non-compliance can result in sanctions from Anatel.
Number portability: when a number has been ported, the carrier must query ABR Telecom's database to route correctly and maintain the subscriber's original identification.

CLI and CLIR Configuration in SipPulse SoftSwitch

The SipPulse SoftSwitch simplifies caller identification configuration through its management interface. Instead of manually editing configuration files, the operator configures CLI and CLIR rules directly in the administrative panel.

P-Asserted-Identity Configuration

In the SipPulse SoftSwitch, PAI is configured per subscriber and per route:

For each subscriber, the system automatically associates the complete E.164 number (55 + area code + number) with the P-Asserted-Identity header.
The SoftSwitch validates that the number presented in the From header belongs to the authenticated subscriber, blocking spoofing attempts before the call leaves the network.
In interconnection calls, PAI is propagated according to the agreements configured for each partner carrier.

CLIR Configuration

The SipPulse SoftSwitch allows CLIR configuration at three levels:

Per subscriber: subscribers can activate or deactivate identification restriction through the self-service portal or via service code (*31# to activate, #31# to deactivate).
Per route: the operator can define CLIR policies per outbound route, forcing number presentation on contact center routes, for example.
Per campaign: for contact center operations using the SipPulse SBC NNI-CC, caller ID can be configured per dialing campaign, ensuring each campaign presents the correct number.

When CLIR is active, the SipPulse SoftSwitch automatically inserts the Privacy: id header in SIP signaling, ensuring the number is not presented to the destination while remaining available for billing and traceability between carriers.

How SipPulse SBC Protects Caller Identification

The SipPulse SBC adds a layer of protection at the network edge, complementing the SipPulse SoftSwitch in caller ID management:

Origin validation at the edge: the SBC UNI verifies that the caller ID presented by the endpoint matches the authenticated subscriber, rejecting spoofed calls before they reach the core.
Normalization between networks: the SBC NNI adjusts identification headers according to each interconnection's specifications, ensuring PAI is transmitted in the correct format for each partner carrier.
Topology hiding with CLI preservation: the SBC conceals internal network topology without compromising the correct transmission of the originating number.

STIR/SHAKEN and Origem Verificada with SipPulse

STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) is the international framework for call identity authentication. It allows the originating carrier to digitally sign the caller's identity, and the terminating carrier to verify that signature.

In Brazil, Anatel is working on the Origem Verificada (Verified Origin) program, which adapts STIR/SHAKEN concepts to Brazil's regulatory environment. The goal is to combat fraudulent calls and caller ID spoofing, a growing problem especially in irregular telemarketing operations.

The SipPulse SBC offers native STIR/SHAKEN support, which means that carriers using the SipPulse platform are already prepared for Origem Verificada requirements:

Call signing (originating SBC): the SipPulse SBC inserts the attestation token (attestation level A, B, or C) in originated calls, digitally signing the caller's identity.
Signature verification (terminating SBC): the SipPulse SBC validates received tokens, verifying the authenticity of the caller's identity and flagging calls with invalid signatures.
Certificate management: the SipPulse platform integrates with the digital certificate infrastructure, simplifying the renewal and management of certificates required for STIR/SHAKEN.

This native integration eliminates the need to acquire third-party STIR/SHAKEN solutions, keeping all call identity management within the SipPulse ecosystem.

Integration Between SipPulse SoftSwitch and SBC for CLI

The combination of SipPulse SoftSwitch and SipPulse SBC creates a complete caller identification management chain:

The SipPulse SoftSwitch authenticates the subscriber, associates the correct number, and inserts PAI.
The SipPulse SBC UNI validates origin at the access edge, blocking spoofing.
The SipPulse SBC NNI normalizes headers for interconnection and applies STIR/SHAKEN on outgoing calls.
On termination, the SipPulse SBC NNI receives the call, verifies the STIR/SHAKEN token, and delivers it to the SoftSwitch with validated attestation.

This chain works transparently, without manual configuration on each component, because all elements share the same database and routing policies.

Practical Implications for ISPs

If you operate STFC as an ISP, the SipPulse platform offers a simplified approach to CLI management:

Configure PAI correctly through the SipPulse SoftSwitch management interface, without needing to edit configuration files.
Implement automatic caller ID validation with the SipPulse SBC UNI at the access edge.
Monitor calls with missing or invalid caller ID through the SipPulse SoftSwitch's integrated CDR reports.
Prepare for Origem Verificada by activating STIR/SHAKEN support on the SipPulse SBC, which already supports the framework natively.
Manage CLIR settings centrally for all subscribers, with full audit trail of changes.