[VoiceOps] Call term misrouting?

Wed Jul 26 18:43:40 EDT 2023

I wouldn't be surprised to see carriers dumping these calls via a GSM gateway, this is really common in europe with gray routes. It'd explain why you get weird cellular voicemail, if they sent the number to the cell phone wrong to actually dial out.

> On Jul 26, 2023, at 6:36 PM, Nathan Anderson via VoiceOps <voiceops at voiceops.org> wrote:
> 
> I just want to briefly point out that I was engaging in some hyperbolic metaphor with the "twelve rounds" bit, and it seems to have misfired.  It wasn't literally 12, and apologies for (unintentionally) misleading anyone.  I was attempting (poorly, apparently) to use a boxing analogy (and what I thought was a fairly commonly-understood idiom) merely to underline that the fight was long and drawn out & it took a lot of back and forth.  It also involved 2 separate tickets with 2 of my direct providers, one a few months back, and the latest one was opened last Thursday and was only resolved yesterday after number of exchanges (that I didn't bother to actually count; heh) over the course of that near-week-long period.  And now it's looking like we are going to need to open yet another ticket with a 3rd provider of ours...
> 
> I was also more interested in exactly what is happening during the "routing via circuitous pathways" that would cause a call to be delivered to the wrong destination.  I can understand crap call quality, long connection times, etc. all in an effort to save a buck.  But sending the call to the wrong endpoint entirely??  Assuming it isn't someone doing something intentionally fraudulent, what *technical* explanation can there be for such a break-down occurring?
> 
> -- Nathan
> 
> -----Original Message-----
> From: David Frankel [mailto:dfrankel at zipdx.com] 
> Sent: Wednesday, July 26, 2023 8:01 AM
> To: 'Mark R Lindsey'; Nathan Anderson
> Cc: voiceops at voiceops.org
> Subject: RE: [VoiceOps] Call term misrouting?
> 
> 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
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops