# STIR/SHAKEN for inbound calls STIR/SHAKEN enables a receiving network to verify a signed assertion about the caller and the calling number. For inbound SIP calls, DIDWW can relay the received SIP `Identity` header or validate it and add the result to the SIP `INVITE` delivered to your endpoint. STIR (Secure Telephone Identity Revisited) and SHAKEN (Signature-based Handling of Asserted information using toKENs) work together to address Caller ID spoofing, where a call presents a calling number the sender is not authorized to use. ## How STIR/SHAKEN works A signing provider attaches a cryptographically signed identity assertion, called a PASSporT, to the SIP `Identity` header. The assertion is encoded as a [JSON Web Token (JWT)](https://en.wikipedia.org/wiki/JSON_Web_Token) and contains the calling number, destination number, and attestation level. Intermediate networks can relay this header to the receiving provider. The receiving provider can validate the signature and compare the signed calling number with the Caller ID in the SIP signaling. The result can show whether the signed information changed while the call crossed other networks. Attestation reflects what the signing provider knew and could verify about the caller and calling number when the call originated. It does not guarantee that the call is legitimate, wanted, or free from spam labeling. See [P-Attestation-Indicator values](#inbound-sip-stir-attestation) for the three levels. ## Inbound handling DIDWW can relay the received `Identity` header, add identity and attestation headers, validate the received identity assertion and add the result, or combine supported behaviors. When DIDWW relays the `Identity` header, the customer is responsible for validating it. Configure the delivered information using **STIR SHAKEN Mode** under [Additional Services](../sip-trunk-settings-reference.html#inbound-sip-trunks-settings-additional-services) in the inbound SIP trunk settings. The default value is **Disabled**. See [STIR SHAKEN Mode values](../sip-trunk-settings-reference.html#inbound-sip-stir-shaken-values) for every selectable value and its behavior. Warning The `Identity` header contains private data. Relay of this header is disabled by default and requires account enablement. Contact [DIDWW Sales](mailto:sales%40didww.com) for more information. ## Delivered headers The headers delivered with a call depend on the selected **STIR SHAKEN Mode** and the information available in the received call. | Header | Description | | --- | --- | | `Identity` | Contains the signed identity assertion received from the call originator. When this header is relayed, the customer is responsible for validating it. | | `P-Asserted-Identity` | Identifies the calling party asserted for the SIP request. | | `P-Stir-Verstat` | Contains the DIDWW verification result for the received STIR/SHAKEN data. | | `P-Attestation-Indicator` | Contains the attestation level from a received `Identity` header with a valid signature. | | `P-Origination-ID` | Contains the STIR/SHAKEN `origid` value. This identifier can be used to trace a call across networks and locate related Call Detail Records (CDRs) in transit systems. | ### `P-Stir-Verstat` values | Value | Description | | --- | --- | | `TN-Validation-Passed` | Validation succeeded. The signature is valid, the certificate chain is trusted, and the calling number matches the SIP signaling. | | `TN-Validation-Failed` | Validation failed because the signature is invalid, the certificate is not trusted, or the calling number does not match the SIP signaling. | | `No-TN-Validation` | Validation could not be performed because the signature is missing or malformed. | ### `P-Attestation-Indicator` values The `P-Attestation-Indicator` header is added when DIDWW receives a valid `Identity` signature. | Value | Signer verified the caller | Signer verified the number | Meaning | | --- | --- | --- | --- | | `A` - Full attestation | Yes | Yes | The signing provider has a direct relationship with the caller and confirms that the caller is authorized to use the calling number. | | `B` - Partial attestation | Yes | No | The signing provider has a direct relationship with the caller but cannot confirm authorization to use the calling number. | | `C` - Gateway attestation | No | No | The signing provider knows where the call entered its network but cannot verify the caller or the calling number. | A lower attestation level does not by itself indicate fraud. A higher level does not guarantee call completion, display, answer rate, or exemption from spam labeling. ## SIP INVITE example The following SIP `INVITE` contains a successful validation result, full attestation, and an origination identifier: ``` INVITE sip:16031234567@example.com:5060 SIP/2.0 Via: SIP/2.0/UDP example.com:5060 From: "Example caller" ;tag=123456789 To: Call-ID: 1-12345@192.0.2.10 CSeq: 1 INVITE Max-Forwards: 70 P-Stir-Verstat: TN-Validation-Passed P-Attestation-Indicator: A P-Origination-ID: 59256b5e-9ab8-41be-9746-d7a797647603 ``` ## Limitations - The SIP `Identity` header can be lost or replaced if a call crosses a network segment that does not support STIR/SHAKEN. - Call forwarding, retargeting, number portability, and international interconnection can affect whether the signed identity reaches DIDWW. - STIR/SHAKEN does not authenticate an inbound SIP trunk or encrypt SIP signaling or media. See [SIP connectivity](../sip-connectivity.html) for inbound trunk authentication and encryption behavior. - STIR/SHAKEN is separate from Caller ID presentation, CNAM, and robocall reputation databases. See [CNAM IN for SIP trunks](cnam-in.html) for inbound caller-name delivery. Important Successful validation or header relay does not guarantee how another provider or application labels or displays a call. ## Regulatory context The U.S. Telephone Robocall Abuse Criminal Enforcement and Deterrence (TRACED) Act was signed into law in December 2019 and required U.S. voice service providers to implement STIR/SHAKEN. The implementation deadline was June 30, 2021 for large carriers and June 30, 2022 for smaller and rural carriers. ## Related standards **RFC 8224** Defines how SIP Identity tokens authenticate and verify calling numbers. **RFC 8225** Defines PASSporT tokens used to cryptographically verify calling numbers. **RFC 8226** Defines certificates that establish authority over telephone numbers. **RFC 7340** Describes problems caused by illegitimate Caller ID spoofing and unauthorized robocalling. ## Related resources - [SIP trunk settings reference](../sip-trunk-settings-reference.html) - Review all inbound SIP trunk fields and values. - [SIP connectivity](../sip-connectivity.html) - Understand how DIDWW delivers inbound calls to a SIP endpoint. - [CNAM IN for SIP trunks](cnam-in.html) - Understand how caller-name information is delivered on inbound calls. On this page