What is STIR/SHAKEN and how does it impact robocalling?


David Preo


If you’re in the communications industry, you’ve likely heard the recent buzz about something called STIR/SHAKEN. What does it all mean and how will it impact your business? We’ll break that down for you in this FAQ. 

Industry leaders have been developing new specifications coined SHAKEN and STIR for Internet Protocol-based traffic exchange in recent years. STIR/SHAKEN is fundamentally aimed at re-establishing trust in the communications ecosystem and a stronger stance against malicious robocalling. The government is also keenly interested in protecting consumers against fraud and abuse in the form of robocalling.

Government interest was clearly demonstrated by the signing into law of the Telephone Robocall Abuse Criminal Enforcement and Deterrence (or TRACED) Act on December 30, 2019. Among a number of provisions in this law are requirements for the FCC to produce a report on the progress of STIR/SHAKEN deployment by the end of 2020, as well as a requirement for Service Providers to have implemented STIR/SHAKEN within 18 months of passage of the law. So, as you work with Bandwidth to advance your communications business needs, we want you to be aware of our stance on the issues and what we’re doing to implement the STIR/SHAKEN standards.

Bandwidth is actively engaged in efforts to implement the most robust call authentication framework possible, while also working diligently to stop the transmission of illegal robocalling on our network holistically. In addition to advancing the adoption of STIR/SHAKEN, Bandwidth is also leading industry efforts and best practices, including a three-pronged operational approach (prevent, detect, and mitigate) to stopping illegal robocalls. Learn more about Bandwidth’s stance against fraud and robocalls in our support article

While curbing illegal robocalling is a main objective of STIR/SHAKEN, the framework itself doesn't include a mandate to block robocalls. We'll explain what it does stipulate, and what that may mean for your business, in greater detail below.


SHAKEN (Secure Handling of Asserted information using toKENs) and STIR (Secure Telephone Identity Revisited) (or vice versa: STIR/SHAKEN) are Telecom industry standards designed to enable service providers to cryptographically sign calls in the SIP (Session Initiation Protocol) header. In simple terms, the STIR portion refers to the process of providing attestation that the call is legitimate, while the SHAKEN part is more about how to handle the calls one way or another. 

The process uses a trusted public key infrastructure to enhance the integrity of the originating call identifying data sent across networks. With STIR/SHAKEN, SIP headers will contain a level of confidence indicator from the originating service provider to signal whether the party originating the call has the right to use the number via the attestation field. There are 3 levels of attestation that can be indicated by the originating service provider:

  • Full Attestation - the service provider has authenticated their customer originating the call and they are authorized to use the calling number.
  • Partial Attestation - the service provider has authenticated their customer originating the call but can't verify they are authorized to use the calling number.
  • Gateway Attestation - the service provider has authenticated from where it received the call, but can't authenticate the call source (e.g., International Gateway call).

In addition to the attestation level, the originating service provider provides data in the header to facilitate traceback identifying where the call entered their network. 

What is the driving force behind STIR/SHAKEN adoption?

Fraud and abuse in the form of robocalling and, in particular, illegally spoofed robocalling, is the number one consumer complaint to the FCC. The industry is seeking to combat the abuse through the adoption of STIR/SHAKEN as one tool that will help. In an effort to combat the rising number of malicious and illegal spoofing, the TRACED Act was signed into law on December 30, 2019 that among other things mandates Service Providers deploy STIR/SHAKEN solutions.

It's worth noting that STIR/SHAKEN isn't a technology that blocks calls per se, but rather a tool that may provide indications of when fraud is occurring. In addition to working on implementing STIR/SHAKEN, Bandwidth also has policies to block unlawful robocalls and other forms of fraud.

It's important to distinguish between fraudulent and legitimate robocalls. Bandwidth continues to implore regulators and the industry to work hard to ensure that legitimate calls don't get blocked in the flurry of effort to prevent abuse. Services that consumers want and demand, such as school closure notifications or prescription reminders, must continue to meet their needs and expectations. While STIR/SHAKEN doesn't block calls, the data produced by the verification of signed calls could be input into the analytics used to block calls. 

What is the difference between STIR and SHAKEN?

STIR is a working group within the Internet Engineering Task Force (IETF), an open standards organization which develops and promotes Internet standards. As such, STIR produces internet standards that form the basis of what is referred to as STIR/SHAKEN. These include RFC 8224, RFC 8225 and RFC 8226, in addition to some draft standards currently being developed to address additional use cases beyond the scope of what is addressed by SHAKEN (ATIS 1000074). SHAKEN defines the extensions and industry framework for the deployment and interworking of the technology in service provider networks.

How does STIR/SHAKEN work in a call path?

When originating a call on the network, the originating service provider’s Secure Telephone Identity Authentication Service (STI-AS) creates an encrypted SIP identity header that includes the following data:

  • Attestation level
  • Date and Time
  • Calling and Called Numbers
  • Orig ID for analytics and/or traceback purposes among others
  • Location of certificate repository
  • Signature
  • Encryption algorithm

The SIP INVITE with the SIP Identity header is sent by the originating service provider and received by the terminating service provider. The terminating service provider invokes a STI Verification Service (STI-VS) to decode the SIP identity header and perform verification of the data transmitted in the call. Depending on the results of the verification, information can be passed in a verification status or verstat parameter indicating the results of the verification step. The call is completed to the receiving party with potentially some optional treatment like a display that is dependent on the level of attestation and the resulting verification. For example, this could be “valid number” or green checkbox for a fully attested call, or labeled as “possible spam” for a gateway attested call without full attestation. 

