STIR/SHAKEN on Asterisk and FreePBX

Asterisk supports STIR/SHAKEN natively. The rewritten res_stir_shaken module (18.22.0, 20.7.0, 21.2.0) signs outbound calls at A, B, or C attestation and verifies inbound ones. But a signature carriers trust needs your own SHAKEN SP certificate, and only qualifying voice service providers can get one. For nearly every self-hosted PBX, the practical path is a carrier that signs at A-level.

“Can Asterisk do STIR/SHAKEN?” is really two questions. Can the software build a signed Identity header? Yes, in recent versions. Will any verifier trust that signature? Not without credentials most PBX operators cannot get. This guide separates the two. It then covers what a FreePBX or VICIdial shop can actually deploy.

What Asterisk actually supports

Asterisk’s first attempt shipped in 16.15.0. It added a per-endpoint PJSIP stir_shaken option with outbound INVITE signing and inbound verification. The official deployment docs now call that original code “only partially functional and not interoperable with other implementations.” On an old LTS branch, the module you have is decorative.

The working implementation is the complete rewrite, the “Stir/Shaken Refactor.” It landed in 18.22.0, 20.7.0, and 21.2.0 in early 2024. Its stated goals were interoperability, RFC compliance, and performance. Two migration facts matter. First, stir_shaken.conf changed significantly, so pre-refactor configs must be rewritten. Second, the module now needs the libjwt v1.15.3 dev package, or a build with --with-libjwt-bundled.

Post-refactor, res_stir_shaken covers both directions:

Direction	What the module does
Outbound (attestation)	Creates and signs SIP Identity headers at Full (A), Partial (B), or Gateway (C) level
Inbound (verification)	Certificate chain verification, CRL checking, signature validation, timestamp validation

Configuration lives in stir_shaken.conf and uses four object types. An attestation object holds the private key, the public certificate URL, and the attestation level. Per-number tn objects are keyed by the canonicalized number, which must start with the country code. A verification object points at CA and CRL files and controls certificate caching. Finally, profile objects attach to chan_pjsip endpoints through stir_shaken_profile.

The docs are equally candid about limits. Asterisk does not validate the destination TN. It cannot verify that the Service Provider Code in a certificate has authority over the calling number. And it does not fetch CRLs in real time from certificate extensions. The heavy trust decisions in how STIR/SHAKEN works happen in the certificate ecosystem, not in your dialplan.

Why you almost certainly cannot self-sign

Here is the part the tutorials skip. The module’s attestation config wants a private key and a certificate URL. But the certificate must come from an approved STI Certification Authority. And an STI-CA only issues one against an SPC token from the STI Policy Administrator (iconectiv). The STI-GA’s token access policy sets the gate:

• a current FCC Form 499A on file (or proof of payment of the annual RespOrg fee);
• an assigned Operating Company Number (OCN) or a Resp Org ID;
• FCC certification of STIR/SHAKEN implementation or Robocall Mitigation Program compliance, listed in the FCC database — or status as a non-carrier RespOrg with direct toll-free number access.

iconectiv enforces this hard. The OCN must be eligible for numbering-resource assignments, which proves direct access to numbers from NANPA and the Pooling Administrator. The STI-PA checks your 499A filing status with the FCC. Annual fees are calculated from 499A revenue lines.

A call center running FreePBX under a dialer holds none of that. No numbering-eligible OCN. No 499A as a telecommunications provider. No RMD certification as a voice service provider. Call centers generally cannot meet the STI-PA criteria. The one exception is an operation that also runs as a carrier in its own right. So only an upstream carrier can sign the calls.

The FCC has also closed the borrow-a-certificate loophole. The Eighth Report and Order (FCC 24-120, adopted November 21, 2024) reaches every provider with a STIR/SHAKEN obligation. Each must obtain its own SPC token and sign with its own certificate “whether directly or through a third party.” Signing under a third party’s certificate is out. Even outsourced signing leaves the attestation-level decision with the obligated provider. The rule’s effective date, and what it means for signing services, is covered below.

What B-attestation means for your traffic

When a middleman signs your calls, the level depends on what it can verify. The FCC quotes the ATIS definitions. A-level requires a verified association between you and the calling number. B-level means the provider can identify you as a customer but has not verified your right to that caller ID. Analytics engines treat partial (B) attestation as a lower-trust signal; no carrier publishes a specific answer-rate gap. The full comparison is in A-level vs. B-level attestation. The reseller-chain version is covered in reseller vs. carrier attestation.

The architectures that actually work

Once self-signing is off the table, two useful patterns remain for a self-hosted Asterisk or FreePBX deployment.

1. The carrier signs everything (recommended)

