STIR/SHAKEN for Asterisk and FreePBX: Attestation and Who Signs

Short answer: STIR/SHAKEN is the US caller ID authentication framework: the originating voice provider signs each call with a certificate and an attestation level (A, B or C), and the terminating provider verifies it. If you run Asterisk or FreePBX behind a SIP trunk, your provider signs your calls, not your PBX; your job is to send caller IDs the provider has assigned to you so it can give A attestation. Asterisk’s res_stir_shaken can also sign and verify, but signing is only for providers with their own certificate. Since the FCC’s third-party authentication rules (FCC 24-120, compliance in 2025), providers that outsource signing must have calls signed with their own certificate.

Asterisk details checked against the official STIR/SHAKEN documentation, and the FCC rule against the Federal Register notice (both linked below), on 6 October 2026. On our lab server (Debian 12, FreePBX 17.0.33, Asterisk 22.11) we confirmed the modules, CLI commands and the STIR_SHAKEN() function. This is a technical overview, not legal advice.

What STIR/SHAKEN does

Robocallers spoof caller ID because plain SIP lets the sender put any number in the From header. STIR/SHAKEN adds a signed token to the call:

• STIR is the IETF work: the SIP Identity header and the PASSporT token it carries, a signed JSON Web Token with the calling number, the called number and a timestamp.
• SHAKEN is the industry profile for how US carriers use it: who issues certificates, how they are checked, and the attestation levels.
• The originating provider signs. The terminating provider fetches the certificate from the URL in the token (the x5u), checks the signature and chain, and passes a verdict to its analytics and the called party’s display.

It only works end to end on SIP between providers. A call that crosses a TDM link loses the token.

Attestation levels A, B and C

Level	Name	What the signing provider asserts
A	Full	It knows the customer who placed the call and that customer is authorised to use the calling number
B	Partial	It knows the customer, but cannot confirm the customer is authorised to use that number
C	Gateway	It only knows where it received the call (for example from another network or an international gateway)

For a business PBX, the practical rule is: send a caller ID that your trunk provider assigned to your account. Typical reasons for B or C on calls you think should be A:

• The PBX sends a number from another carrier (for example a main number ported to a different provider than the outbound trunk).
• Forwarded calls or follow-me: the PBX passes the original caller’s number out through your trunk, which your provider cannot vouch for.
• A cloud dialer or contact-centre platform sends calls through your trunk with numbers you never registered with the provider.

Ask your provider how to register numbers you own elsewhere (some have a process for this) and what attestation they give forwarded calls. Our number porting guide helps if moving numbers to one provider is the cleaner fix.

Who signs: provider or PBX?

In the US framework, signing is done with a certificate issued to a voice service provider. Getting one involves an SPC token from the STIR/SHAKEN Policy Administrator and a certificate from an approved certification authority, which in turn requires provider registrations. A business running FreePBX behind a SIP trunk is a customer, not a provider, so:

• Typical PBX owner: does not sign. The trunk provider signs the INVITE after it leaves your PBX.
• Provider or reseller running Asterisk as its switch: may need to sign, with its own certificate. This is where res_stir_shaken attestation is used.
• Anyone receiving calls: can verify incoming Identity headers, or simply read the verdict the upstream provider passes on.

The 2025 third-party authentication change

Many smaller providers used to pay a vendor to sign calls with the vendor’s certificate. The FCC’s Eighth Report and Order (FCC 24-120, released 22 November 2024) ended that: a provider may still use a third party to do the signing, but calls must be signed with the certificate of the provider that has the obligation, not the third party’s.

The compliance date caused some confusion. The order set it at 30 days after Federal Register publication following OMB approval, or 210 days after release, whichever is later. 210 days after release was 20 June 2025, the date providers and the FreePBX community widely announced. The Federal Register notice was published on 19 August 2025 and states the rules are effective 18 September 2025. If your provider used a third party’s certificate, check that it now signs with its own.

STIR/SHAKEN in Asterisk (res_stir_shaken)

Asterisk’s STIR/SHAKEN support was rewritten in early 2024. The new implementation is in Asterisk 18.23.0+, 20.8.0+, 21.3.0+ and all of 22. Our Asterisk 22.11 lab had both modules running:

Module                         Description                              Use Count  Status      Support Level
res_pjsip_stir_shaken.so       PJSIP STIR/SHAKEN Module for Asterisk    0          Running              core
res_stir_shaken.so             STIR/SHAKEN Module for Asterisk          1          Running              core

Configuration lives in stir_shaken.conf with four object types:

Object	Purpose	Key options
attestation (one)	Defaults for signing outgoing calls	private_key_file, public_cert_url, attest_level
tn (one per number)	Per caller ID signing settings; the ID is the canonical number	overrides of key, certificate URL, level
verification (one)	How incoming Identity headers are checked	ca_file/ca_path, cert_cache_dir, failure_action, max_iat_age
profile (any number)	Per endpoint behaviour	endpoint_behavior = off, attest, verify or on

A profile is attached to a PJSIP endpoint with stir_shaken_profile. A verify-only setup for a trunk, based on the official examples:

; stir_shaken.conf
[verification]
ca_path = /var/lib/asterisk/keys/stir_shaken/verification_ca
cert_cache_dir = /var/lib/asterisk/keys/stir_shaken/verification_cache
failure_action = continue

[verify-trunk]
type = profile
endpoint_behavior = verify

; pjsip.conf
[provider-a]
type = endpoint
stir_shaken_profile = verify-trunk

failure_action defaults to continue; reject_request rejects failed calls with a 4xx response, and continue_return_reason lets the call through but adds a Reason header. Start with continue and read the results before rejecting anything.

Read the result in the dialplan with the STIR_SHAKEN() function. This example is from the function’s own help on Asterisk 22:

 same => n,NoOp(Number of STIR/SHAKEN identities: ${STIR_SHAKEN(count)})
 same => n,NoOp(Identity ${STIR_SHAKEN(0, identity)} has attestation level ${STIR_SHAKEN(0, attestation)})

The third value, verify_result, tells you whether verification passed. You could, for example, route calls with failed verification to voicemail instead of ringing staff.

Check your setup from the CLI

These commands exist on Asterisk 22.11 (from core show help on our lab):

asterisk -rx "stir_shaken show profiles"
asterisk -rx "stir_shaken show eprofiles"
asterisk -rx "stir_shaken show verification"
asterisk -rx "stir_shaken show attestation"
asterisk -rx "stir_shaken show tns"

On our lab the configuration file was the shipped sample with everything commented out, so stir_shaken show profiles printed No stir/shaken profiles found, and stir_shaken show verification and stir_shaken show attestation failed because neither object existed. That is the normal state of a fresh install. “eprofiles” are the effective profiles Asterisk builds by merging the attestation, verification and profile settings; check them after a change.

Asterisk 20.10.0, 21.5.0 and later also have stir_shaken verify certificate_file to test a certificate against the verification store.

FreePBX notes and common problems

The open-source FreePBX 17 modules on our lab include no STIR/SHAKEN settings page; FreePBX ships the Asterisk sample stir_shaken.conf. If you want verification on FreePBX, you configure Asterisk directly, and the endpoint setting has to be added in a way FreePBX will not overwrite (custom PJSIP config files). For most FreePBX owners it is simpler to ask the provider what it passes on: some providers add a verification result to inbound calls in a SIP header, which you can inspect with pjsip set logger on.

• Your outbound calls show as spam or “unknown”: check the attestation your provider gives (ask them, or test to a phone on a carrier that shows it). Fix the caller ID first; B and C calls are more likely to be flagged by analytics.
• Caller ID changed in the dialplan breaks signatures: the Asterisk docs note that it signs CALLERID(num); if you rewrite From or P-Asserted-Identity headers separately, the token no longer matches.
• Verification fails with time errors: max_iat_age and max_date_header_age default to 15 seconds. Keep NTP running on the PBX.
• Certificate download timeouts: curl_timeout defaults to 2 seconds; outbound HTTPS from the PBX must be allowed.

Official documentation: Asterisk: STIR/SHAKEN · Asterisk: res_stir_shaken module configuration · Federal Register: Call Authentication Trust Anchor (FCC 24-120)

Related: SIP Response Codes: Lookup for Every SIP Error, With Causes and Fixes · Port Phone Number to VoIP: 6 Steps and Common Rejections Explained · Troubleshoot SIP Calls with sngrep and the Asterisk PJSIP Logger · SIP Trace Analyzer: Find NAT, Codec and Dropped-Call Problems in a SIP Log

See also: STIR/SHAKEN Identity Header Decoder (PASSporT)

Frequently asked questions