{"slug":"stir-shaken","title":"STIR/SHAKEN — Caller ID Attestation and the TRACED Act","tags":["stir-shaken","caller-id","traced-act","attestation","robocall","sip"],"agent_summary":"STIR/SHAKEN is the FCC-mandated framework that cryptographically signs caller ID on IP-based voice calls. Originating carriers attest to caller identity at three levels — A (full), B (partial), C (gateway) — and downstream carriers verify the SIP Identity header to flag spoofed traffic. Required for all US carriers since 2021-06-30 under the TRACED Act.","trigger_phrases":["STIR SHAKEN","caller ID attestation","TRACED Act","SIP Identity header","attestation A B C","spoofed caller ID","robocall framework","signed caller ID"],"runnable":false,"markdown":"\n# STIR/SHAKEN\n\nSTIR (Secure Telephony Identity Revisited) and SHAKEN (Signature-based Handling of Asserted information using toKENs) are the IETF and ATIS standards that authenticate caller ID on IP-based voice calls. Originating carriers sign the calling number with a private key; terminating carriers verify the signature. The FCC required compliance for all US carriers by 2021-06-30 under the TRACED Act of 2019.\n\n## How the signature flows\n\n1. Originating carrier receives a SIP INVITE from a customer.\n2. Carrier evaluates how confident it is in the calling number's legitimacy.\n3. Carrier mints a JWT (the PASSporT) with claims for `orig`, `dest`, `iat`, and `attest`.\n4. The JWT is signed with the carrier's private key (issued by an STI-CA).\n5. The signed token is inserted in the SIP `Identity` header.\n6. Each transit and terminating carrier verifies the signature against the public cert.\n\n## Three attestation levels\n\n| Level | Name | Meaning |\n|---|---|---|\n| **A** | Full attestation | Carrier authenticated the customer AND confirmed the customer is authorized to use the calling number |\n| **B** | Partial attestation | Carrier authenticated the customer but cannot confirm the customer owns the calling number |\n| **C** | Gateway attestation | Carrier received the call from an upstream gateway (often international) and cannot authenticate the origin |\n\nVoice service providers must reach attestation A on traffic they directly originate from verified customers. Wholesale and resale traffic typically lands at B. International gateway traffic lands at C.\n\n## What downstream carriers do with the result\n\n| Verification result | Common terminating behavior |\n|---|---|\n| Verified A | Display name shown, no spam label |\n| Verified B | Display name shown, may add \"verified\" indicator |\n| Verified C | Pass-through, may add \"unverified\" tag |\n| Verification failed | Many carriers add \"Spam Likely\" or \"Scam Likely\" caller ID tag |\n| Missing Identity header | Some carriers block, most add a warning label |\n\n## SignalWire and STIR/SHAKEN\n\nSignalWire signs outbound calls automatically with Attestation A when the calling number is owned by the project and the project's BTN (Behind-The-Number) registration is complete. No customer config — happens at the carrier layer.\n\nFor BYOC (Bring Your Own Carrier) setups where the customer pushes calls from third-party SIP infrastructure into SignalWire for delivery, attestation drops to B because SignalWire cannot independently authenticate the origin.\n\n## Common failure modes\n\n- **CNAM mismatch** — STIR/SHAKEN does not push caller name. CNAM is a separate database lookup at the terminating switch. Signed call ID is the number, not the name.\n- **Number not registered to BTN** — number was ported in but the new carrier did not register the BTN. Attestation drops to B until BTN sync completes.\n- **Spoofed call signed as A** — happens when the originating carrier authenticates the customer but does not validate ownership. The TRACED Act gives FCC power to revoke STI certs for repeat offenders.\n- **International call shows attestation C** — expected. The terminating carrier may still allow it but with a verification warning.\n\n## How to check attestation in production\n\nFor SignalWire-originated calls, the `Identity` header is added to the egress SIP INVITE automatically. To verify a specific call:\n\n1. Pull the call detail record (CDR) from the SignalWire portal.\n2. Inspect the `sip_identity` field in the CDR JSON.\n3. Decode the JWT — the `attest` claim is \"A\", \"B\", or \"C\".\n\nFor inbound calls (PSTN → SignalWire), the `Identity` header is preserved end-to-end. SWML scripts can read it via `%{call.sip_identity}` if you need to branch on verification status.\n\n## TRACED Act enforcement\n\n- FCC has revoked STI certificates from repeat-offending carriers (multiple actions since 2023).\n- Carriers that fail to verify inbound STIR/SHAKEN by 2023-06-30 are subject to FCC enforcement.\n- Robocall mitigation programs (RMP) filings are required for any carrier that lacks full STIR/SHAKEN deployment.\n\n## When to care as an application developer\n\n- **You must care** if your callers are reporting \"Spam Likely\" tags. Run a BTN verification with your provider.\n- **You must care** if you use BYOC and want Attestation A — work with your carrier on a delegate certificate arrangement.\n- **You probably don't need to care** for typical SignalWire-originated traffic where the calling number is owned by your project.\n\n## References\n\n- ATIS-1000074: STIR/SHAKEN technical standard\n- FCC Order: TRACED Act implementing rules (2020-03-31)\n- IETF RFC 8224: Authenticated Identity Management in SIP\n- IETF RFC 8225: PASSporT — Personal Assertion Token\n","html":"<h1>STIR/SHAKEN</h1>\n<p>STIR (Secure Telephony Identity Revisited) and SHAKEN (Signature-based Handling of Asserted information using toKENs) are the IETF and ATIS standards that authenticate caller ID on IP-based voice calls. Originating carriers sign the calling number with a private key; terminating carriers verify the signature. The FCC required compliance for all US carriers by 2021-06-30 under the TRACED Act of 2019.</p>\n<h2>How the signature flows</h2>\n<ol>\n<li>Originating carrier receives a SIP INVITE from a customer.</li>\n<li>Carrier evaluates how confident it is in the calling number's legitimacy.</li>\n<li>Carrier mints a JWT (the PASSporT) with claims for <code>orig</code>, <code>dest</code>, <code>iat</code>, and <code>attest</code>.</li>\n<li>The JWT is signed with the carrier's private key (issued by an STI-CA).</li>\n<li>The signed token is inserted in the SIP <code>Identity</code> header.</li>\n<li>Each transit and terminating carrier verifies the signature against the public cert.</li>\n</ol>\n<h2>Three attestation levels</h2>\n<p>| Level | Name | Meaning |\n|---|---|---|\n| <strong>A</strong> | Full attestation | Carrier authenticated the customer AND confirmed the customer is authorized to use the calling number |\n| <strong>B</strong> | Partial attestation | Carrier authenticated the customer but cannot confirm the customer owns the calling number |\n| <strong>C</strong> | Gateway attestation | Carrier received the call from an upstream gateway (often international) and cannot authenticate the origin |</p>\n<p>Voice service providers must reach attestation A on traffic they directly originate from verified customers. Wholesale and resale traffic typically lands at B. International gateway traffic lands at C.</p>\n<h2>What downstream carriers do with the result</h2>\n<p>| Verification result | Common terminating behavior |\n|---|---|\n| Verified A | Display name shown, no spam label |\n| Verified B | Display name shown, may add \"verified\" indicator |\n| Verified C | Pass-through, may add \"unverified\" tag |\n| Verification failed | Many carriers add \"Spam Likely\" or \"Scam Likely\" caller ID tag |\n| Missing Identity header | Some carriers block, most add a warning label |</p>\n<h2>SignalWire and STIR/SHAKEN</h2>\n<p>SignalWire signs outbound calls automatically with Attestation A when the calling number is owned by the project and the project's BTN (Behind-The-Number) registration is complete. No customer config — happens at the carrier layer.</p>\n<p>For BYOC (Bring Your Own Carrier) setups where the customer pushes calls from third-party SIP infrastructure into SignalWire for delivery, attestation drops to B because SignalWire cannot independently authenticate the origin.</p>\n<h2>Common failure modes</h2>\n<ul>\n<li><strong>CNAM mismatch</strong> — STIR/SHAKEN does not push caller name. CNAM is a separate database lookup at the terminating switch. Signed call ID is the number, not the name.</li>\n<li><strong>Number not registered to BTN</strong> — number was ported in but the new carrier did not register the BTN. Attestation drops to B until BTN sync completes.</li>\n<li><strong>Spoofed call signed as A</strong> — happens when the originating carrier authenticates the customer but does not validate ownership. The TRACED Act gives FCC power to revoke STI certs for repeat offenders.</li>\n<li><strong>International call shows attestation C</strong> — expected. The terminating carrier may still allow it but with a verification warning.</li>\n</ul>\n<h2>How to check attestation in production</h2>\n<p>For SignalWire-originated calls, the <code>Identity</code> header is added to the egress SIP INVITE automatically. To verify a specific call:</p>\n<ol>\n<li>Pull the call detail record (CDR) from the SignalWire portal.</li>\n<li>Inspect the <code>sip_identity</code> field in the CDR JSON.</li>\n<li>Decode the JWT — the <code>attest</code> claim is \"A\", \"B\", or \"C\".</li>\n</ol>\n<p>For inbound calls (PSTN → SignalWire), the <code>Identity</code> header is preserved end-to-end. SWML scripts can read it via <code>%{call.sip_identity}</code> if you need to branch on verification status.</p>\n<h2>TRACED Act enforcement</h2>\n<ul>\n<li>FCC has revoked STI certificates from repeat-offending carriers (multiple actions since 2023).</li>\n<li>Carriers that fail to verify inbound STIR/SHAKEN by 2023-06-30 are subject to FCC enforcement.</li>\n<li>Robocall mitigation programs (RMP) filings are required for any carrier that lacks full STIR/SHAKEN deployment.</li>\n</ul>\n<h2>When to care as an application developer</h2>\n<ul>\n<li><strong>You must care</strong> if your callers are reporting \"Spam Likely\" tags. Run a BTN verification with your provider.</li>\n<li><strong>You must care</strong> if you use BYOC and want Attestation A — work with your carrier on a delegate certificate arrangement.</li>\n<li><strong>You probably don't need to care</strong> for typical SignalWire-originated traffic where the calling number is owned by your project.</li>\n</ul>\n<h2>References</h2>\n<ul>\n<li>ATIS-1000074: STIR/SHAKEN technical standard</li>\n<li>FCC Order: TRACED Act implementing rules (2020-03-31)</li>\n<li>IETF RFC 8224: Authenticated Identity Management in SIP</li>\n<li>IETF RFC 8225: PASSporT — Personal Assertion Token</li>\n</ul>\n"}