Your PBX does nothing STIR/SHAKEN-related outbound. No attestation object, no certificates on disk. Calls leave your trunk unsigned, and the carrier’s switch attests them on entry. When the carrier holds its own SP certificate and has verified your DIDs, that signature is A-level. The entity with the FCC filings, the OCN, and the number relationships makes the attestation claim. That is how the ecosystem was designed.

Bias disclosed: this is what SIPNEX does. We are an FCC-licensed carrier with our own STIR/SHAKEN SP certificate. We sign outbound calls directly at A-level on verified DIDs; details are on our STIR/SHAKEN compliance page. The evaluation question for any carrier is the same. Do they sign with their own certificate, or does someone upstream sign for them?

2. Asterisk as an inbound verifier

The verification side of res_stir_shaken needs no SPC token. It works from the signer’s public certificate and a configured CA trust list. On an inbound trunk, your dialplan can see whether a call arrived signed and whether the signature held up. That is useful for screening or logging on DIDs you control. The documented caveat still applies: Asterisk cannot confirm the signer’s authority over the specific calling number.

Configuring Asterisk verification step by step

Verification is the one piece of res_stir_shaken a PBX can run end to end. Here is the shape of a minimal setup. The values come from the shipped stir_shaken.conf.sample and the deployment guide.

[verification]
global_disable = no
load_system_certs = no
ca_path = /var/lib/asterisk/keys/stir_shaken/verification_ca
cert_cache_dir = /var/lib/asterisk/keys/stir_shaken/verification_cache
failure_action = continue
curl_timeout = 5
max_iat_age = 60
max_date_header_age = 60

[inbound_verify]
type = profile
endpoint_behavior = verify

Then point the inbound trunk endpoint at the profile in pjsip.conf with stir_shaken_profile = inbound_verify. The endpoint_behavior value picks the direction: off, attest, verify, or on for both. Leave the carrier trunk you dial out on at off or verify. An unsigned INVITE is exactly what a signing carrier expects to receive.

Three failure_action values decide what happens when a check fails. continue lets the call through and leaves the decision to your dialplan. reject_request rejects the INVITE at once with the RFC 8224 response codes. continue_return_reason lets the call continue but sends the originator a SIP Reason header in the next provisional response. With use_rfc9410_responses = yes, that Reason header carries the newer STIR protocol value from RFC 9410 instead of SIP.

Two timing knobs trip people up. Asterisk checks the age of the PASSporT’s iat claim and the age of the SIP Date header. Both default to 15 seconds (max_iat_age, max_date_header_age); the sample config raises both to 60. A sender that omits the Date header fails verification. The deployment guide is blunt: the sender “MUST also send a SIP Date header.”

Every verification also fetches the signer’s certificate from the x5u URL in the Identity header, unless the cache already holds it. By default that URL must use https on port 443 or 8443, and its path is restricted too. The relax_x5u_port_scheme_restrictions and relax_x5u_path_restrictions options loosen those rules; the docs label both a security risk. Use x5u_permit, x5u_deny, or x5u_acl to fence which hosts Asterisk will fetch from.

Reading the result in the dialplan

With failure_action = continue, the STIR_SHAKEN() dialplan function exposes the outcome. STIR_SHAKEN(count) returns how many Identity headers were processed. For a given index, the fields are identity, attestation, and verify_result:

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)})
same => n,NoOp(Verification result: ${STIR_SHAKEN(0, verify_result)})

If you decide to drop the call from there, the deployment guide points at PJSIPHangup(). It can reject the call with a STIR/SHAKEN-specific SIP response code instead of a generic one.

FreePBX STIR/SHAKEN options compared

FreePBX has no native STIR/SHAKEN GUI module. Sangoma staff said it plainly on the official forum in May 2022: “FreePBX doesn’t have support for it, and the Asterisk module itself needs further work.” As of Sangoma’s published documentation, nothing native has replaced that answer.

What the docs portal carries instead are community-contributed guides in its FreePBX Community Documentation space. They wire third-party signing services (TransNexus ClearIP, Sansay NSS, TILTX) in front of FreePBX. An external service signs; FreePBX itself never does. Here is how the realistic FreePBX paths compare:

Path	How it attaches to FreePBX	What you must bring	Where the signature is made
Carrier signs on entry (recommended)	Nothing changes on the PBX; the trunk stays unsigned	Verified DIDs on a carrier with its own SP certificate	The carrier’s switch
TransNexus ClearIP	A separate in-line SIP proxy host, plus a new chan_pjsip trunk pointed at it with authentication and registration set to none	ClearIP subscription, a host for the proxy, a provider that accepts IP authentication	The in-line proxy
Sansay NSS API	A macro-dialout-trunk-predial-hook runs a bash script on every outbound call and injects the Identity header; no proxy or SBC in the path	Sansay NSS account, a STIR/SHAKEN certificate, the jq utility	The Sansay service, via API
res_stir_shaken self-signing	Native attestation object plus a profile with endpoint_behavior = attest	Your own SP certificate from an STI-CA, which needs an SPC token	Your Asterisk box

Both community guides target FreePBX/PBXact 15 and 16. Read the Sansay prerequisites closely: the list includes “A STIR/SHAKEN certificate.” The API applies a signature; it does not conjure the credential.

That is the test for every third-party path. A valid signature has to chain to a certificate issued against an SPC token. If your operation cannot get that token, the signature is being made under a credential that belongs to a provider. And the FCC’s third-party rules now govern exactly that arrangement.

The ClearIP guide explains why the proxy exists: “ClearIP does this by means of a SIP signaling mechanism that can’t easily be consumed directly by FreePBX. It relies on an external SIP proxy to perform the S/S signature.” On plain Asterisk, TransNexus documents a redirect model instead. The dialplan dials a clearip endpoint configured with redirect_method = uri_pjsip. A pre-dial subroutine carries the P-Asserted-Identity and Identity headers across with PJSIP_HEADER(add,...). Asterisk then sends the call to whatever destination ClearIP returns.

If running the box yourself is the real problem, FreePBX hosting from SIPNEX takes the PBX out of your rack and the signing question with it.

VICIdial specifics

VICIdial is the same story. Its documented STIR/SHAKEN support is the official TILTX integration (svn/trunk 3449+). An AGI script runs before each outbound carrier dial. It tags the call with X-TILTX-ID, Identity, and CAID headers for TILTX’s service. Nothing in VICIdial’s documentation gives the dialer a certificate or signing role; the headers are tags for TILTX’s service. If your dialer trouble is broader than signing, start with the VICIdial troubleshooting guide.

What the FCC’s third-party signing rule changed

Third-party signing services sat in a gray zone until 2025. The Eighth Report and Order settled it. A provider with a STIR/SHAKEN obligation may let a third party perform “the technological act of signing calls.” Two conditions apply. The obligated provider makes every attestation-level decision. And every call is signed with that provider’s own certificate from an STI-CA, “not the certificate of a third party.” The order adds recordkeeping duties for any such agreement.

The order also spells out who the obligated party is. The rules apply to providers with control over the network infrastructure needed to implement STIR/SHAKEN. Under ATIS-1000074, only the provider that originates the call onto the IP service-provider network may apply A- or B-level attestation. The FCC defines that originating provider as the one handling a customer’s outgoing calls “at the point at which they are entering the public network.” For a FreePBX shop on a SIP trunk, that point is the carrier’s switch, not the PBX.

Two consequences follow. A signing service in front of your PBX cannot move accountability for the attestation; it stays with the provider whose certificate signs the call. And a provider that lets a third party’s certificate sign its traffic is now in violation. The final rule ran in the Federal Register on August 19, 2025 and took effect 30 days later, on September 18, 2025.

A-level is not a checkbox, either. The same order cites the FCC’s 2024 notice against Lingo Telecom (FCC 24-60). That notice proposed a $2,000,000 forfeiture for apparent violations of the caller ID authentication rule, over calls Lingo had signed at A-level. The lesson for a PBX operator is simple. The carrier that signs your calls has a strong reason to verify your numbers before it grants A.

A FreePBX trunk checklist for carrier signing

If the carrier signs, your job is to keep its A-level claim true on every call. Four checks cover most deployments:

1. Send only caller IDs the carrier has verified. A-level rests on a verified association between customer and number. Pin the trunk’s outbound caller ID to DIDs you hold on that carrier. Keep rotating or borrowed numbers out of the outbound routes.
2. Match the caller ID format the carrier verified. Ask whether it expects 10 or 11 digits, and set the outbound route’s caller ID rules to match. A number the carrier cannot match to a verified DID has no verified association, so it cannot get A.
3. Leave outbound attestation off. Do not configure an attestation object for the carrier trunk. The carrier attests on entry; an Identity header from a PBX without a valid certificate adds nothing it can trust.
4. Check the carrier in the Robocall Mitigation Database. The FCC’s database is public. Under FCC 24-120, a provider certifying complete or partial STIR/SHAKEN implementation there must hold its own SPC token and sign with its own certificate. The Robocall Mitigation Database explainer covers how to read a filing.

How to check what your calls get today

Ask your carrier, in writing: who signs your outbound calls, with whose certificate, at what attestation level. A carrier signing with its own SP certificate answers in one sentence. Vague talk of “upstream partners” usually means B or C attestation applied somewhere you can’t see.

