STIR/SHAKEN verification service

The STIR/SHAKEN framework enables telephone service providers to authenticate and verify caller identities to mitigate caller ID spoofing, a common tactic used in unwanted robocalls. This paper explains how the verification service uses the SIP Identity header and signature provided in a signed call.

This whitepaper covers the following topics to explain the STIR/SHAKEN authentication service:

  1. Verification service
  2. Verification results
  3. Using verification results

1. Verification service

Service providers who terminate calls on the IP network are responsible for verifying calls through a verification service. These terminating service providers verify calls by checking the format and contents of the Identity header and verifying the originating service provider’s signature.

How the verification process works

The terminating service provider uses the Identity header and digital signature provided by the originating service provider in the authentication process. (For more detailed information about this process, see our whitepaper on the STIR/SHAKEN authentication service.) When the terminating service provider receives a signed call with an in-band Identity token, it is sent to the verification service in a verification request. Alternatively, the service provider may receive tokens out-of-band from a Call Placement Service.

Terminating provider receives signed call, sends Invite for verification

SHAKEN Call flow

Review Identity header format and contents

The verification service checks the format and contents of the Identity header and PASSporT token to ensure every required parameter is present and contains a value.

It checks that the date and time indicated in the iat parameter is not earlier than 60 seconds before the time of verification.

To ensure the token contains accurate information, the verification service compares the telephone numbers in the dest and orig parameters with the telephone numbers in the To and From (or P-Asserted-Identity) headers.

Validate the certificate

Before verifying the originating provider’s signature, the terminating provider acquires the originating provider’s certificate and assesses its validity.

The verification service makes a request for the certificate to the originating provider’s certificate repository and receives a copy of the current certificate.

Then the verification service ensures the certificate is currently valid:

  • The expiration date and time have not passed.
  • The issuing certificate authority is currently valid according to a list of approved certificate authorities compiled by the SHAKEN policy administrator.
  • The certificate authority signature on the originating provider’s certificate is verified with the certificate authority’s public key.

The time between sending a certificate request and then receiving the certificate can depends on the distance between the verification service and the certificate repository. To speed up certificate acquisition, the verification service can implement certificate caching.

Verify the signature

Once the originating provider’s certificate has been verified, the verification service extracts the public key from the certificate to verify the signature.

Signatures are evaluated to determine if the call information within the SIP Invite was altered in transit.

The verification service takes the PASSporT token header and payload within the Identity header and computes the hash value.

Then it inputs the public key and digital signature into the signature verification algorithm to obtain the original hash value computed by the originating service provider.

Verify the signature

The verification service compares the computed hash value with the original hash value. If they match, the signature is considered valid.

verify the signature

If the hash values are different, the signature is considered invalid and verification fails. This mechanism allows caller ID spoofing and replay scams to be detected and stopped in real time.

Compare hash values


2. Verification results

If an error occurs during verification, the verification service signals this to the originating service provider through an error code:

  • 403: Stale Date. Verification service receives an Identity header that is older than 60 seconds after the time indicated in the iat parameter.
  • 428: No ID Header. Unsigned call is received when it is expected to be signed. This error code is reserved until SHAKEN is widely adopted.
  • 436: Bad Identity Info. Verification service is unable to access the certificate repository listed in info URI due to a request timeout or 4XX (client) or 5XX (server) error.
  • 437: Unsupported Credential. Verification service does not trust certificate or certificate authority.
  • 438: Invalid Identity Header. Signature verification fails, attest value not valid, orig and dest do not match From or P-Asserted-Identity header and To header.

Verification results are transmitted to the called party’s user equipment in the SIP verstat parameter.1 The verstatparameter is a tel URI parameter within the P-Asserted-Identity header or the From header.

P-Asserted-Identity: tel:+15617500080;verstat=TN-Validation-Passed

There are currently three different options to convey verification results through the verstat parameter:

  1. TN-Validation-Passed
  2. TN-Validation-Failed
  3. No-TN-Validation

If the called party’s user equipment does not support the verstat parameter, then the user equipment can discard the parameter.

3. Using verification results

Call analytics

STIR/SHAKEN verification results are valuable when combined with a call analytics service where STIR/SHAKEN provides a source of reliable call data. An analytics service can determine the level of risk associated with an incoming call by evaluating SHAKEN verification results alongside other data:

  • Reported phone number lists (FCC, FTC lists)
  • Social media
  • Caller reputation data

The analytics service can be implemented as part of the terminating network, by a third-party that partners with the terminating service provider or as an application in the user equipment.

Verification policies

Terminating providers will probably want to leverage STIR/SHAKEN verification results in policy actions. The STIR/SHAKEN framework doesn’t specify policy actions. These are left for carriers to develop as a value-added service for their customers.

When planning their STIR/SHAKEN deployment, carriers should give careful consideration to the verification policies they wish to offer and how they will develop these capabilities.

User equipment displays

