“Whenever we call an AT&T wireless number, our call is marked as spam!”
And so it begins.
I spoke to a client today who relayed these words from one of his subscribers. My client has not yet implemented STIR/SHAKEN, but AT&T has – and so calls from this ILEC (and many others) are considered less trustworthy on AT&T’s network than traffic from the Tier 1 carriers.
Small carriers are at a disadvantage
This should come as no surprise.
- In February last year I first expressed concern that independent telcos would become second-class citizens of the PSTN because they were forced to use TDM interconnect to their tandems.
- A couple of months ago the NTCA sent a letter to the FCC about this “reverse rural call completion problem” and asking that SIP interconnect be made available to all service providers.
The core problem is that STIR/SHAKEN (which validates the calling number, a key step in identifying and blocking robocalls) only works for calls that traverse the PSTN entirely over SIP.
STIR/SHAKEN works how?
The originating service provider is supposed to attach a new SIP identity header to the call attesting to the world that this caller ID is valid. This is the telecoms equivalent of the politician saying “I am Josiah Bartlet and I approve this message”.
That SIP header must then traverse the entire PSTN, and be delivered over SIP to the terminating service provider, who can then validate the header and the certificate, and potentially inform the called party that this call is trustworthy.
This is the technology that has been enshrined into law in the Pallone-Thune TRACED Act – which requires STIR/SHAKEN for all VoIP calls by June 30, 2021.
In-band STIR doesn’t work if…
- The originator sends the call out over SS7.
- The terminating service provider receives the call over SS7.
- Any intermediate carrier in the call path uses SS7.
- An intermediate SIP device drops this unrecognized header from the INVITE message.
- An intermediate SIP device can’t process the SIP message because it’s unusually large.
And all that’s assuming that all US service providers have successfully implemented STIR/SHAKEN.
Now I’m not saying it’ll never work – if you implement STIR/SHAKEN and send the call out over SIP trunks and the destination is a cell phone from one of the Tier 1 wireless providers, you’re probably fine.
But a significant portion of PSTN traffic is going to run into some kind of issue.
Out-of-Band STIR to the rescue?
Out-of-band STIR is a draft IETF standard that uses the same authentication and verification methodology of in-band STIR/SHAKEN, but rather than sending the data as a SIP header in the INVITE, the identity tokens can instead be stored in a centralized database.
The terminating service provider can then perform a lookup in that central database for any received calls, and retrieve the identity tokens (and verify them) if they’re present. This removes all requirements on the intermediate transport – it could be end-to-end TDM and out-of-band STIR could still verify the call.
Does it really work?
Yes. TransNexus have taken the lead here and implemented out-of-band STIR in their STIR/SHAKEN solution, and they recently gave a webinar to NTCA members where they demonstrated it working.
And they’re not alone. I’ve also seen comments from Neustar about the benefits of out-of-band STIR which suggests they may be working on an implementation too.
Of course, we would ultimately need this to be adopted industry wide – with agreement on who is running the central database of identity tokens, and so on. But since we already have an assigned Policy Administrator and Certificate Authorities for STIR/SHAKEN, it seems plausible that these issues could be figured out.
Certainly widespread adoption of out-of-band STIR seems more likely than replacing all ISUP trunks with SIP in the next 15 months.
What should I do about STIR/SHAKEN?
This is a complicated topic, so we’d like to help make this as easy as possible.
This is one of those situations where every telco is going to have to go through this process, so rather than all of you learning all about it just to implement it once, it makes much more sense for us to become experts and perform the same integration work over-and-over again – so we can learn the gotchas and make the process as smooth as possible.
If you’re on our email list you’ll know that we will soon be launching a service to do exactly that – where we’ll handle the configuration to implement STIR/SHAKEN in your network. We have already done some testing with TransNexus and will also support integration with the Metaswitch/TNS Call Guardian Authentication Hub.
We currently have a wait-list of service providers who are interested in this service – and have begun work on the first implementation project. If you’d like to be added to that wait list, please complete our contact form – and you’ll be the first to know when we officially launch.
I can’t resist finishing another STIR/SHAKEN article without sharing the trailer to the 25th James Bond movie “No Time to Die”. It looks amazing.
