200 OK STIR/SHAKEN: How investigators can tell if you're compliant

For many service providers offering service in the United States, June 30, 2023 has been a looming deadline. It's the date at which every Voice service provider in the USA is required fully implement the STIR/SHAKEN framework. But many providers are stopping short of full implementation -- and running a risk of an enforcement investigation from the FCC.

For Voice engineering teams, the most visible part of STIR/SHAKEN is the Identity. It's a value sent to other companies when the phone call is setup, as a SIP header. But behind sending Identity are many other decisions...

  • What level of attestation should we be using? 
  • Do we know if our customers have the right to use the phone numbers they're using?
  • In what parts of our network do we have to implement STIR/SHAKEN? (Meaning: do we have to have Identity headers everywhere)?
  • What do we have to do to "fully implement" STIR/SHAKEN?
  • What do I do with the data I gain from verifying the Identity header PASSporT values?
  • Could the FCC determine if I'm verifying inbound calls?

This article is written for Voice Service Providers to discuss these questions and help you see if you're fully compliant.

What level of attestation should we be using? A, B, or C?

In the Identity header, there's an encoded value called a PASSporT. The PASSporT was created for a single phone call, and inside it has a single attestation value: A, B, or C. I paraphrase the attestation levels for a Service Provider like this.

  • A: I know who the caller is as a legal person/corporation, and I know they have the right to call from this telephone number.
  • B: I know who the caller is as a legal person/corporation, but I don't know if they have the right to call from this telephone number.
  • C: I don't know who the caller is, but I know where the call came into my network. But that entry point wasn't from the caller.

Do we know if our customers have the right to use the phone numbers they're using?

