STIR/SHAKEN, or SHAKEN/STIR, is a suite of protocols and procedures intended to combat caller ID spoofing on public telephone networks. Caller ID spoofing is used by robocallers to mask their identity or to make it appear the call is from a legitimate source, often a nearby phone number with the same area code and exchange, or from well-known agencies like the Internal Revenue Service or Ontario Provincial Police. This sort of spoofing is common for calls originating from voice-over-IP (VoIP) systems, which can be located anywhere in the world. © Wikipedia
In Sippy 2020, we introduced STIR/SHAKEN functionality through our partner, 1 Call Connect, calls can be signed with proper Identity generated before sending to termination. If you require this service, you can subscribe here: 1 Call Connect STIR/SHAKEN Request Form
Stir/Shaken Authentication setup
For 2021 and 2022 versions it's possible to either choose Authentication provider 1CallConnect or disable Stir/Shaken authentication for the whole environment on a web page located under System Management - System Parameters - STIR/SHAKEN
Starting from Sippy 2023 the UI now supports different connectors for both Authentication and Verification on System Management - SIP Features - Stir/Shaken
Authentication and Verification connectors
1CallConnect Authentication Connector
Before sending an outgoing INVITE the b2bua sends a special INVITE message to 1CallConnect authentication server. 1CallConnect server sends a response with code 302 and a signature for the call within X-Identity header along with X-Date header that contains current timestamp. The b2bua collects that signature and puts it in Identity header along with Date header into the outgoing INVITE which goes to vendor connection or trunk or registered UA.
Sippy only supports format of incoming X-Date header as specified in RFC3261, e.g.:
X-Date: Sat, 13 Nov 2010 23:29:00 GMT
- Requests are sent to 5060 port only of 1CallConnect Authentication server, no port should be specified in SIP Host
- requests are sent from b2bua's port, not OpenSIPS
- requests are sent with random call-id generated on our side
- 1callconnect/sip_hosts would be tried within 10 seconds.
Parameters:
- SIP Host - the hostname or IP address of 1CallConnect Authentication server to be used with Stir-Shaken. Provided by 1CallConnect team
- UUID - unique UUID identified of the client. Provided by 1CallConnect team
ISP Telecom Authentication and Verification Connectors
Authentication connector:
Once configured before sending the calls to vendor connections the special INVITE might be sent to the signing server of 1callconnect so that it can send back the signed Identity for the CLI/CLD pair in a 302 response within Identity header.
- custom port could be specified after host name/IP, separated with colon
- requests are sent from b2bua’s port, not opensips
- requests are sent with random call-id generated on our side
- isp_telecom/host would be tried within 6 seconds
- even if there are no numeric symbols (digits) in CLI or CLD (From and To header correspondingly) - authentication request would still be sent
Parameters:
- Host - the hostname or IP address of ISP Telecom Authentication server to be used with Stir-Shaken. Provided by ISP Telecom team
Verification connector:
Once configured before sending the calls to the routing the special INVITE would be sent to the verification server of ISP Telecom with Identity header received from the Caller expecting to get 302 response with either From or P-Asserted-Identity(fallback) header that has verstat parameter with result of verification, e.g.:
From: 12345678901<sip:12345678901;verstat=TN-Validation-Passed@our-test-system:5062> P-Asserted-Identity: 12345678901<sip:12345678901;verstat=TN-Validation-Passed@our-test-system:5062>
Depending on verification mode the call with unsuccessful verification would be either processed or dropped. No response/invalid response from VS equals verification failure.
Parameters:
- Mode - Relaxed (no matter what was result of verification, call still comes through) or Strict (for unsuccessful verification call is dropped with 438 error code)
- Host - the hostname or IP address of ISP Telecom Authentication server to be used with Stir-Shaken. Provided by ISP Telecom team
Local DB Authentication and Verification Connectors
Authentication connector:
This configuration works based on Stir-Shaken Certificate and Key added to the SSL Certificates, the b2bua signs every outgoing INVITE using the the private key and certificate supplied and puts the configured x5u, origid and attest values into the resulting signature as part of Identity header. Date header is also included into outgoing INVITE with the valid timestamp.
Both CLI and CLD are used to generate the signature, and both should contain at least some numeric symbols, as non-numeric ones are excluded.
Parameters:
- Certificate - stir-shaken SSL certificate and key created under SSL Certificates.
- X5U URL - the URL to stir-shaken SSL certificate. This URL is encoded into signature placed within Identity header and is used to fetch the SSL certificate by verification side.
- Origid - unique UUID value which is encoded into signature placed within Identity header and provides the identification for the side that generated Identity.
- Attestation - the level of attestation of call signer. Available options are A (Full Attestation), B(Partial Attestation), and C(Gateway Attestation)
Verification connector:
This configuration works based on Stir-Shaken root certificate added to CA Lists - this certificate is used to verify the signature received in the Identity header of INVITE within the incoming call.
Note, no Tr. Rules are applied for neither CLI nor CLD before sending request for verification, only incoming CLI/CLD are used. Sippy only supports format of incoming Date header as specified in RFC3261, e.g.:
Date: Sat, 13 Nov 2010 23:29:00 GMT
When a new call arrives the b2bua takes signature from the Identity: SIP header and also date and time when the call has been signed from the Date: header. b2bua unpacks received signature, takes the x5u URL from it and attempts to fetch (download) the certificate of the caller from the specified WWW URL. b2bua verifies if the downloaded certificate is not expired and is actually signed by a CA from the chain of root certificates, the signature is checked using the downloaded certificate, on this stage both CLI and CLD should contain at least some numeric symbols, as non-numeric ones are excluded, if one has no numeric symbols [0-9] - the CLI/CLD would be considered as empty.
Parameters:
- Mode - Relaxed (no matter what was result of verification, call still comes through) or Strict (for unsuccessful verification call is dropped with 438 error code)
- CA List - stir-shaken root certificate created under CA Lists
Extended setup
As of >=2023 version the ability to manage Stir/Shaken settings within the Routing Group would be available.
It's possible to disable signing of the calls/requests to AS for any Routing Entry by unsetting Stir/Shaken Enabled checkbox, also for specific Routing Entry it's possible to set one of the following Stir/Shaken policies:
- Required
- Supported (default one for existing and new records)
- Disabled
S/S policy | Should AS be queried if no Identity cached? | Send INVITE to Vendor with cached Identity? | Send INVITE to Vendor with no Identity (no cached Identity present)? |
Disabled | no | no | yes |
Supported | no | yes | yes |
Required | yes | yes | no |
Long term Outlook (Sippy 2021 and beyond)
In future versions of our software we will also be adding a few more ways for both signing for calls as well as verification. We'll be looking at adding functionality to be able to sign or verify calls locally on your softswitch. We have also received requests for other devices to work on other integrations for other third party signing and verification services. We will be adding additional services where we can.
FAQ