The verstat Header in STIR/SHAKEN

1. What verstat is

verstat is a parameter on the SIP From header (and sometimes the P-Asserted-Identity header) that conveys the result of STIR/SHAKEN verification of the calling number on incoming voice traffic. It is set by the terminating provider's verification service after checking the Identity header in the incoming INVITE.

The Identity header carries the cryptographic signature that proves the calling number was authorized to use that identity. The verification service:

1. Extracts the Identity header from the INVITE
2. Fetches the signing certificate from the URL specified in the header
3. Verifies the certificate chain back to a trusted certificate authority
4. Verifies the signature against the call's identifiers and origination time
5. Sets verstat on the outgoing call to the terminating endpoint

verstat lets endpoints (and downstream systems) know what happened during verification without re-running the cryptographic check themselves.

2. The three verstat values

Debugging this right now? Paste the trace into the SIP trace analyzer — severity-ranked findings with the likely cause in seconds, free tier included. Or continue below for the manual approach.

TN-Validation-Passed

The Identity header was present, the signature verified, and the calling number is consistent with the signed identity. The terminating provider has confidence that the caller is who they claim to be (subject to the attestation level).

This is the “green checkmark” case. Display systems can show a verified indicator. Routing systems can apply less aggressive screening.

TN-Validation-Failed

An Identity header was present but verification failed. Possible reasons: signature does not validate, certificate is expired or untrusted, the identity in the signature does not match the From header, or origination time is outside the allowed skew.

This is the “red flag” case. Many terminating providers route TN-Validation-Failed calls more cautiously — some block, some warn the user, some apply additional analytics before connecting.

No-TN-Validation

No Identity header was present, or the call originated from a non-IP path where STIR/SHAKEN cannot be applied. The verification system cannot determine whether the calling number is legitimate.

This is the “unknown” case. It is not necessarily fraudulent — many legitimate calls (especially from international or TDM-only sources) arrive without Identity. But it indicates an absence of cryptographic guarantee.

3. How verstat is determined

The verification process is mechanical:

1. The terminating provider's SBC or verification service receives the INVITE
2. Looks for an Identity header. If absent, sets verstat=No-TN-Validation and proceeds.
3. Parses the Identity header. It is a JSON Web Token (JWT) with a header, payload, and signature.
4. Fetches the signing certificate from the URL in the JWT header (an x5u parameter)
5. Verifies the certificate is valid and chains to a trusted authority (the SHAKEN policy administrator)
6. Verifies the signature over the JWT payload
7. Compares the “orig” claim in the payload to the actual From header in the INVITE
8. Checks “iat” (issued at) for time skew — typically must be within 60 seconds
9. If all checks pass, sets verstat=TN-Validation-Passed; if any fail, verstat=TN-Validation-Failed

The attestation level (A, B, or C) is in the JWT payload and indicates how strongly the originating provider can vouch for the calling number:

• Attestation A: The originating provider has a direct authenticated relationship with the customer and can confirm they are authorized to use the calling number
• Attestation B: The provider has a relationship with the customer but cannot fully verify their authorization to use the specific number
• Attestation C: The provider only knows the call is on their network but has no direct relationship with the originator

verstat=TN-Validation-Passed means the signature verified, but the underlying trust depends on the attestation level. C-level passed is technically valid but provides weak guarantees about caller identity.

4. Display rules and routing

Different terminating providers and endpoints use verstat in different ways across voice service networks:

Display indicators

• Many mobile carriers display “Verified Caller” or a checkmark icon for TN-Validation-Passed with attestation A
• “Possible Spam” or warning icons for TN-Validation-Failed
• No special display for No-TN-Validation, falling back to the existing caller ID

Routing decisions

• Block lists may auto-add numbers with multiple TN-Validation-Failed events
• Analytics pipelines can flag No-TN-Validation calls from international gateways for additional scrutiny
• Some enterprise PBXes use verstat for spam filtering before delivering to extensions

Endpoint behavior

SIP phones from major vendors (Yealink, Polycom, Cisco) increasingly read verstat and display verification status. Older phones ignore it. The PBX or SBC can convert verstat into other indicators (e.g., display name prefix “[V]” for verified calls) for endpoints that don't natively understand it.

5. Limitations and edge cases

6. Reading verstat from a trace

verstat appears as a parameter on the From or P-Asserted-Identity header:

What to look for:

• Is verstat present at all? If absent, the verification service did not set it. Either no STIR/SHAKEN is implemented at the terminating provider, or the call did not pass through verification.
• What value is set? Passed, Failed, or No-TN-Validation determines treatment.
• Is there an Identity header? If yes and verstat=No-TN-Validation, something failed in verification. Check certificate URLs and time skew.
• Attestation level in the Identity header. Even with verstat=TN-Validation-Passed, the attestation level (A/B/C) is what determines the strength of the identity guarantee.
• Discrepancy between From and Identity orig claim. Sometimes the visible From header has been rewritten but the Identity claim is for a different number. This should produce verstat=TN-Validation-Failed but some implementations miss it.

Frequently asked questions

What is the verstat header in SIP?

verstat is a parameter on the From header (sometimes on P-Asserted-Identity) that conveys the result of STIR/SHAKEN verification. It has three possible values: TN-Validation-Passed (signature verified, calling number authorized), TN-Validation-Failed (Identity header present but verification failed), and No-TN-Validation (no Identity header was present, typically for non-IP origins). It is set by the terminating provider's verification service.

What is the difference between TN-Validation-Passed and No-TN-Validation?

TN-Validation-Passed means an Identity header was present in the INVITE, the cryptographic signature was verified, and the calling number is consistent with the signed identity. No-TN-Validation means no Identity header was present at all — typically because the call originated on a non-IP path (TDM, international gateway) where STIR/SHAKEN cannot be applied. Passed is a positive verification; No-TN-Validation is the absence of any verification, not a failure.

Does verstat=TN-Validation-Passed mean the caller ID is real?

Not necessarily. verstat=TN-Validation-Passed means the cryptographic signature verified, but the trust depends on the attestation level (A, B, or C) recorded in the Identity header. Attestation A means the originating provider directly authenticated the customer's right to use the number. Attestation C only means the call was on their network. A passed verstat with attestation C provides much weaker identity guarantees than attestation A.