Then test. Point an inbound DID you control at your Asterisk box with verification enabled. Call it from your own outbound trunk. The Identity header (or its absence) and the verification result show what the far end sees. If your traffic is drawing “Network Blocked” responses instead, that is a different diagnosis path: see SIP code 603.

Frequently asked questions

Can Asterisk sign calls with STIR/SHAKEN on its own?

Technically yes, practically no. The refactored res_stir_shaken module can create and sign Identity headers at A, B, or C attestation. But a signature only counts when it chains to an SP certificate issued against an STI-PA SPC token, and those go only to qualifying voice service providers. Without that credential the module has nothing valid to sign with. That is why self-hosted deployments rely on carrier-side signing.

Which Asterisk versions have working STIR/SHAKEN support?

Use 18.22.0, 20.7.0, or 21.2.0 and later. Those versions carry the complete rewrite. The original implementation from 16.15.0 is described in Asterisk’s own deployment docs as only partially functional and not interoperable with other implementations. The refactor also changed stir_shaken.conf significantly and added a build requirement: libjwt v1.15.3 dev packages, or configuring with —with-libjwt-bundled.

Does FreePBX add STIR/SHAKEN signing on top of Asterisk?

No. FreePBX has no native STIR/SHAKEN module. Sangoma staff confirmed this on the official forum in May 2022, and as of Sangoma’s published documentation that has not changed. The guides on Sangoma’s docs portal are community-contributed walkthroughs for external signing services like TransNexus ClearIP, Sansay NSS, and TILTX. In each one a third-party service or SIP proxy applies the signature before the call reaches the carrier.

Why can’t my Asterisk call center get its own SHAKEN certificate?

Because the STI-PA gate is built for carriers. An SPC token requires a current FCC Form 499A filing (or RespOrg fee payment), an assigned OCN or Resp Org ID, and FCC certification listed in the Robocall Mitigation Database. A call center generally holds none of those. It buys numbers from a carrier rather than receiving them from NANPA. So only an upstream provider that meets the criteria can sign its calls.

What attestation level do calls from a self-hosted Asterisk box get?

Whatever the signing carrier assigns; the PBX does not decide. A carrier with a verified association between you and the calling number can attest A-level. One that can only identify you as a customer attests B. Ask in writing which level applies to your DIDs, and verify with a test call to a number you control.

What does failure_action do in Asterisk’s stir_shaken.conf?

It sets what Asterisk does when an inbound Identity header fails verification. The default, continue, passes the call to the dialplan, where the STIR_SHAKEN function exposes the result. The reject_request value rejects the INVITE with the RFC 8224 response codes. The continue_return_reason value lets the call proceed but returns a SIP Reason header to the originator in the next provisional response. The setting lives in the verification object or in a per-endpoint profile.

How do I read the STIR/SHAKEN verification result in an Asterisk dialplan?

Use the STIR_SHAKEN dialplan function. STIR_SHAKEN(count) returns how many Identity headers Asterisk processed on the channel. STIR_SHAKEN(0,identity), STIR_SHAKEN(0,attestation), and STIR_SHAKEN(0,verify_result) return the caller identity, the attestation level, and the verification outcome for the first one. It only helps when failure_action is continue or continue_return_reason; with reject_request the call never reaches the dialplan.

Does a FreePBX shop need its own certificate for ClearIP or Sansay signing?

For the Sansay NSS path, yes on paper: the FreePBX community guide lists “A STIR/SHAKEN certificate” among its prerequisites. The ClearIP guide does not say whose certificate the proxy signs with. Either way, an STI-CA only issues certificates against an SPC token, and call centers generally do not qualify for one. So the credential behind any third-party signature belongs to a qualifying provider, and the FCC’s 2025 third-party rules hold that provider accountable.

When did the FCC’s third-party STIR/SHAKEN signing rule take effect?

September 18, 2025. The Eighth Report and Order (FCC 24-120) was adopted on November 21, 2024 and released the next day. Its final rule was published in the Federal Register on August 19, 2025 and took effect 30 days after publication. Since then, a provider with a STIR/SHAKEN obligation that uses a third party to sign must still hold its own SPC token and certificate, make its own attestation-level decisions, and keep records of the arrangement.

---

SIPNEX is an FCC-licensed carrier with its own STIR/SHAKEN SP certificate. Outbound calls on verified DIDs are signed directly at A-level, and we are registered in the Robocall Mitigation Database. If your self-hosted PBX or dialer is stuck at B-attestation behind a middleman, see how our STIR/SHAKEN signing works or talk to us about your trunks.