The results of verification must be communicated to the called party. The creators of the STIR/SHAKEN frameworks have published recommended guidelines on verification displays for user equipment based on usability studies.2

Text-based displays

Some user equipment may be limited to communicating verification results through text. Recommended text-based displays are based on conventional CNAM displays that are limited to 15 alphanumeric characters.

Option 1: A designated special character is added to the official CNAM to indicate whether a call has been verified. In this example, the special character is represented as an asterisk (*).

John Doe*

Option 2: A conventional CNAM query is performed and results are delivered to an analytics server. If a call is unlikely to be fraudulent, the CNAM is displayed. However, if a call is likely to be fraudulent, the CNAM is overwritten with text to indicate fraud.


Visual displays

Usability studies focused on how displaying different icons and descriptions influenced call pickup and blocking rates. Display options can differ depending on whether a call analytics service is used.

Without call analytics:

Without call analytics, the end user equipment only displays whether an incoming call has passed or failed verification.

If verification is successful, then the screen should display a normal call profile without any indication of successful verification such as a padlock or green checkmark. The display may show the calling number, caller name, logo of the calling party, and location (city, state).

Successful verification results without analytics

If verification fails, then the display can show the calling number along with a warning and a brief description for the reason. It is recommended to use the phrase “Fake Number” along with a stop sign icon. The terminating service provider may block these calls if requested by the end user.

Failed verification results without analytics

With call analytics:

With call analytics, the end user equipment can display whether a call is likely to be spam or fraudulent in addition to verification results.

If verification was successful, the display should show the normal call profile. Analytics results can also be provided to give the end user more information to trust the call.

Successful verification results with analytics

If verification was successful but analytics indicates that the call is likely to be spam, then the display should show a warning and reason with the calling number. Analytics results can be added to further explain why the call is likely spam.

Successful verification results with suspicious analytics

If verification fails, then further analytics need not be performed. The screen should display a warning.

Failed verification results with analytics


SHAKEN enables service providers to authenticate and verify caller identities to mitigate call spoofing. Originating service providers are responsible for authenticating calls by creating the signed Identity header. Terminating service providers are then responsible for verifying the call by validating first the originating provider’s certificate and then the signature. Verification results are communicated to the end user through the verstat parameter and an enhanced display. Call analytics can provide additional information to determine if a call should be trusted.


1. Martin Dolly, “Mitigation Techniques for Unwanted Robocalls: Updates on ATIS and Other Key Industry Initiatives,” October 2016,

2. ATIS, “ATIS Technical Report on a Framework for Display of Verified Caller ID,” May 2018,

More on

Jan 17, 2022

STIR/SHAKEN statistics for December 2021

Jan 12, 2022

Reply comments on proposed rules for gateway providers

Jan 10, 2022

State attorneys general urge tough robocall rules for gateway providers

Dec 27, 2021

FCC reevaluates SHAKEN extensions

Dec 22, 2021

Comments on FCC proposed rules for gateway providers

Dec 13, 2021

FCC order accelerates SHAKEN deadline for some small providers

Dec 8, 2021

Recent activity on pending and proposed robocall rules

Dec 1, 2021

SHAKEN statistics for November 2021

Nov 29, 2021

FCC proposed rules for gateway providers—would they work?

Nov 23, 2021

Canadian SHAKEN mandate approaches

Nov 15, 2021

SHAKEN for TDM podcast

Nov 10, 2021

New York governor signs robocall legislation

Nov 8, 2021

SHAKEN statistics for October 2021

Nov 3, 2021

Robocall trends in the new SHAKEN era

Nov 1, 2021

Canadian SHAKEN token access policy revised

Oct 25, 2021

Enforcement action against robocallers in the SHAKEN era

Oct 20, 2021

STI-GA announces support for enhanced SHAKEN functionality

Oct 18, 2021

STIR/SHAKEN statistics for September 2021

Oct 5, 2021

Out-of-Band SHAKEN with a private Call Placement Service

Sep 29, 2021

Many SHAKEN certifications, few SHAKEN-authorized providers

Sep 13, 2021

FCC proposes additional robocall rules for gateway providers

August 26, 2021

Rich Call Data and Delegate Certificates—a great pairing

August 16, 2021

Canadian regulator changes service provider SHAKEN qualifications

August 4, 2021

Are SHAKEN and robocall mitigation preventing unlawful robocalls?

July 28, 2021

Who should sign SHAKEN calls?

July 26, 2021

Spam robocalls and SHAKEN attestation

July 15, 2021

SHAKEN for TDM standards approved

June 29, 2021

Robocaller tried to hack SHAKEN

June 15, 2021

May 2021 STIR/SHAKEN statistics

June 9, 2021

Robocall Mitigation Database filing statistics

June 7, 2021

U.S. — Canada cross-border SHAKEN

May 25, 2021

Press release — New Out-of-Band SHAKEN whitepaper available

May 13, 2021

February 17, 2021

ClearIP Out-of-Band SHAKEN enhancements