STIR/SHAKEN Verification API: Call Authentication for Carriers

What Is STIR/SHAKEN?

STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted Information Using toKENs) is the FCC-mandated framework for authenticating caller ID information across VoIP and interconnected telephone networks. The framework assigns digital signatures to calls so that terminating carriers and analytics engines can verify that the number displayed as caller ID is legitimately associated with the calling party.

STIR is the IETF standard set that defines how caller identity tokens are created and validated cryptographically. SHAKEN is the ATIS/SIP Forum implementation specification that defines how US carriers deploy those standards in practice. Together, they create a chain of accountability from the originating carrier through any transit carriers to the terminating carrier.

For a deep dive on attestation levels A, B, and C, see our companion guide: STIR/SHAKEN Attestation Levels Explained.

FCC Requirements: Who Must Comply

The FCC's call authentication mandate, enacted under the TRACED Act and implemented through a series of orders, requires all voice service providers to implement STIR/SHAKEN on their IP networks. Key requirements include:

• All voice service providers must implement STIR/SHAKEN on IP portions of their networks
• Carriers that cannot implement STIR/SHAKEN on non-IP or legacy TDM networks must file a robocall mitigation program in the FCC's Robocall Mitigation Database (RMD)
• Intermediate providers that carry but do not originate or terminate calls must pass STIR/SHAKEN tokens unchanged and may not strip or alter signed headers
• Gateway providers that first receive calls from foreign networks must apply a SHAKEN attestation when signed tokens are not present on foreign-originated calls
• Downstream providers may block traffic from carriers not listed in the RMD or lacking STIR/SHAKEN compliance

Compliance failures carry enforcement risk and, more practically, downstream carriers increasingly block or flag traffic from non-compliant upstream providers. A carrier with no attestation on its outbound calls is at a structural delivery disadvantage that compounds as more terminating carriers tighten their call handling policies.

The Robocall Mitigation Database

Any carrier that cannot fully implement STIR/SHAKEN on all traffic must file a detailed robocall mitigation program with the FCC. The RMD is a public database; downstream carriers query it to verify that upstream providers are compliant. Carriers not listed in the RMD can have their traffic blocked by any downstream provider — no FCC enforcement action required.

How the Call Authentication Flow Works

Understanding the STIR/SHAKEN verification flow clarifies where LRN and carrier data fits in. A signed call moves through four stages:

1. Origination — Signing. The originating carrier receives a call from its customer. It queries its number inventory and subscriber data to determine what attestation level it can assign. It then creates a PASSporT (Personal Assertion Token) — a JSON Web Token containing the calling number, called number, attestation level, and a timestamp — signed with the carrier's private STI certificate. This token is inserted into the SIP IDENTITY header.
2. Transit. Intermediate carriers pass the SIP IDENTITY header unchanged. They may add their own header if the call enters their network without one (as from a foreign gateway), but they do not re-sign authenticated calls.
3. Termination — Verification. The terminating carrier extracts the PASSporT from the SIP IDENTITY header. It fetches the originating carrier's public certificate from the STI-CR (Certificate Repository) and validates the cryptographic signature. It checks that the token is fresh (not replayed) and that the calling number matches.
4. Call Handling Decision. The termination result — verified, invalid signature, missing token, expired token — is passed to analytics engines and call-handling logic. Calls with valid Full Attestation (A) receive the best treatment; calls with no signature or invalid signatures are candidates for blocking or voicemail routing.

Attestation Levels: A, B, and C

Attestation level is the most consequential field in the PASSporT. It encodes how much the originating carrier can vouch for the call:

The path from C to A is largely a data problem: the carrier needs accurate, current information about who owns which numbers and whether callers are authorized to use them. That is where LRN and carrier data are indispensable.

The Data Layer: Why LRN and Carrier Data Are Critical

STIR/SHAKEN is a signing protocol, but the attestation level it produces is only as accurate as the underlying data the signing carrier holds. Two data types determine whether a carrier can assign Full Attestation or is forced to fall back to Partial or Gateway:

LRN Lookup: Verifying Number Ownership After Porting

A Local Routing Number (LRN) is the 10-digit identifier that tracks where a ported phone number actually terminates after a customer moves between carriers. When a subscriber ports their number from Carrier A to Carrier B, the LRN in the national number portability database updates to point to Carrier B's switch — even though the original NPA-NXX still belongs to Carrier A.

For STIR/SHAKEN attestation, this matters in two ways:

• Originating carrier verification. Before an originating carrier can assign Full Attestation to a call, it needs to confirm that the calling number is currently assigned to a subscriber on its network. An LRN lookup against a current portability database confirms whether the number is genuinely owned by the carrier's subscriber or has been ported away. A number that left your network six months ago cannot receive Full Attestation from you.
• Terminating carrier validation. When a terminating carrier verifies a signed call, it can cross-reference the attested calling number against LRN data to catch mismatches — for example, a call claiming Full Attestation from Carrier A on a number that has been ported to Carrier B. These mismatches are indicators of fraud or misconfigured signing.

VeriRoute Intel's LRN API returns the current routing carrier, LRN, line type, and LRN activation date for any US phone number. The activation date field is a VRI differentiator: it tells you exactly when a number was ported, enabling fraud detection for numbers ported very recently before a call campaign.

Learn more about LRN lookup →

Carrier Data: Identifying the Originating Provider

Carrier data identifies the current operating company for a given phone number, linking it to its OCN (Operating Company Number) and network type. This data serves two functions in the STIR/SHAKEN stack:

