STIR/SHAKEN

TelcoBridges has partnered with TransNexus to deliver a complete STIR/SHAKEN solution that enables service providers to prevent illegal robocalls, authenticate caller IDs, and restore trust in voice communications across SIP and TDM networks.

Solving the Illegal Robocalling Problem

Illegal robocalling continues to plague consumers, more than interrupting with nuisance calls about automotive extended warranties, they have become the point of entry for scammers who prey on consumers.

“Unwanted calls – including illegal and spoofed robocalls – are the FCC’s top consumer complaint and our top consumer protection priority”  – Former FCC Chairman Ajit Pai

Falsification of a caller’s identity, or caller ID spoofing, is a favorite deception used by illegal robocallers and scammers to get their victims to answer the call. Whether the call appears to be from a neighbor, a bank, a utility or a government agency, consumers often fall for the deception, costing millions of dollars per year in fraud.

Regulators worldwide are strengthening efforts to combat fraud and unwanted calls through caller ID authentication frameworks. In the United States, the FCC and FTC enforce the TRACED Act, which mandates STIR/SHAKEN to verify caller identity, while countries such as France and Brazil have introduced similar authentication requirements.

The Objectives of STIR/SHAKEN

While complicated in implementation, the simple objective of STIR/SHAKEN is to secure the identity of the calling party, allowing the called party to know with relative certainty who initiated the call. For the subscriber, this should re-establish trust in the caller ID displayed on their telephone, presenting an icon or text that indicates that the caller-ID information is valid.

A second objective of implementing STIR/SHAKEN is to improve the analytics used to detect and block illegal robocallers, allowing legal robocallers (reverse 9-1-1, doctor’s appointment reminders, etc.) to reliably reach their intended recipients.

A third objective is to provide tools for law enforcement, enabling them to identify the source of phone calls, maintain a record of potentially illegal activity, and provide a strong deterrent.

STIR/SHAKEN Theory of Operation

The design of STIR/SHAKEN is centered around creating an encrypted identity token at the originating service provider, passing it through the network to the terminating service provider, who verifies its authenticity. Using well-understood public key infrastructure (PKI), STIR/SHAKEN relies on certificates managed by a Certificate Authority (CA) that closely manages issuance and revocation, limiting issuance to vetted and credentialed telephony service providers.

STIR/SHAKEN Architecture

Figure 1: STIR/SHAKEN Architecture

As shown in Figure 1, a simplified STIR/SHAKEN architecture encompasses a number of key elements:

Calling Party – the initiator of the call, a known customer of the originating telephone service provider (TSP).

Called Party – the intended recipient of the call, likely a subscriber on a different TSP.

Originating TSP – the service provider that first handles the call from the calling to the called party, is responsible for attesting to the authenticity of the caller, using an Authentication Service to create a secure telephone identity token. The identity is embedded in the SIP signaling before passing the call to the Terminating TSP.

Authentication Service – using the call information and attestation, creates an encoded identity token, returning the token to the Originating TSP.

Terminating TSP – the service provider that services the called party, validates the identity token using a caller ID Verification Service, and relays the results of the verification to the Called Party.

Verification Service – decodes the identity token, verifies the token with the certificate public key, and relays the verification status (true/false) back to the Terminating TSP.

Certificate Repository – a shared service that hosts the certificates for each of the trusted service providers.

A STIR/SHAKEN Solution from TelcoBridges

TelcoBridges and TransNexus have teamed to deliver a complete STIR/SHAKEN solution for service providers that is easy to integrate into existing systems, scales easily, works for both SIP and TDM networks, and has a business model that scales with adoption.

STIR/SHAKEN for SIP Service Providers

STIR/SHAKEN for SIP Networks

Figure 2: STIR/SHAKEN for SIP Networks

For SIP-based telecom service providers, the use of TelcoBridges ProSBC and TransNexus ClearIP is integrated together as shown in Figure 2.

At the Originating TSP, the architecture puts an SBC instance at the egress of their network, capturing call details as they leave their network, and passing the calling party information to ClearIP. The ClearIP service assigns an attestation letter, generates an Identity header, and returns the SIP identity header to ProSBC. That SIP INVITE with the Identity header is then passed on to the destination Terminating TSP.

At the Terminating TSP, the architecture puts an SBC at the point of ingress, passing the SIP INVITE with the SIP Identity header to ClearIP for verification. ClearIP retrieves the certificate found in the Identity header, verifies its authenticity, and returns a “verstat” status in the P-Asserted Identity field of the SIP INVITE. At this point, the softswitch at the Terminating TSP can use the verstat results to:

  • Perform additional reputation analytics
  • Redirect the call to screening services
  • Insert “[V]” in the caller name field
  • Or display the call validation status as is appropriate.

