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.
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:
- Pass the PASSporT to a system that can decode it
- Decode it
- Retrieve the certificate used to sign it
- Confirm the digital signature on the PASSporT
- 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.