In the United States alone, consumers received an estimated 55 billion robocalls in 2023. The problem is not just volume; it is trust. When a caller ID can be trivially spoofed by inserting any number into the SIP From header, recipients have no way to know whether an incoming call is legitimate. STIR/SHAKEN is the industry's answer: a cryptographic framework that lets originating carriers sign their calls and terminating carriers verify those signatures, creating an auditable chain of attestation for every call that traverses the network.
The Two RFCs: Identity and PASSporT
STIR/SHAKEN is built on two complementary IETF standards. RFC 8224 (Authenticated Identity Management in SIP) defines how identity information is carried in SIP messages. It introduces the Identity header field, which contains a signed token that asserts the caller's identity. RFC 8225 (PASSporT: Personal Assertion Token) defines the token format itself, a compact JSON Web Token (JWT) that encodes the calling number, called number, attestation level, and a unique origination identifier.
The "STIR" part stands for Secure Telephone Identity Revisited. "SHAKEN" stands for Signature-based Handling of Asserted information using toKENs. Together, they define both the data format (what gets signed) and the operational framework (who signs it, who verifies it, and how certificates are managed).
The Three Attestation Levels
Not every call has the same relationship to the originating carrier. STIR/SHAKEN defines three attestation levels to express how much the signing carrier knows about the caller:
- Full Attestation (A): The carrier has authenticated the caller and can confirm they are authorized to use the calling number. This is the strongest level. It typically applies to calls from directly connected enterprise PBXs or retail subscribers where the carrier controls number assignment.
- Partial Attestation (B): The carrier has authenticated the caller (they have a legitimate account) but cannot verify that the caller is authorized to use the specific calling number. This commonly applies to wholesale or reseller traffic where the carrier knows the upstream partner but not the end subscriber.
- Gateway Attestation (C): The carrier received the call from an international gateway or a network where it has no relationship with the originator. The carrier can only attest that it is the entry point into the US network. This level provides the least information but still establishes accountability for where the call entered the domestic network.
The attestation level is not a quality score. A legitimate international call from a known foreign carrier will receive a C attestation, and that is correct. The value is in the accountability: every call that enters the US network is traceable to a specific carrier that signed it at a specific attestation level.
How PASSporT JWTs Work
A PASSporT is a standard JWT with three parts: header, payload, and signature. The header identifies the signing algorithm and references the certificate used to verify the signature:
{
"alg": "ES256",
"ppt": "shaken",
"typ": "passport",
"x5u": "https://cert.example.com/certs/sp-1234.pem"
}The x5u field contains a URL where the verifying party can download the signing certificate. The algorithm is always ES256 (ECDSA with P-256 and SHA-256), which provides strong security with compact signatures suitable for real-time SIP processing.
The payload contains the identity claims:
{
"attest": "A",
"dest": { "tn": ["12125551234"] },
"iat": 1735257600,
"orig": { "tn": "12125559876" },
"origid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}attest-- the attestation level (A, B, or C)orig.tn-- the calling party number in E.164 formatdest.tn-- the called party number(s) in E.164 formatiat-- the issued-at timestamp (Unix epoch seconds)origid-- a UUID that uniquely identifies this call, used for traceback
The signature is computed over the Base64URL-encoded header and payload using the carrier's private key. The complete PASSporT is then placed in the SIP Identity header as a compact JWT (header.payload.signature), along with metadata parameters that specify the signing algorithm and PASSporT type.
The Certificate Chain
The trust model relies on a hierarchical PKI. At the top is the STI-PA (Secure Telephone Identity Policy Administrator), currently operated by iconectiv in the US. The STI-PA authorizes STI-CAs (Certificate Authorities) to issue certificates. Each carrier obtains an STI certificate from an authorized STI-CA, proving that they hold a valid Service Provider Code (SPC) token issued by the STI-PA.
The chain looks like this:
- STI-PA verifies the carrier's identity and issues an SPC token
- STI-CA validates the SPC token and issues an X.509 certificate with a TNAuthList extension (listing the telephone numbers or number ranges the carrier is authorized to sign for)
- Service Provider uses the certificate's private key to sign PASSporTs for outbound calls
- Verifying carrier downloads the certificate from the
x5uURL, validates it against the STI-CA root, and checks the signature
Certificates have a defined lifetime (typically 90 days) and must be renewed. The x5u URL must be publicly accessible over HTTPS so that any terminating carrier can fetch the certificate for verification without requiring a pre-existing business relationship with the originating carrier.
Verification at the Terminating Carrier
When a terminating carrier receives a SIP INVITE with an Identity header, the verification process follows these steps:
- Extract the PASSporT from the Identity header and decode the JWT header to get the
x5uURL - Fetch the certificate from the
x5uURL (with caching; most implementations cache certificates for their validity period) - Validate the certificate chain against the trusted STI-CA roots, checking expiration, revocation status, and that the TNAuthList extension covers the calling number
- Verify the JWT signature using the public key from the certificate
- Check freshness: the
iattimestamp must be within a configurable window (typically 60 seconds) to prevent replay attacks - Compare claims: verify that the
origanddestnumbers in the PASSporT match the SIP From and To headers
If verification succeeds, the terminating carrier knows the identity of the signing carrier and the attestation level they assigned. This information can be passed to the called party as a "verified caller" indicator, and it can inform call analytics systems that score calls for spam likelihood.
How MOBITELSMS Implements STIR/SHAKEN
The MOBITELSMS platform includes a dedicated STIR/SHAKEN module that implements the full RFC 8224/8225 specification. The implementation is structured around three core operations:
Certificate Management
Certificates are stored in the stirshaken_certificates database table and loaded into memory at startup. Each origination point (OP) can be associated with a specific certificate via the stirshaken_certificate_id field, allowing multi-tenant deployments where different customers sign with different identities. Certificate renewal is handled automatically; when a certificate approaches expiration, the system alerts the operator via the admin dashboard.
Outbound Signing
During call authorization, when the routing engine selects a termination point, the module checks whether the origination point has STIR/SHAKEN enabled. If so, it constructs a PASSporT JWT with the appropriate attestation level (determined by the OP's configuration), signs it with the certificate's private key using ES256, and inserts the Identity header into the outbound SIP INVITE. The entire signing operation adds less than 1ms to the authorization path.
// Simplified signing flow
passport.header.alg = "ES256";
passport.header.x5u = certificate.public_url;
passport.payload.attest = attestation_level; // "A", "B", or "C"
passport.payload.orig.tn = calling_number;
passport.payload.dest.tn = called_number;
passport.payload.iat = current_timestamp();
passport.payload.origid = generate_uuid();
identity_header = jwt_sign(passport, certificate.private_key);Inbound Verification
For inbound calls that arrive with an Identity header, the module performs the full verification chain described above. The verification result is stored in the call data record (CDR), including the attestation level and whether verification succeeded or failed, along with the reason for any failure (expired certificate, signature mismatch, stale timestamp, etc.). This data feeds into analytics dashboards that track verified vs. unverified traffic patterns over time.
Impact on Call Completion and Caller ID Trust
Carriers that implement STIR/SHAKEN signing see measurable improvements in call completion rates. Calls with valid A-level attestation are significantly less likely to be blocked by downstream call analytics platforms. Some terminating carriers and analytics vendors explicitly boost the reputation score of calls that carry verified signatures, resulting in higher answer rates.
For carriers that do not implement STIR/SHAKEN, the situation is deteriorating. The FCC's mandate requires all US carriers to implement STIR/SHAKEN on IP portions of their network. Carriers without signing capability increasingly find their traffic flagged or blocked, particularly for high-volume A2P voice traffic where analytics platforms apply aggressive filtering.
The MOBITELSMS implementation signs all outbound calls by default when a certificate is configured. There is no opt-in process per call or per route; if the origination point has a valid certificate, every call gets signed. This zero-configuration approach ensures complete coverage and eliminates the risk of unsigned calls leaking through misconfigured routes.
For operators looking to implement or upgrade their STIR/SHAKEN deployment, MOBITELSMS supports the complete lifecycle: certificate provisioning, automatic signing on all outbound traffic, inbound verification with CDR-level reporting, and dashboard analytics for monitoring attestation distribution across your traffic. See our STIR/SHAKEN service page for configuration details.