# STIR/SHAKEN for outbound trunks STIR/SHAKEN allows terminating providers to verify the originating provider's signed assertion about the caller and calling number. DIDWW signs outbound calls by default and can instead relay a SIP `Identity` header that your system has already signed. ## Purpose of STIR/SHAKEN 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. A signing provider attaches a cryptographically signed identity assertion, called a PASSporT, to the SIP `Identity` header of an outbound call. Intermediate networks are expected to relay this header. A terminating provider verifies the signature and can show the result to the called party or use it in call-labeling and analytics systems. Attestation reflects what the signing provider knew and could verify about the caller and the calling number at the moment the call originated. It is not a guarantee that the call is legitimate, wanted, or free from spam labeling downstream. STIR/SHAKEN also does not authenticate your SIP trunk and does not encrypt signaling or media. Both of those are handled separately, as described in [Authentication and security](authentication-security.html). ## Supported modes DIDWW supports two outbound modes: signing calls itself by default, or relaying a SIP `Identity` header that you have already signed. | Mode | Signing party | Identity header behavior | Customer action | | --- | --- | --- | --- | | Default DIDWW attestation | DIDWW | Any customer-provided header is not preserved | None | | Customer Identity header relay | Customer | Relayed unchanged | Request activation, generate a valid header | ### Default DIDWW attestation By default, DIDWW applies STIR/SHAKEN attestation to outbound calls sent through an outbound trunk: - DIDWW generates the signed identity assertion for the call. Any SIP `Identity` header received from the customer is not preserved. - The attestation level is assigned according to DIDWW policy and applicable regulatory requirements. No additional configuration or action is required from the customer. ### Customer Identity header relay If you sign your own outbound calls, DIDWW can relay your SIP `Identity` header unchanged instead of generating its own: - You are responsible for generating and providing a valid SIP `Identity` header. - DIDWW does not generate or modify the SIP `Identity` header in this mode. - The original SIP `Identity` header you provide is relayed unchanged. To enable `Identity` header relay for your outbound trunks, contact [DIDWW Sales](mailto:sales%40didww.com) or [DIDWW Customer Care](mailto:customer.care%40didww.com) with a request to relay your identity header for outbound calls. Note - This configuration is applied per trunk. We recommend using a separate trunk for customer-signed traffic. - Activation is subject to technical and compliance review. ## Attestation STIR/SHAKEN defines three attestation levels. Each describes what the signing provider could verify about the call at origination, not the likelihood that the call is legitimate: | Level | Signer verified the caller | Signer verified the number | Typical meaning | | --- | --- | --- | --- | | A - Full attestation | Yes | Yes | The signing provider has a direct relationship with the caller and confirms 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 only where the call entered its network, such as an international gateway, and cannot verify the caller or the number. | A lower attestation level does not by itself indicate fraud, and a higher level does not guarantee call completion, display, answer rate, or exemption from spam-likely labeling. DIDWW determines the attestation level used in the default mode according to its policy and applicable regulatory requirements. If you use Identity header relay, you are responsible for asserting only an attestation level you are authorized to use. ## Limitations - Downstream verification and any caller-verification indicator shown to the called party depend on the terminating carrier and the receiving device or application, not on DIDWW. - The SIP `Identity` header can be lost or replaced if a call transits a network segment that does not support STIR/SHAKEN. - Call forwarding, retargeting, number portability, and international interconnection can all affect whether a signed identity survives to the terminating network. - STIR/SHAKEN is separate from Caller ID presentation, CNAM OUT, and robocall reputation databases, described in [Caller ID and CNAM OUT](caller-id-cnam-out.html) and the [Robocall mitigation and call labeling](robocall-mitigation/index.html) section. Important Successful signing or relay does not guarantee how a downstream provider labels or displays the call. ## Related standards **RFC 8224** Defines how SIP Identity tokens are used to authenticate and verify calling numbers. **RFC 8225** Explains how to create and validate cryptographic tokens for Caller ID verification. **RFC 8226** Covers the use of certificates to establish authority over telephone numbers. **RFC 7340** Outlines challenges leading to unauthorized robocalling and Caller ID spoofing. ## Related resources - [Caller ID and CNAM OUT](caller-id-cnam-out.html) - Configure Caller ID formatting and CNAM behavior. - [Authentication and security](authentication-security.html) - Understand trunk authentication and encryption, which are separate from signed caller identity. - [Outbound SIP information](outbound-sip-information.html) - Find SIP endpoints, transports, and protocol parameters. - [Routing and dialing](routing-dialing/index.html) - Configure destination dialing and review call flow examples. - [Robocall mitigation and call labeling](robocall-mitigation/index.html) - Review robocall compliance and call-labeling topics. On this page