By Simon Woodhead
Last week we sent a mail and posted a blog about our GC C6 filtering on both CLI and dialled numbers globally. This is an update on that!
There was some lively chat on our community Slack about why we weren’t telling you which calls we were rejecting; we weren’t because you could see them in your own SIP traces and monitoring. However, we relented and began notifying everyone about calls that would in future be rejected. There was then some lively chat on our community Slack about why we were telling you about things you could see in your own SIP traces and monitoring!
Joking aside, that prompted us to publish an FAQ (restricted to customers only) on this wider topic and going into greater detail about what we were doing, why, and how it would work through to customers. I’d recommend you read this if you haven’t already.
For the last week, we’ve been monitoring and reporting internally on the volume of calls across our customer base that will be rejected when this is turned on, on April 20th. From that, we firstly confirm that it will indeed be turned on on April 20th. But there’s two other things to talk about:
- What have we seen?
- What about customers who need more time?
Observations
We’ve seen a few trends with calls we’ve notified on, that for simplicity we’ll call ‘rejected calls’.
Two customers account for 54% of the rejections, and no it probably isn’t you! One is a Startup customer who completes very little traffic but sends seven times as much in calls that fail; clearly an LCR failing over with rubbish. Another would tell you they’re a competitor of ours and clearly have very naive failover too. 60% of their traffic will fail next week, which speaks volumes about the quality of the routes before us that are failing traffic we can subsequently complete, i.e. only 60% of everything that failed elsewhere is not completable. The vast majority of customers are in pretty good shape though and shouldn’t be too worried.
Even including those two significant outliers (which more than double it), rejected calls run at 1.78%.
Rejected calls are pretty evenly split between bad CLI and being to an invalid destination. CLI has it by a hair – 53.3% to 46.7%.
Given calls to invalid destinations will ultimately fail anyway (discounting the possibility of us having a false positive), this means that CLI related rejections will amount to 0.82% of traffic. Again, this is doubled by the outliers.
This is outbound only. Inbound CLI remains too dirty to contemplate filtering yet. Yes, unsurprisingly, you’re doing a much better job than the rest of the industry!
Need more time?
We said last week that we would not be extending this on a per customer basis, and on aggregate there is no need to delay turning rejections live. However, we have no wish to cause anybody any unnecessary stress.
Back in the early days of GC C6, when we implemented a useful interpretation of the rules and before the guidance was reissued to make them pointless and side with an incumbent MNO, a number of customers needed the rule dis-applying to them.
Whilst we all (you, us, and the party receiving the call) have to apply these rules, we put in place a waiver that said for Virtual and Managed Interconnect calls, we’re effectively transiting the call and will not filter. You maintain the responsibility for filtering but doing so is your problem to put it bluntly, and we agree we’re not doing it for you.
Those waivers remain valid and our Ops desk are contacting the people who signed them to assess:
- Whether you wish us to now filter CLI
- Whether you wish the waiver to stand and pay a surcharge on traffic passed that we determine to have invalid CLI
We will default to a position of filtering, with or without the waiver in place, so please respond to us if this matters to you. Other Virtual and Managed Interconnect customers are welcome to put new waivers in place if there is a good reason, and ultimately at our discretion considering overall traffic quality.
As to the surcharge, this is a commercial necessity given past commentary about EU surcharges, but also present in other places such as the US where it is referred to as ‘non-jurisdictional’ traffic, i.e. one can’t tell where it came from and that is critical for billing it. Whilst the principle of a surcharge will be introduced to our billing within the next 24 hours, we are setting the rate of it to 0. From May 1st, however, this will increase to the level advised in the FAQ of 20p per minute. It’ll be disclosed in our ancillary charges rate sheet thereafter.
This feels like a compromise that balances customer need and commercial necessity, with a longer buffer in between of business as usual!
Once the charge is introduced, whether at 0p or the intended rate on May 1st, surcharged calls will be visible in CDRs. To reiterate, the surcharge will only apply for those who have signed the waiver and asked us to pass calls with invalid CLI and have sent a call with invalid CLI. Only when all those circumstances exist, the description in our CDRs will be suffixed with “(Invalid CLI uplift)”. For example: “United Kingdom – Mobile – EE (Invalid CLI uplift)”. The rate shown will also reflect the presence of the surcharge.
To be further clear, we are not applying a charge where calls are rejected due to invalid CLI or destination at this time.
***
Thanks again for embracing this change and contributing to cleaning up UK telecoms to ultimately protect end-users.
