[VoiceOps] Call term misrouting?

Wed Jul 26 11:01:02 EDT 2023

Mark's reference to the RCC regs is pointing in the right direction.

The problem stems from sketchy providers trying to save money routing via
circuitous pathways, which often end up with the misbehaviors cited in this
thread.

Nathan's comments that he's been through TWELVE rounds of provider
blacklisting shows what a mess this is.

Recognizing the problem, the FCC as part of their RCC initiative several
years ago put a "safe harbor" in place to incent providers to perform direct
routing to rural locations:
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart
-V/section-64.2107

Go to a reputable intermediate provider and tell them that you want a rate
deck that conforms to this safe harbor, which dictates direct or one-hop
routing. You will pay incrementally more for this rate deck, and you will
get more than your money back in terms of time saved from all this trauma
chasing completion issues. If you want a suggestion of where to start, I'd
say try Inteliquent.

David Frankel
ZipDXR LLC
St. George, UT USA

-----Original Message-----
From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mark R Lindsey
via VoiceOps
Sent: Wednesday, July 26, 2023 8:32 AM
To: Nathan Anderson <nathana at fsr.com>
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Call term misrouting?

It would not only be a form of fraud, but sounds be a violation of the Rural
Call Completion rules (specifically 47 CFR 64.2119(a)). I would recommend
you make a complaint to the FCC and categorize them at Rural Call Completion
issues. Provide as much info as you can on carrier names, dates and times of
the calls.

The FCC staff do contact carriers and intermediate providers to track down
RCC problems. I worked with one rural provider in the US on an issue related
to rural call completion, and our complaints were getting callbacks to help
us troubleshoot from Comcast, Verizon and AT&T at different points in the
troubleshooting.

The FCC requires all the intermediate providers to retain records of call
routing attempts in a readily-accessed format for six months.
https://www.ecfr.gov/current/title-47/section-64.2103

There are minimum standards of quality for carriers related to the
successful delivery and routing of calls.
https://www.ecfr.gov/current/title-47/section-64.2119

(I'm an engineer, not a lawyer, and this is technical advice, not legal
advice.) Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting
<https://ecg.co/lindsey/schedule> | Newsletter
<https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944
/>

> On Jul 26, 2023, at 09:28, 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

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops