[VoiceOps] Call term misrouting?

[David Knell]

Hi Nathan -

I don't think that your supposition that the calls are being misrouted for
the carrier doing it to collect the termination revenue's far from the
truth.  This has been going on forever in myriad ways - send answer on
ringing (extends the chargeable duration of a call), route calls to fake
voicemail systems (had this just the other day on a UK cell route), answer
calls with a recording of a "fruity" conversation (so the caller assumes
it's a crossed line and eavesdrops), etc., etc., etc.  We've had calls to
our IVR services hijacked and terminated on a clone of the service.  It's
just nuts.

The root of the problem, in your case, is rural carriers who have a dozen
subscribers and a massive free conference call service hanging off an
enormous termination rate..

Cheers --

Dave

On Wed, Jul 26, 2023 at 3:28 PM Nathan Anderson via VoiceOps <
voiceops at voiceops.org> wrote:

> ...by which I mean, we send a call to a term provider via SIP, who then
> *seems* to terminate the call to the wrong callee entirely.
>
> What the heck actually causes this?
>
> Whenever I have experienced it, it inevitably involves a rural carrier of
> some kind, one that likely charges a lot to accept traffic.  Over the
> course of a few days, we just went through twelve rounds of having a
> wholesale term provider blacklist various carriers from their LCRs for
> calls headed to this particular exchange, before the problem stopped
> happening.  "Is it working yet?"  "Nope."  "How about now?"  "Still nope."
> And it's random and sporadic enough that I have to place a lot of test
> calls (as well as continue to field feedback from our end-users) before I
> can be sure that the problem is actually fixed.  It's aggravating...
>
> It doesn't seem to be the final destination carrier that's screwing up the
> call routing after having received the call: I can call the same number
> over and over again through a "reputable" carrier, or via my personal cell
> (but I repeat myself), and get connected to the right destination every
> time.  Based on my experiences, I highly doubt the misdirected calls are
> even getting as far as the CO's switch for that exchange.
>
> So I have to hypothesize that some sketch carrier getting is picked from
> an LCR table, one who just doesn't like sending the call to a rural carrier
> who either charges that much, or that they suspect is engaging in fraud.
> But...WHY *misroute* it?  I'd rather you just reject the call if you don't
> want to carry it.
>
> The misrouted calls in this latest case more often than not seemed to be
> hitting a foreign voicemail system that sounded an awful lot like AT&T
> Mobility's default voicemail greeting.  But we have definitely had calls
> just end up ringing the absolute wrong phone...in one case a few months
> back, I tried ringing the public library branch in this one rural town, and
> ended up getting the answering machine for some random business (...and
> also the call quality was *abysmal* on top of that).  (Never did manage to
> figure out where that business whose answering machine I got was actually
> located.  It was a generic-enough name for a business in their industry,
> but what I can tell you is that there was no business by that name in the
> rate centers covered by that rural carrier.  And also that my CDRs back up
> the fact that I did *not* mis-dial that call.)
>
> About the only theory I can come up with that makes a lick of sense is
> that these cut-rate carriers in these LCRs decide to throw to a rando
> number if they get asked to term to a high-cost exchange, so that they can
> record a call completion and charge the caller for it anyway.  Which would
> be a form of fraud itself, if that's actually happening.
>
> I suppose there could be a leg of the call that is being signalled
> non-digitally (so, not SS7, not SIP, ...), and something is getting either
> mis-transmitted or mis-interpreted.  But if they were doing something like
> (e.g.) in-band DTMF over a crap connection to an old switch somewhere, I
> would expect dropped digits, and thus not enough to construct a viable &
> valid destination number out of.
>
> -- Nathan
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20230726/927fb71c/attachment.htm>