STIR/SHAKEN for TDM Service Providers

However, not all service providers have completed their migration to SIP, leaving part or all of their network using TDM equipment. To help bridge this gap, a TelcoBridges/TransNexus STIR/SHAKEN solution offers the flexibility to work in both SIP and TDM networks, or hybrid networks and any combination of service providers.

STIR/SHAKEN for TDM Networks

Figure 3: STIR/SHAKEN for TDM Networks

For TDM-based telecom service providers, use of TelcoBridges TMG Media Gateways with TransNexus ClearIP integrates as shown in Figure 3.

At the Originating TSP, the architecture puts a media gateway instance at the egress of their network, capturing call details as they leave their network, and passing the calling party information to ClearIP. The ClearIP service assigns an attestation letter, authenticates the call and posts the identity header at the destination TSP’s designated Call Placement Service.

At the Terminating TSP, the architecture puts a media gateway at the point of ingress. Upon arrival of a call, the media gateway converts the call to SIP, passing the INVITE to ClearIP, where the SIP Identity header is retrieved from the Call Placement Service. Once retrieved, the Identity header is verified for authenticity, and ClearIP returns a “verstat” status to the media gateway. At this point, the media gateway or TDM switch at the Terminating TSP can use the verstat results to:

  • Redirect the call to screening services
  • Insert “[V]” in the caller name field
  • Or display the call validation status as is appropriate.

Case Study: Wabash Communications implements STIR/SHAKEN on a hybrid SIP/TDM Network

Learn how TelcoBridges helped Wabash Communications implement STIR/SHAKEN to help eliminate illegal robocalls and improve subscriber answer rates.
Read Case Study

Benefits of the TelcoBridges/TransNexus STIR/SHAKEN solution

The benefits of the TelcoBridges/Transnexus includes:

Ease of implementation

Inserting ProSBC into the call flow eliminates the need for major system upgrades.

Flexible deployment options

TelcoBridges’ STIR/SHAKEN solution supports both SIP and TDM networks or hybrid networks.

Interoperability

Based on ATIS standard interfaces, our STIR/SHAKEN solution is compatible with standard STIR/SHAKEN solutions.

Cloud-ready

The TelcoBridges STIR/SHAKEN solution can be deployed in existing data centers or as a software-as-a-service subscription.

Scalable business model

Service providers can “ramp up” their support for STIR/SHAKEN as they migrate and grow.

Highly reliable

The TelcoBridges’ STIR/SHAKEN solution is based on reliable carrier-class software and hardware systems.

Learn More About STIR/SHAKEN

From the TelcoBridges Video Library:

More on TelcoBridges’ ProSBC and TMG media gateways:  www.prosbc.com & VoIP media gateways

More on TransNexus’ ClearIP:  https://transnexus.com/clearip/

Discover the Right STIR/SHAKEN Solution for Your Network

Complete the form below to request a consultation with our experts who can evaluate and make recommendations on your specific situation:

Frequently Asked Questions

What is STIR/SHAKEN?

STIR/SHAKEN is a set of interconnected standards designed to authenticate caller identity on voice networks. STIR (Secure Telephone Identity Revisited) defines how to create and verify cryptographic identity tokens attached to SIP calls. SHAKEN (Signature-based Handling of Asserted information using toKENs) specifies how voice service providers implement STIR within their networks. Together, they allow a terminating service provider to verify that the calling number on an incoming call has been attested to by the originating service provider, giving the called party a reason to trust the caller ID displayed on their phone.

What do the STIR/SHAKEN attestation levels mean?

When an originating service provider signs a call, it assigns one of three attestation levels based on how much it knows about the caller. Full Attestation (A) means the provider has authenticated the calling party and confirmed they are authorized to use the calling number. Partial Attestation (B) means the provider knows where the call originated within its network but has not verified the caller’s right to use that specific number. Gateway Attestation (C) means the call entered the provider’s network from an external or untrusted source, such as an international gateway, and the provider cannot verify the caller’s identity. Calls with Full Attestation are the most trusted and least likely to be flagged or blocked by downstream analytics.

Is STIR/SHAKEN required by law?

In the United States, yes. The TRACED Act (2019) and subsequent FCC orders require voice service providers to implement STIR/SHAKEN in the IP portions of their networks. Large carriers were required to comply by June 2021, and smaller providers received extended deadlines with interim mitigation requirements. The FCC’s own-certificate rule further requires that originating providers obtain their own STI certificates rather than relying on upstream carriers. Other countries are adopting similar frameworks: Canada implemented STIR/SHAKEN through the CRTC, France has introduced caller authentication requirements, and Brazil’s ANATEL is developing equivalent regulations.

How does STIR/SHAKEN work technically?

When a call is placed, the originating service provider’s SBC sends the call details (calling number, called number, and timestamp) to an authentication service (STI-AS). The authentication service creates a PASSporT (Personal Assertion Token), a digitally signed JSON object containing these claims plus the attestation level, and returns it as a SIP Identity header. The SBC attaches this header to the outgoing SIP INVITE. When the call reaches the terminating provider, their SBC extracts the Identity header and sends it to a verification service (STI-VS), which retrieves the originating provider’s public certificate, validates the signature, and returns a verification status. The terminating provider can then display a trust indicator to the called party or apply further analytics.

Does STIR/SHAKEN work on TDM networks?

TDM (Time Division Multiplexing) networks cannot carry SIP Identity headers natively, since they use SS7 signaling rather than SIP. However, an out-of-band STIR/SHAKEN approach solves this. A media gateway at the originating TDM network converts the call to SIP, sends the call information to an authentication service like TransNexus ClearIP, and the signed identity token is posted to a Call Placement Service. At the terminating end, a media gateway retrieves and verifies the token from the Call Placement Service when the call arrives. TelcoBridges supports this out-of-band approach using Tmedia media gateways alongside ClearIP, allowing service providers with hybrid SIP/TDM networks to implement STIR/SHAKEN across their entire infrastructure.

What is an STI certificate and who issues them?

An STI (Secure Telephone Identity) certificate is the digital credential that authorizes a service provider to sign calls with STIR/SHAKEN. It functions like a digital passport: the authentication service uses the provider’s private key (associated with the certificate) to sign PASSporT tokens, and terminating providers use the corresponding public key to verify those signatures. In the United States, STI certificates are issued by STI Certificate Authorities (STI-CAs) that are authorized by the STI Policy Administrator (STI-PA), currently managed by the industry consortium iconnectiv. Providers must be vetted and credentialed before receiving a certificate, and the STI-PA can revoke certificates from providers found to be originating illegal traffic.

How does ProSBC implement STIR/SHAKEN?

ProSBC integrates with third-party authentication and verification services, primarily TransNexus ClearIP and Neustar, to deliver STIR/SHAKEN signing and verification. In the production deployment pattern, ProSBC routes calls through a dedicated trunk group (NAP) configured to communicate with the signing service over SIP. The signing service acts as a SIP redirect server: it evaluates the call, assigns an attestation level, creates the Identity header, and returns it to ProSBC, which attaches the header to the outgoing INVITE. For verification, the same pattern works in reverse. This architecture means ProSBC can add STIR/SHAKEN to an existing voice network without requiring changes to the upstream softswitch or PBX. For a step-by-step walkthrough, see the STIR/SHAKEN SBC implementation guide.

Does STIR/SHAKEN stop all robocalls?

No. STIR/SHAKEN authenticates caller identity; it does not block calls by itself. A verified call only tells the terminating provider that the calling number was attested to by a known service provider, not that the call is wanted. Legal robocalls (appointment reminders, school closures, emergency alerts) carry valid attestation and should not be blocked. The value of STIR/SHAKEN lies in enabling better analytics: calls with no attestation or low attestation can be scored, flagged, or routed to screening services. Calls with forged caller IDs will fail verification entirely, making them easy to identify and block. Over time, as adoption increases and analytics improve, the framework makes illegal robocalling progressively more difficult and expensive for bad actors.

What happens if a call has no STIR/SHAKEN attestation?

A call arriving without a SIP Identity header simply has no STIR/SHAKEN verification status. The terminating provider may display a “Not Verified” indicator or apply additional scrutiny through reputation analytics and call scoring. Unverified calls are not automatically blocked, but they receive a lower trust score than verified calls. Common reasons for missing attestation include calls originating from providers that have not yet implemented STIR/SHAKEN, calls traversing international gateways (where STIR/SHAKEN infrastructure may not exist), and calls from TDM networks that lack an out-of-band signing implementation. As regulatory deadlines pass and adoption increases, the proportion of unverified calls is decreasing.

Can I implement STIR/SHAKEN without replacing my existing network equipment?

Yes. One of the primary advantages of an SBC-based STIR/SHAKEN implementation is that the SBC inserts into the call path at the network edge without requiring changes to your softswitch, PBX, or core infrastructure. ProSBC sits between your existing equipment and the external network, handles the authentication and verification exchange with the signing service, and passes calls through with the Identity header attached. For TDM networks, a Tmedia media gateway provides the same functionality at the TDM/IP boundary. Both SIP and TDM deployments can scale incrementally, starting with a single trunk group and expanding as needed.