• Certificate chain validation. When a terminating carrier validates a signed call, it must retrieve the originating carrier's certificate from the STI-CR using the certificate URL in the PASSporT. Knowing the originating carrier from the calling number's current data allows the verifier to cross-check that the signing certificate actually belongs to that carrier.
• Routing and handling decisions. Analytics engines that score calls use carrier identity as a trust signal. A call signed by a well-known national carrier with a clean compliance history is treated differently from one signed by an unrecognized OCN. Accurate carrier identification surfaces those distinctions.

VeriRoute Intel's carrier lookup returns OCN, carrier name, network type (wireless, wireline, VoIP), and messaging provider identification — the last field being a capability no other lookup API offers at this scale.

Explore the Carrier Lookup API →

Querying VRI for STIR/SHAKEN Data

A single VRI API call returns both LRN and carrier data for a phone number. Here is an example lookup used in an originating carrier's pre-signing flow to determine attestation eligibility:

curl -X POST https://verirouteintel.com/api/v1/lrn \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"phone_number": "14155550123"}'

Example response:

{
  "phone_number": "14155550123",
  "lrn": "4085550000",
  "ocn": "6529",
  "carrier": "Pacific Bell Telephone Company",
  "line_type": "wireline",
  "ported": true,
  "lrn_activation_date": "2024-03-14",
  "messaging_provider": null
}

In this response, ported: true and lrn_activation_date tell you the number has been ported and when. The ocn and carrier fields confirm the current owning provider. An originating carrier can cross-reference this against its subscriber database: if the calling subscriber's account matches the OCN and the number has not been ported away, Full Attestation (A) is warranted. If there is a mismatch, the carrier should fall back to Partial Attestation (B) rather than over-attest.

Building a STIR/SHAKEN-Compliant Implementation

For carriers and VoIP providers building or auditing their STIR/SHAKEN implementation, this checklist covers the data and infrastructure requirements:

Originating Carrier Requirements

1. Obtain an STI certificate. Register with a SHAKEN Certificate Authority (CA) through the STIR/SHAKEN Policy Administrator (STI-PA). You need a valid STI certificate to sign calls.
2. Maintain a current number inventory. Know exactly which numbers are assigned to your subscribers. Integrate LRN lookup to validate number ownership in real time, especially for enterprise customers with large number blocks.
3. Implement attestation decision logic. Build the rules engine that assigns A, B, or C based on what your subscriber data and LRN/carrier lookups confirm. Over-attesting is an FCC enforcement risk; under-attesting damages your customers' call delivery.
4. Sign calls in SIP IDENTITY headers. Generate PASSporTs and insert them in outbound SIP INVITE messages. Ensure your SBC or softswitch supports this header without stripping it.
5. Log signed calls. Maintain records of attestation levels assigned for FCC traceback compliance.

Terminating Carrier Requirements

1. Parse SIP IDENTITY headers. Extract PASSporTs from inbound SIP INVITE messages.
2. Fetch and cache originating certificates. Retrieve signing certificates from the STI-CR. Cache certificates per their TTL to minimize verification latency.
3. Validate cryptographic signatures. Verify that the signature in the PASSporT was produced by the claimed originating carrier's certificate.
4. Cross-reference number data. Use LRN lookup to validate that the signed calling number is currently associated with the attesting carrier. Flag mismatches for analytics review.
5. Pass verification results downstream. Surface attestation status to analytics engines, call-blocking services, and display systems that use this data for call handling decisions.

STIR/SHAKEN for VoIP Providers and CPaaS Platforms

VoIP providers and CPaaS platforms occupy a complex position in the STIR/SHAKEN ecosystem. They originate calls on behalf of enterprise customers, often presenting numbers that the enterprise — not the VoIP provider — has sourced from a separate carrier. This creates the typical Partial Attestation (B) scenario: the provider knows its customer but cannot independently verify the customer's right to use the presented calling number.

Closing the gap to Full Attestation (A) requires a defined process:

• Number verification programs. Collect letters of authorization (LOAs) from enterprise customers for all numbers they present as caller ID. Cross-reference those against LRN data to confirm the numbers are actually assigned to carriers the enterprise controls.
• Delegated certificates (emerging). The STIR/SHAKEN governance framework is developing standards for enterprise-level delegated certificates that would allow large enterprises to sign their own calls directly, bypassing the carrier attestation problem.
• Carrier partnerships. Work with upstream carriers that have direct number assignment relationships so that calls routed through those carriers can receive Full Attestation at the carrier level.

For CPaaS providers processing millions of calls daily, the LRN lookup cost at VRI's rate of $0.0009 per lookup is a fraction of the revenue risk from mis-attested calls that get blocked or flagged as spam.

Monitoring and Maintaining Compliance

STIR/SHAKEN is not a one-time implementation. Number inventory changes, carrier relationships change, and the FCC regulatory environment continues to evolve. Ongoing compliance requires:

• Regular LRN audits. Phone numbers port frequently. A subscriber number that was valid for Full Attestation last quarter may have ported away. Periodic bulk LRN lookups against your active subscriber list catch stale entries before they cause attestation errors.
• Attestation level monitoring. Track the distribution of A/B/C attestation across your outbound traffic. A sudden increase in B or C attestation levels signals a data or configuration problem.
• Traceback readiness. The FCC's Industry Traceback Group (ITG) can request traceback records on calls within 24 hours. Maintain call records that link signed calls to subscriber accounts and attestation decisions.
• RMD status checks. Verify that your upstream carriers remain listed in the Robocall Mitigation Database. Traffic from delisted carriers should be treated with maximum scrutiny or rerouted.