This question gets to the "Know Your Customer" (KYC) problem. What do you know about your customers, and how do you go about learning it? You can watch many presentations on this topic at SIP Forum's June 2023 KYC Summit. The problem space varies widely among service providers.


  • SIMPLEST: Customers only use telephone numbers that you assign to them. They cannot modify their telephone numbers used for outbound calls. You know you have the right to use the telephone numbers because they were assigned to you from a governing authority. If a customer tries to send a call from another telephone number, you block their call (except when it's going to 911, because you never block that.)
  • HARDEST: Your customers place calls to you from any telephone number they choose. In fact, your customers may actually be routing calls that they received from another location (such as with Call forwarding, or informal Service Providers)


In the "simplest" case, you can typically be happy to choose the "A" attestation level. Happily, that aligns well with the wording of the federal TRACED law, which desires Service Providers to provide the strongest level of proof of the identity of their callers.

If you have customers in the "hardest" category, then choosing the attestation level can be quite hard! You may need technology to determine which calls they're placing from numbers assigned directly to them to choose the "A" attestation level. There is no universal registry of telephone numbers, nor is there a standard way of proving ownership of a telephone number. Combine this with other obligations that service providers must take affirmative steps to prevent their customers from placing illegal calls of any kind, and the administrative workload for service providers has increased substantially. A customer with a SIP trunk allowing them to call from any telephone number should expect to pay more than a SIP trunk that uses "number screening" to limit the telephone numbers they can use.

In what parts of our network do we have to implement STIR/SHAKEN? (Meaning: do we have to have Identity headers everywhere)?

Service Providers have to implement STIR/SHAKEN in all of the SIP portions of their network, but that doesn't necessarily mean they have to add Identity headers throughout. 

If you have a simple network, the "User-Network Interface" may simply be used for device management and authentication (i.e., SIP REGISTER, 401, REGISTER with Authorization, then 200). That authentication itself allows you to satisfy some of the STIR/SHAKEN requirements by clarifying precisely which legal person/corporation your system is communicating with. If you have a set of SBCs, and few synchronized calling servers (like BroadSoft/BroadWorks Application Servers linked with a single Network Server, or a single Metaswitch MaX platform, or a single Crexendo/NetSapiens cluster), then it's likely all the context about the identity of the caller is kept in one place. That simplifies the process of tracking the identity of the caller.

If you have a larger network or a more distributed architecture, a call may enter your network on one entry point and be routed several times before ultimate termination. In this case, you may need to track context, like "Where did the call enter our network?" and "Do we trust the caller's right to place a call from this telephone number?". For those purposes, tagging headers like those described by Metaswitch's Austin Spreadbury can be useful.

What do we have to do to "fully implement" STIR/SHAKEN?

Everyone quickly becomes aware of the need to send SIP INVITE's with the Identity header. But the FCC is strict about the need to analyze incoming Identity headers. One major US service provider was put in the penalty box for failing to verify all calls entering its network.

In a 2022 Order, the FCC penalized Vonage because it wasn't verifying all the Identity headers it received.

Vonage claims that it “completed all necessary network upgrades to its network infrastructure to be able to authenticate and verify caller ID information for calls exchanged with STIR/SHAKEN-enabled partners by June 30, 2021.” However, Vonage also explains that only “50% of inbound SIP calls [are] being validated as of today,” and that it is “coordinating with . . . partners and expects to expeditiously re-enable inbound processing of STIR/SHAKEN identification headers.” We [the FCC] find that this gap in Vonage’s use of STIR/SHAKEN falls short of the Commission’s requirement that a provider have “fully implemented the STIR/SHAKEN authentication framework” to maintain the exemption in section 64.6306(e). We conclude that this section must be read in light of section 64.6301(a), which defines the requirements for a voice service provider to “fully implement the STIR/SHAKEN authentication framework” in the first instance. In section 64.6301(a), the Commission requires a voice service provider to, among other things “verify caller identification information for all SIP calls it receives from another voice service provider . . . which it will terminate and for which the caller identification information has been authenticated.

This order is striking because it shows the FCC expects verification of the incoming Identity headers to be performed, even though there are no defined outputs of the verification. That is, as a service provider, you don't have to do anything with the data you gather in the verification. You're simply required to do the verification.

The verification process requires a few key steps:


  1. Pass the PASSporT to a system that can decode it
  2. Decode it
  3. Retrieve the certificate used to sign it
  4. Confirm the digital signature on the PASSporT
  5. Compare the calling party, called party, and timestamp information to judge the validity of the PASSporT


What does a Service Provider with the data it gains from verifying the Identity header PASSporT value?

A service provider can use the data as part of a program of blocking inbound nuisance calls. If a service provider does so, and uses that to block calls, then there are obligations for logging that data and providing for remediation. (I.e., callers have to be able to contact the blocking service provider.) In addition, certain SIP response codes must be used -- 603, 607, or 608 -- when blocking like this is done.

Can the FCC determine if I'm verifying inbound calls?

Yes! The FCC can easily determine if you are verifying inbound calls. While the outbound SIP INVITEs go into the PSTN and potentially could be available to any service provider through which our calls route, some service providers don't think about the fact that Verification triggers detectable activity across the Internet. 

Stay One Step Ahead

Nobody I know wants to be on the side of the illegal robocallers. Don't put yourself in the position to be caught by the FCC for non-compliance. When you're implementing STIR/SHAKEN, do a thorough job, both carefully "Knowing your Customer," sending proper attestations, and verifying inbound calls.

We'd love to chat about your STIR/SHAKEN implementation and help you confirm it's fuily compliant. Contact our team for a chat today at sales@ecg.co.

Related to SHAKEN/STIR


Protect Your Customers from Spam Callers: Technology Provider Panel

Technology options to protect your customers against scam calls, boost your revenue, and protect your business. Nuisance robocalls to your customers are a menace to Voice Service Providers -- but did you know you can stop those calls from reaching your customers?  Hear from a panel of the leading technology companies with options to protect your customers against inbound robocalls. Whether you offer SIP trunking, UCaaS Hosted PBX, or have an enterprise network, you can effectively manage & block inbound nuisance calls. Out of the top 23 UCaaS / Hosted PBX vendors identified by Gartner, only four can protect their customers against inbound robocalls. Only four!  This is a great opportunity for UCaaS vendors to differentiate their services based on the quality of inbound protection, along with the ability to report on blocked calls and to ensure that all desirable calls.  This change brings new revenue possibilities, including up to 15% revenue increase per user at one US UCaaS leader. Every vendor provides unique solutions. ECG can integrate with any robocalling mitigation vendor into your existing network. Relationship between Robocall Mitigation, SHAKEN/STIR, and Spam Calling Market Opportunity for UCaaS and SIP Trunking Revenue Generation Examples -- looking at what's in the market today Key questions raised by spam call blocking: A New Spam Mailbox? Emergency 911 callback? Rural Call Completion? "Reasonable Analytics"   Panelists: Rich Quattrocchi is Vice President of Digital Transformation at Mutare. He holds six patents and is working his seventh for work at Mutare. Bart Pesavento is the Director of Product Marketing at Neustar and is responsible for driving the go-to-market strategy for Neustar’s Trusted Call Solutions and Order Management portfolios. Ray Muscatell is Vice President of Worldwide Sales, and leads the sales teams and is responsible for sales for RedShift Networks UCTM product portfolio. Alec Fenichel is a software engineer, and leads the design and operations of TransNexus’s cloud based service platform, ClearIP. Greg Blumstein is the founder of TrueCNAM and the TrueSpam service. Gerry Christensen is responsible for leading new business development and strategic relationships at YouMail.

More about SHAKEN/STIR