In June this year, 37% of calls signed with B-level attestation were robocalls, while only 7% of unsigned calls were robocalls. In other words, if you see a call that has been signed with a STIR/SHAKEN B-level attestation, that means it’s more likely to be a robocall.
That isn’t how things were supposed to work. STIR/SHAKEN was supposed to make things better.
Let’s review the vision for how STIR/SHAKEN was going to reduce the impact of robocalls:
- Ideally, all originating providers would sign calls with a SHAKEN certificate giving Attestation A, meaning “I authenticated the caller, and I know they’re permitted to use this number”.
- To cope with international origination, and to cope with TDM entry-points into the PSTN, the standards also allow for Attestation B (meaning, “I authenticated the caller, but I don’t know if this calling number is theirs”), and Attestation C (meaning, “I received this call from another provider, but I don’t know where it came from before that”).
- In general, the hope was that most legitimate calls would have Attestation A, and then if a robocaller managed to sneak a call onto the PSTN, the lack of certificate (or errors in the certificate) would indicate that this call was dubious.
- If a robocaller used a standard originating service provider, and the calls were signed, then it would be very easy to find the source of the calls and shut it down.
- In the short term, many small service providers are exempt from implementing STIR/SHAKEN if they instead implement a robocall mitigation program, and file their plan in the central Robocall Mitigation Database.
Unfortunately, things haven’t quite worked out like that. Based on recent data from TransNexus (who provide monthly updates on SHAKEN stats on their blog), there are some holes in this vision.
- Some intermediate service providers (e.g. Inteliquent – among others) are selling long distance SIP trunks to ILECs, where they offer to add SHAKEN certificates to the calls as part of the service (with Attestation B/C).
- Service providers who sign up for this offering often feel that they have now complied with the FCC requirements to “implement STIR/SHAKEN”, and as a result they don’t implement a robocall mitigation program. This creates the possibility for a robocaller to find an easy way onto the network (although I’m not convinced this is actually happening at scale with rural ILECs).
- However, it’s clearly the case that many robocallers are signing up directly with intermediate service providers, using them to originate large volumes of robocalls, and hoping that the presence of a SHAKEN certificate on the call will help the calls to be completed.
How do we make things better?
As individuals we have limited ability to influence the situation, but as an industry, there are three key ways we could work to improve the effectiveness of STIR/SHAKEN in reducing robocalls.
- Better robocall mitigation: Every originating service provider should be implementing an effective robocall mitigation plan, regardless of whether STIR/SHAKEN has been implemented for their calls.
- Better traceback: There’s an industry group that is responsible for going after the source of illegal robocalls, and there’s clearly more that we can do here. A group of US Senators recently wrote to the FCC asking for more transparency in traceback efforts, and clearly there needs to be pressure put on the intermediate service providers to do a better job of policing the entry of robocalls into their networks.
- Wider STIR/SHAKEN implementation: This is the tough one. The hybrid TDM/VoIP nature of the PSTN infrastructure limits the impact of STIR/SHAKEN, and while ATIS has released some standards that allow STIR/SHAKEN to be at least partly implemented over TDM, today the vast majority of calls are still unsigned.
Remember: if you used the small service provider exemption to delay implementation of STIR/SHAKEN, the deadline for implementation is June 30, 2023 – so you still have a little while, and very likely the guidance (as it relates to TDM) will have evolved by then.
