STIR/SHAKEN and CLI Spoofing Mitigation

STIR/SHAKEN is a framework of interconnected standards. STIR/SHAKEN are acronyms for the Secure Telephone Identity Revisited (STIR) and Signature-based Handling of Asserted Information Using toKENs (SHAKEN) standards. This means that calls traveling through interconnected phone networks would have their caller ID “signed” as legitimate by originating carriers and validated by other carriers before reaching consumers. STIR/SHAKEN digitally validates the handoff of phone calls passing through the complex web of networks, allowing the phone company of the consumer receiving the call to verify that a call is in fact from the number displayed on Caller ID.

There are some crucial dates in the calendar coming up very soon for any service provider putting traffic into the US PSTN, some better known than others.

  • 6 May 2021 – “affirmative obligations” on all voice service providers concerning robocalling
  • 30 June 2021 – implementation of STIR/SHAKEN and/or robocall mitigation, and filing in the FCC’s database
  • 28 September 2021 – obligation not to accept traffic from any service provider not in the database
  • 1 January 2022 – implementation of specific SIP and ISUP response codes when blocking calls

The BASE STIR/SHAKEN Standard is targeted at internet IP-based service providers. The non-IP providers with traditional TDM basic infrastructure are not able to implement it as you need to have a SIP infrastructure (Session Initiation Protocol).

Problems increase if there are multiple vendors and different parties involved in the call path. Some of those parties might not able to support STIR/SHAKEN and the call attestation is lost.

With our distributed CLI Integrity Attestation (CIA) we close that gap. The originating carrier records a Call Information Attestation (CIA), cryptographically secured, on the blockchain.

The terminating carrier is now able to check and verify this this attestation before terminating the call.

As the vendors and different parties involved in the call path are not involved thus the attestation cannot get lost.

We are aware that speed and low latency is essential and offer many different fast low level API’s.

For testing purposes we included web services APIs in our Antifraud Namespace:

It is also possible to use our CodeB CommandLine Interface. More HERE.

Note: Web Services testing API’s are much slower than the low level production API’s! Contact us in case you are interested in testing the production APIs.


The FastRecordCall should be called at the originating end and the function has 4 parameters:

ANumber: This is the origin number.

BNumber: This is the termination number.

StartDateTimeUTC: The start date/time of the call in d/M/yyyy HH:mm:ss format (UTC). The current date/time can be always retrieved in the right format with the helper function: DateTimeUTCNOW. If left empty the current node time is used!

Note: We are aware that times might not match exactly between origin and termination. We cater for that with our unique fuzzy hash algorithm.

AgreementCode: For extra privacy carrier can agree on extra values for this field. Could be also a salt or any other details of the CDR. If left empty the internal identity system takes care of it.


FastCheckCall has exactly the same parameter as the function RecordCall. It returns the values true or false indicating if that call ever has been terminated or not.

Note: We are aware that times might not match exactly between origin and termination. We cater for that with our unique fuzzy hash algorithm. You might try it out with small time variation.

Please note that any Call Information is not stored permanently! Everything is pruned after some time!