The following diagram shows the high-level call flow for SHAKEN calls:

  1. SIP INVITE is received by originating service provider who looks at call source (customer) and calling number to determine the level of attestation to provide for the call
  2. Originating service provider sends SIP INVITE to the authentication service
  3. Authentication service returns SIP INVITE with SIP Identity Header containing PASSporT header, PASSporT payload, PASSporT signature, encryption algorithm and location of certificate repository
  4. SIP INVITE with Identity header is sent to terminating service provider
  5. Terminating service provider sends SIP INVITE with Identity header to Verification Service
  6. Verification Service obtains the digital certificate with the public key, decodes the identity header and verifies that the originating service provider is authorized to originate calls for the calling number
  7. Verification Service returns results indicating whether the Identity Header was valid and whether TN Validation passed, failed or wasn't performed
  8. Terminating service provider completes the call to the called party

When will Bandwidth implement STIR/SHAKEN?

Bandwidth participates in the relevant industry forums (ATIS IP-NNI, NANC WG, etc.) and is actively implementing the STIR/SHAKEN specifications. We've successfully deployed the key components of STIR / SHAKEN in production and formally announced our initial carrier interop with Verizon Wireless in a December 11, 2019 press release. Our current SHAKEN implementation is as defined in ATIS 1000074. However, Bandwidth is on record with the FCC that SHAKEN as written isn't adequate for all uses cases. 

One example of an outstanding use case is when a customer purchases a telephone number from one provider but originates a call with a different provider. Bandwidth continues to participate in ATIS IP-NNI with other interested parties to ensure that proposals such as "Certificate Delegation" or "TN Proof of Possession" are adopted to ensure all legitimate customer calls are treated equitably.

Because of the existing gaps in current standards, Bandwidth expects to be implementing STIR/SHAKEN from our initial production deployment in the 4th quarter of 2019 well into 2020. Note that the new TRACED Act that was signed into law mandates that Service Providers have STIR / SHAKEN deployed by June 30, 2021. The text of the TRACED Act can be viewed here.

It's worth noting that STIR/SHAKEN validates that the telephone number (TN) of the call is valid. It also adds a mechanism for traceback of the call to the carrier that originated the call. It doesn't block calls. 

Are you currently in production with STIR/SHAKEN interop with peering partner?

Yes. Our initial carrier interoperability occurred in 4Q 2019 with a formal press release on Dec 11, 2019. We're also actively working with other Service Providers to expand our coverage and overall effectiveness of STIR/SHAKEN.

What can I do now to prepare for STIR/SHAKEN deployments?

As a customer, you can consult with your equipment vendor to understand its readiness for receiving additional SIP headers that will result from STIR/SHAKEN. While discussions are ongoing in the ATIS IP-NNI forum regarding what to pass the customer, the current best practice proposal suggests passing both the verstat parameter as well as the full identity header to the customer. Verstat is the header containing the verification results produced by the STI-VS, while the identity header is the header added by the originating service provider calling the STI-AS and includes such things as the attestation level and Orig ID.

As previously mentioned, on the origination side there are use cases that ATIS 1000074 as defined doesn't address directly, such as when a customer buys telephone numbers from multiple carriers and originates calls with different carriers. Bandwidth continues to advocate with the industry and the FCC that these use cases need to be addressed to ensure fair and non-discriminatory treatment of traffic. 

As a customer, you should stay abreast of these developments and, if possible, participate in the industry forums and make your opinions known. 

As a customer, will my network be expected to generate identity headers for traffic sent to Bandwidth?

Currently, no. For SHAKEN, as it’s defined today in ATIS-1000074, the originating carrier will generate the Identity Header via an STI Authentication Function (STI-AS). As mentioned, there are some use cases in which SHAKEN as written needs to be augmented to address. One example of this is when a customer’s equipment diverts a call (forward or transfer) which makes verification of the original Identity Header difficult or impossible. Another case is when a customer gets a number from one carrier and originates a call on a different carrier.

Both of these cases, among others, are being debated in the industry forums and may result in a customer needing to generate an Identity Header (or for Bandwidth or a third party to generate one on the customer’s behalf).

What is Bandwidth doing in relation to STIR/SHAKEN in the United States?

Bandwidth is actively engaged with the Federal Communications Commission (FCC), as well as with several STIR/SHAKEN working groups, to help shape and establish an industry solution for validating phone numbers and caller authenticity in an effort to reduce instances of robocalls and spoofing. We're working alongside other major service providers to develop and implement solutions that will best suit our customers’ wide variety of use cases. 

Bandwidth will be actively updating our customers on major changes as they take place. 

How will STIR/SHAKEN impact call forwarding use cases?

Call forwarding and otherwise “diverted” calls, such as call transfer, can result in the inability to verify the identity header added by the originating service provider because of the SIP header modifications that could occur. The ATIS IP-NNI forum is working on a standard specifically to handle these diversion cases, but it's still in draft status and being debated.

How will STIR/SHAKEN impact a call flow incorporating multiple carriers?

Authentication and signing of a call (STI-AS function) should be done by the originating service provider, and verification of a call (STI-VS function) should be done by the terminating service provider. The transit networks in between should pass the identity header without modification.

Article is closed for comments.