Skip to main content

STIR/SHAKEN for AI Voice Builders

THIS TUTORIAL IS HIGHLY SIMPLIFIED!

The following tutorial provides a simplified overview and does not cover all aspects of STIR/SHAKEN and related topics. It is designed to provide AI builders with the basic concepts, so that they can converse with telephony providers using similar terms and jargon. For more information about STIR/SHAKEN, please refer to the its Wikipedia page.

What is STIR/SHAKEN?​

STIR (Secure Telephony Identity Revisited) is an IETF standards suite that lets a voice provider cryptographically sign the caller’s identity (typically the calling number) inside SIP signaling using a token called a PASSporT. (IETF Datatracker)

SHAKEN (Signature-based Handling of Asserted information using toKENs) is the North American deployment framework that specifies operational rules, certificate governance, and how providers should sign and verify calls in production. (IETF Datatracker)

Why you (AI Voice Builder) should care:

  • Signed, correctly attested calls reach more consumers with fewer blocks/labels.
  • Incorrect or weak attestation hurts answer rates and can trigger spam analytics flags.
  • U.S. rules increasingly push accurate attestation and tighten third-party/chain-of-custody expectations. (FCC Docs)

The moving parts (at a glance)​

  • PASSporT (JWT): A signed token asserting the calling identity (and optional extras) carried in SIP’s Identity header.
    (IETF Datatracker)
  • STI Certificates: X.509 certs that authorize a provider to sign numbers, governed by the SHAKEN ecosystem.
    (IETF Datatracker)
  • Verification Service: The terminating side validates the signature and evaluates attestation to influence treatment and display.
    (IETF Datatracker)

Attestation levels — what A / B / C actually mean​

When an originating provider signs a call, it must include an attestation level indicating its confidence that the caller is authorized to use the calling number. These levels are defined in the SHAKEN framework and reinforced by industry guidance. (FCC Docs)

  • A — Full attestation The signer has a direct relationship with the calling customer and can confirm authorization for the specific calling number. Best trust signal; most likely to display cleanly and be completed. (FCC Docs)

  • B — Partial attestation The signer knows the customer but cannot fully confirm the right-to-use for the specific number. Lower trust; can reduce answer rates. (FCC Docs)

  • C — Gateway attestation The signer is just a gateway passing the call and cannot vouch for the caller or number. Minimal trust; more likely to be labeled or blocked if other risk signals exist. (FCC Docs)

Governance note: The STI-GA has explicit guidance on improper attestation; setting the wrong level can trigger remediation or certificate action. Providers are expected to get attestation right, not just “sign something.” (sti-ga.atis.org)

What gets signed (and how it’s verified)​

  • The signer builds a PASSporT (compact JWT) with claims like originating number, destination, timestamp, and attestation level, signs it with its STI private key, and carries it in the SIP Identity header. The terminating verifier retrieves the public cert and validates the signature. (IETF Datatracker)
  • Call forwarding/diversions are handled by the PASSporT div (diverted call) extension so verifiers can trust legitimate redirects. (IETF Datatracker)

Rich Call Data (RCD) — branding on top of attestation​

Rich Call Data adds verified name/logo/subject information to the PASSporT so recipients see who’s calling, not just a number. For enterprises, A-attestation + RCD is the gold standard for branded calls and fewer false “spam” labels. (RFC Editor)

The 3 common pitfalls (and how to avoid them using Cloudonix)​

  1. Using numbers you don’t control → B/C attestation
    Fix: Use numbers you own or are explicitly assigned (LOA, invoices). When signing up for Cloudonix Termination services, you will be asked to answer and fill a KYC (Know Your Customer) form. You will be required to provide physical proof of ownership for your phone numbers. Once you do, Cloudonix will provide you with Level-A attestation, via our partners. (sti-ga.atis.org)

  2. Multi-provider chain with unclear number custody
    Fix: Make sure the entity that signs has authority to sign for your TNs, or establish compliant third-party signing/assignment documentation. Policy is tightening on who may issue A/B. Cloudonix has secured STIR/SHAKEN signatory partnership to prevent this issue. (Federal Register)

  3. Inflated attestation (claiming A without proof)
    Risk: Non-compliance; potential certificate/governance action. Fix: Only request A when KYC + number-authorization evidence support it. By signing the Cloudonix KYC, our signatory partners will properly attest to your outbound calls, presenting a Level-A attestation. (sti-ga.atis.org)

Architecture diagrams​

End-to-end call with attestation and verification​

How attestation is chosen?​

Multi-carrier pass-through (who can change what)​

