By Simon Woodhead
We’ve banged on about CLI filtering for years. Ofcom GC C6 even mandates it, if anyone – including Ofcom – cared to interpret it as originally written. Invalid CLI is bad, often the result of mis-configuration and ultimately harms end users.
More recently, a number of countries began implementing origin-based surcharges on calls which can make calls from certain originating countries very expensive, to us not to you, because we took a decision to take the rough with the smooth rather than overcomplicate our billing. However, on examining these, the vast majority of cases are where the CLI is plain wrong. For example, we don’t have a massive customer in Brazil causing us surcharges of £0.05/min on routes we sell for less than £0.01, we just have a few customers who cannot (or will not) format UK CLI correctly!
At the same time, now we’re licensed in eleven states in the USA, we’re seeing a very different standard of network cleanliness. I might describe our standards as the better end of European standards; they would describe them as “typical VoIP”. Of course, maintaining that standard in a region where every number is exactly the same length and every number is also ‘dipped’ to see if it is alive and ported, is trivial. Doing so for the rest of the world less so.
Some operators apply a regex, often just to filter country code. Some rely on their downstream operator to further check length. Some rely on the destination network to actually confirm the number is alive and, in many cases, this last step is unavoidable as only they have that data. We’ve applied a combination of all the above to date, but need to tighten it up.
So, effectively immediately, all calls are going to have their destination and origin strictly filtered. By strictly filtered I mean we’re going to be checking:
- Are they valid in terms of format, including the length expected for that particular number range in that particular country. If you are leaking erroneous prefixes or suffixes, calls will fail this test.
- For the UK, we’re double-checking the Ofcom numbering database to ensure the number range actually exists in issue, and the length expected. We’re handling inconsistencies in said database.
- For the US, we will be double-checking and relying on the various dips we do, and network intelligence we have.
- For other countries we’re applying lots of meta-data from the ITU and direct operators to determine if the range is valid and allocated.
The goal here is to ensure that filthy calls do not leave our network and by implication you are compliant, without imposing draconian or complicated changes that make us hard to do business with. Of course, if you genuinely don’t care about compliance or end-use harm, there’s plenty of other carriers (or more likely resellers of resellers calling themselves carriers) who don’t care either.
Of course, we’re not simply turning this filtering on, you need warning. You will already see invalid destinations rejected by us with appropriate SIP codes and you will already see (and have for many years) X-Warning headers for Invalid CLI. Hopefully you are tracing and acting on those. For the coming week, we will be repurposing those X-Warning headers and you may see ‘Invalid CLI’ or ‘Invalid destination’ in our initial response to your INVITE. If you see this it indicates a call that would have been rejected Simwood-side if the filtering was live.
Our intention is to monitor the changes we’ve made to assess the calls rejected for the rest of this week. All being well, we then intend to make the filtering live on Monday April 13th and any outbound calls that have until then had an X-Warning header, will instead be rejected.
Whilst this also needs to apply to inbound calls, we’re aware of other networks (notably BT via IPEX) who have resellers passing problematic caller ID – you’ve opened lots of tickets with us about it and they’re working to bring the seven resellers into line. Whilst technically we are required to block this traffic under GC C6, we’ve been alone in complying before and don’t wish to disrupt your traffic due to a known issue elsewhere. We will apply it to inbound when the majority of calls are unaffected.
We’d implore you to please check your interop before traffic begins failing. We’d also remind you that if sanitising your own equipment is problematic, or you, for example, forward calls with potentially missing/invalid CLI, you can set a ‘default’ CLI for each wholesale trunk. That default will be applied on all calls regardless of what you send us. This is a very quick and easy solution for the majority of customers, although do remember it’ll be applied for all calls on that trunk so your trunk usage strategy might need some thought.
Lastly please remember, for all Simwood Partners, we take care of technical regulatory obligations, such as this, that normally go with operating your own platform. We’re also offering free migration as one of our COVID-19 assistance measures. We appreciate you, all of our customers, whether Wholesale or Partner of course!
