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

Compliance

Plan of actions


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.
  • every lookup to Authentication server is counted against the stir-shaken plan on 1CallConnect side


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 ISP Telecom so that it can send back the signed Identity for the CLI/CLD pair in a 302 response within mandatory Identity header. If no valid Identity header is received, such routing entry would be skipped from this call attempt, in case it's the last Routing Entry, 500 No Routes For the Call error can be returned.

  • 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
  • every lookup to Authentication server might be counted against the stir-shaken plan on ISP Telecom side


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
  • every lookup to Verification server might be counted against the stir-shaken plan on ISP Telecom side


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. Authentication lookups and Identity generation are performed locally and are free of charge.


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.


Verification lookups are performed locally except of certificate fetch from x5u URL and are free of charge.


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


> Please let know how Sippy decides for which call needs to be enabled AS and for which VS.
1. Any incoming call with Identity and Date will be sent to the VS service to verify if signature is correct. If no Identity was received, the Verification is still performed, then based on Verification mode the call could be dropped (in case it's set to Strict)
2. Any outgoing call before termination will be sent to the AS to receive the signature (Identity), and then sent to the INVITE vendor with the signature, if the AS provided it.

> Does Sippy can do AS by itself, using a private key?
Starting from Sippy2021 it's possible to use your own certificate, key and other parameters to perform either call signing or verification. The web UI for self-management is available starting from Sippy2023, earlier versions can have it configured using xmlapi