Practical blueprints for AI Voice use cases​

Outbound AI agent (reminders, verifications, dispatch)​

Goal: A-attested, branded calls that get answered.

Checklist

  • Numbers: Use enterprise-owned or explicitly assigned DIDs per campaign/function; keep a clean reputation history.
  • KYC: Provide proof of number rights (LOA, invoice, CSR) to your signing provider.
  • Signing: Ensure your carrier/CPaaS signs with A for those TNs.
  • RCD: Add display name/logo/subject (“Delivery confirmation”).
  • Analytics: Track labels, answer rate, completion, and complaints; remediate before rotating TNs. (RFC Editor)

Inbound IVR → Callbacks​

  • Sign callbacks from the same authorized number block (keeps A).
  • For transfers/forwards, include div PASSporT so the chain remains trustworthy. (IETF Datatracker)

Multi-provider (CPaaS + carrier mix)​

  • Document who signs, with which certificate, and for which TN ranges.
  • If numbers live at Carrier X but you originate at Provider Y, arrange verified delegation/assignment so the signer can lawfully give A (not B/C). (sti-ga.atis.org)

How attestation influences call treatment​

Terminating carriers/analytics engines combine:

  • Signature validity (does PASSporT verify?),
  • Attestation level (A > B > C), and
  • Reputation/behavior (complaints, velocity, opt-in, purpose consistency).

Regulators emphasize that attestation must be accurate—misstating A/B/C can have consequences. (FCC Docs)

Implementation notes (for your engineering backlog)​

  • Token mechanics: PASSporT is a JWT with base claims (orig, dest, iat) and SHAKEN fields (attest, origid). Carried in SIP’s Identity header. (IETF Datatracker)
  • Freshness: Verifiers check token time (iat) to prevent replay. (IETF Datatracker)
  • Diversions: Use RFC 8946 (div) for forwarded calls. (IETF Datatracker)
  • RCD: Implement the PASSporT RCD extension (name/logo/subject) where supported. (RFC Editor)
  • Error signaling (optional): STIR error handling drafts map verification failures to 4xx responses for diagnostics. (IETF)

Security, governance, and “what not to do”​

  • Don’t request/accept A if your signer hasn’t validated your number rights; STI-GA guidance defines this as improper attestation. (sti-ga.atis.org)
  • Don’t assume signing alone fixes poor campaign hygiene—complaints and mislabeling can still rise.
  • Do align legal/ops/marketing: consent, opt-in records, and campaign clarity matter as much as signatures.

Quick reference: choosing the right path to A​

SituationLikely AttestationHow to earn/keep A
You own the numbers with the provider that signsAProvide LOA/CSR; keep assignment current; consistent campaign use. (sti-ga.atis.org)
You originate via CPaaS; numbers live elsewhereB → A (with proof)Establish verified delegation/assignment so the signer can assert A. (sti-ga.atis.org)
You place calls via a generic gateway with no KYCCAvoid; move to providers that can KYC you and validate number rights. (sti-ga.atis.org)

FAQ for AI Voice Builders​

Q: Does STIR/SHAKEN apply to every call? A: On IP interconnects among participating North American providers, yes—coverage continues expanding as exemptions shrink. (FCC Docs)

Q: Can my brand/logo show on the handset? A: Yes—where supported—via RCD combined with valid signing. Adoption is expanding across networks and devices. (RFC Editor)

Q: We keep getting B or C even though we’re legitimate—why? A: Your signer may lack a paper trail proving your right to the TNs. Fix delegation/assignment and KYC so they can elevate to A. (sti-ga.atis.org)

Q: Are there penalties for wrong attestation? A: The FCC and STI governance treat incorrect attestation as non-compliance; repeated issues can lead to enforcement or certificate scrutiny. (FCC Docs)

Deeper dives (authoritative sources)​

Your action plan (paste into your backlog)​

  1. Inventory every calling number by use-case; map ownership & assignment.
  2. Pick a signing path: your carrier signs; your CPaaS signs with verified TNs; or compliant third-party signing (with A-eligibility). (Federal Register)
  3. Deliver KYC + TN proof (LOA, invoice, CSR) to the signer; request A where eligible. (sti-ga.atis.org)
  4. Add RCD (name/logo/subject) for key campaigns; A/B test answer rates. (RFC Editor)
  5. Instrument analytics (labels, answer rate, completion, complaints) and remediate early.
  6. Harden transfers/forwards using div PASSporT. (IETF Datatracker)
  7. Quarterly review: FCC/ATIS updates, certificate health, attestation correctness. (FCC Docs)