A few weeks ago Metaswitch announced a new partnership with TNS to offer a new robocalling blocking service based on STIR/SHAKEN.
Which seemed odd to me, because Metaswitch already have a robocalling blocking service and a separate STIR/SHAKEN product… so how is this a new thing?
I like a good mystery, so I’ve been doing some investigating on your behalf, and it turns out this is a pretty interesting announcement after all.
Now people have been complaining about robocalls for many years, but things have really been hotting up recently, with some aggressive statements from the FCC and even a bill in Congress that would mandate STIR/SHAKEN and require telcos to offer robocall blocking to subscribers free of charge.
While the technology has been gradually becoming available over the past few years, there’s a renewed push now on deploying quickly, and that’s the focus of this new partnership between Metaswitch and TNS.
So… what exactly does the partnership involve?
- Metaswitch have a product named QCall that handles STIR/SHAKEN verification. This has been available for a year or so but service providers had to purchase the software, commission it, and host it in their local virtual environment. Whereas through this partnership TNS are deploying QCall and making it available in the cloud for telcos to access – making it significantly easier for a service provider to use STIR/SHAKEN on their SIP calls.
- TNS meanwhile, are bringing their Call Guardian service to the table. This is a cloud-based robocall blocking application – you send your calls (post STIR/SHAKEN verification) to Call Guardian and it will assess whether the call should be blocked as a likely robocall.
From a service provider’s point of view, this means that STIR/SHAKEN and Robocall Blocking are combined through this single offering – where both products are hosted in the cloud and can (relatively) easily be deployed. To quote the press release, this solution “enables carriers to quickly and economically go-to-market with a call authentication solution that meets FCC Chairman Ajit Pai’s call-to-action to adopt protocols that combat illegal spoofing and better protect subscribers from unwanted robocalls.”
Technical Sidebar: how does it work?
First a quick reminder:
- STIR/SHAKEN is a framework that allows SIP calls to be signed with a certificate at source (validating who created the call, and that the caller ID is valid), and then that same certificate is verified when the call arrives at its destination – thereby proving that the stated caller ID is real, not spoofed.
- Robocall Blocking platforms typically have access to data from a large number of calls, and use that data to spot patterns and identify likely robocalls.
The new integration between Metaswitch and TNS occurs in two places.
- Perimeta is configured with a connection to the TNS-hosted QCall servers, which is used on outbound calls to add the STIR/SHAKEN headers to the SIP INVITEs, and on inbound calls to verify the headers found there. Note that QCall doesn’t block any calls – it simply analyzes the STIR/SHAKEN information and updates the SIP request to record the results of that verification.
- For inbound calls, the Metaswitch CFS receives the SIP INVITE from Perimeta, with the STIR/SHAKEN verification already complete, and then routes the call over to the TNS Call Guardian service. Call Guardian will evaluate the call, and then route the call back to the CFS with a recommendation on how to process – e.g. block the call, or send to the subscriber. You can see that in time there’s potential for a lot of granularity in the options – a call could be blocked, or sent straight to voicemail, or the caller could be forced to press a key to continue, or the call could be delivered with some kind of visual indication to the caller that it’s suspect.
Interestingly, the ATIS framework report about STIR/SHAKEN discusses the idea of Call Validation Treatment (CVT) as part of the STIR/SHAKEN verification – which basically suggests that one day the Robocall blocking application could be combined into the STIR/SHAKEN verification, rather than having two different steps as we do today.
What does this all mean for rural telcos?
Looking at how the political wind is blowing, and understanding how the technology works, if I were a rural service provider I would draw the following conclusions.
- There will soon be regulations requiring both STIR/SHAKEN and robocall blocking.
- This will cost rural carriers money, for a service that may need to be offered to subscribers at no charge – so this would be a great time to ask the FCC about cost-recovery for this mandated network upgrade.
- The Metaswitch / TNS Call Guardian partnership is probably the easiest way to implement a robust solution quickly.
- Caller ID authentication only works over SIP so if a telco wants their outbound calls to be validated by the network (improving call completion), they should make sure they are using SIP trunks for long distance.
- In fact, as I’ve written about before, unless independent telcos can use SIP for all calls – local and LD, inbound and outbound – they’re going to really struggle to compete against the big guys. Personally I think the NTCA should be lobbying to require all RBOCs to provide SIP interconnect to all their local tandems. I’m not particularly optimistic that anything will happen, but anyone using TDM will be at a disadvantage if/when the new regulations are implemented.
If anyone has any insight on the political side of things I’d be fascinated to hear from you. If you’re considering deploying STIR/SHAKEN and/or Robocalling I’d be curious to hear more about your current thinking – what’s prompting you to act, or what’s holding you back.
