I think this might be the least-sexy subject line I ever wrote.
Every time I send out an email I get a report from the email service (Drip) showing what percentage of recipients open the email – and I can learn from that what subjects are more (or less) interesting to you, our amazing readers and clients. I’m betting that this email has a very low open rate – let’s see if you all prove me wrong.
(Note that this message is specifically for those of you with a Metaswitch, so if that’s not you, feel free to archive and move on with your day.)
The problem
Unless you’re new to telecoms, you’ve probably heard the term Robocall Mitigation these past few years. In brief, it refers to steps that you take in your network to prevent illegal robocalls from being sourced from your network.
There are a variety of ways of approaching this, but one of the better technological approaches is to route all outbound calls via a SIP trunk to a cloud-based service, which is able to evaluate the call and assess how likely it is to be an illegal robocall. The service then returns a 404 Not Found, allowing routing to continue to the “real” outbound trunk, while also producing a daily report for service providers, who can investigate suspicious calls. (Many of our clients use ClearIP from TransNexus for this service, although Metaswitch Call Guardian Authentication Hub and other products act similarly.)
This all works well, however if you use Route Verification Tests (RVTs) as a way to validate your Metaswitch translations you’ll find that every call is now shown to route to your Robocall Mitigation provider, rather than the real destination, with the result that all your RVT results are misleading.
For example, if you review your RVT result in SAS, it may look like this.
In this example routing table 99 is for sending calls to a ClearIP SIP trunk for robocall mitigation. Since RVTs don’t go past the first “Routing succeeds” line, the test finishes here. As far as the test knows, all is well (unless you’ve set an expected result to specify a particular trunk, in which case all your tests will now be failing).
What should I do?
It’s likely at this point that you’re not trying to make sure your robocall mitigation routing is working properly – you want to know where the call is actually routed to, after robocall mitigation is complete. To make the RVT work as expected, you’ll need to exclude the RM trunk from your RVT group.
The good news is that it’s very easy to do. On the test group object – not an individual test, but the test group – scroll down a little more than halfway in the right pane. There will be a section called “Included media channels”.
Set the “Media channels included” parameter to “All except specified” in the dropdown menu. A new set of fields will appear for excluding trunks. Click the button with three dots on the “Media channel 1” field, and select your robocall mitigation trunk. When you’re done, it should look something like this:
Now when you run your test, the step to route to your robocall mitigation trunk will fail since you’ve excluded that trunk. The test should then hit whatever failover option you’ve configured for bypassing the RM trunk when it’s down – i.e. the real PSTN trunk that receives this call.
Having not succeeded at the RM step, the RVT will now go through the post-RM steps and actually test the call’s true routing as you were intending.
This has been a public service announcement for anyone using RVTs on a Metaswitch alongside a Robocall Mitigation service.
Thanks to David Wunderlich for the idea for this article, and for writing the majority of it.
If any of our clients are having a hard time implementing this change, feel free to reach out through your usual channels. If any of you are having regular problems with translations changes, then you might want to consider adding some RVTs to your repertoire, as an easy way to test any changes before going live.
