- VoiceOps - lists.voiceops.org

ATT contact
by dovid＠telecurve.com Aug. 14, 2023

Aug. 14, 2023

I know this is a long shot. I have a client that accidentally advertised a number owned by ATT (TC SYSTEMS, INC. - NY). The number goes to a message saying it's not in service so I am hoping it's available. Does anyone have any contacts at ATT to see if I can get a number? It's in Fire Island NY if that helps. TIA. Dovid

1 0

TF CPR dip?
by nathana＠fsr.com Aug. 9, 2023

Aug. 9, 2023

Paul Timmins wrote: > If you have access to TCAP queries via SS7 or SIP, you can fire the > query yourself. I do not; at present we are merely offloading term traffic to a couple of different SIP term wholesalers. -- Nathan

1 0

TF CPR dip?
by nathana＠fsr.com Aug. 9, 2023

Aug. 9, 2023

Jay, Thanks; yes, I understand that & thought I made that clear later on in my post. So to restate/rephrase: 1. How does direct (as opposed to call-forwarding-esque) TF origination work, exactly? As far as I can tell, all such numbers are still comprised of CPRs in the SMS/800 database, and ultimately (after consulting the table to account for originating number/LATA, time-of-day, etc.) every TF routing decision still boils down to a pairing of CIC + some valid 10-digit NANP number. Yes? So, for "direct" routed TFs, is the 10-digit destination just set to be equal to the TF number itself? 2. How does one look up the CPR for a given TF number? I have reason to believe that the particular TF numbers I'm interested in are not "direct-routed", but in any case, my questions about these numbers would be quickly answered if I could simply perform some kind of route look-up on the number(s). *Must* you be a RespOrg and onboarded to the SOMOS portal to be able to do this? There are all sorts of third-parties that provide LRN dip services...it's surprising to me that a similar market of services does not seem to exist for what I view as the analogue in the TF world. I really don't even care for the whole CPR: all I really want to do is basically perform the same look-up that would be made during an actual call, and know what the singular routing decision would be for that call to that TF number at that particular time of day and given a particular originating exchange. -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jay Hennigan via VoiceOps Sent: Wednesday, August 9, 2023 8:04 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] TF CPR dip? On 8/9/23 19:54, Nathan Anderson via VoiceOps wrote: > Is this even a thing? Is it possible to do a look-up on a TF number and know ultimately what local number a call to that TF number is going to be sent to? It may not go to a local number at all. It can terminate on an old-school toll trunk (PRI) or be delivered by SIP as the native toll-free number. "Switched" TF is translated to a local number by the provider and delivered over the PSTN/VoIP on that local number. "Dedicated" TF is delivered directly to the customer natively as the TF number. More complex schemes can be set up with routing based on originating NPA/NXX, time of day, etc. as well. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

3 3

TF CPR dip?
by nathana＠fsr.com Aug. 9, 2023

Aug. 9, 2023

So, I'm not a RespOrg (though I've considered it), thus have no access to SOMOS, and know extremely little about TF call routing; don't hurt me... Is this even a thing? Is it possible to do a look-up on a TF number and know ultimately what local number a call to that TF number is going to be sent to? >From the little Googling I've done so far, it's not clear to me if a CPR record actually contains the final destination (perhaps it does *sometimes*), or if the "destination" typically just represents a number belonging to the IXC that will finally complete the call (similar to LRN for routing a ported local number to the right switch). I'm guessing the latter? in which case it's impossible to know what the actual final destination of the call is just by consulting SMS/800...the destination would ultimately be proprietary information that only the long-distance provider responsible for those calls could know...? (I'm guessing this is made even messier today by the existence of direct SIP TF origination, in which case there is no true "local" number that the TF is being forwarded to. Knowing that this is a thing is driving some of my assumptions here. Though perhaps I'm misunderstanding how this works under-the-hood...maybe a CPR does always contain the actual destination #, and what's happening in the case of direct SIP origination is that the CIC points at the SIP provider, and the "destination" is set to be the same as the actual TF number itself? Does that work / are you allowed to do that?) Though I'd love to understand all of this more in-depth as a whole, the particular thing driving my query at the moment is that a prospective customer -- who is a local branch office of a national firm -- is asking us about issues with call quality and call completion that they have been experiencing when calling their HQ via the HQ's TF numbers (there are several, each of which apparently route to different departments at different destinations), when making those calls via ILEC, where ILEC is also their LD provider. They do not experience the same issues when calling those same TFs via mobile. They have tried to work with ILEC to try to resolve these issues to no end, and want to be assured that either they would not experience the same problem when sending those calls through us, or that if they do, we could (unlike the ILEC, apparently) actually work to solve the underlying issue / route around it. If we do run into the issue to these particular numbers, short of opening tickets with whomever we term the TF calls through, one thought I had would be to have end-user bypass the TF#s entirely, and to try direct-dialing the local number that they point to instead. The question is how to determine what those destination numbers actually are. Thanks, -- Nathan

2 1

Dominican Republic LERG Data
by beckman＠angryox.com Aug. 9, 2023

Aug. 9, 2023

Customer states their DO Number is active with Claro. Twilio states that it is not active with any carrier. My LERG sources only have US and Canada NPANXX data. Where would I get Dominican Republic LERG data (area codes 809, 829, 849) without paying hundreds or thousands of dollars? Any lookup services? Beckman PS -- if you have access, email me privately and I'll send the number to check. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

4 9

Bandwidth Outage
by ctaloi＠gmail.com Aug. 7, 2023

Aug. 7, 2023

All of my 1+ termination to Bandwidth is failing to a 503 as of 2:30PM EST. Support is telling me they have an issue but they are not sure what yet. Is this impacting anyone else? Chris

2 1

Carriers that support cic codes
by ciscoplumber＠gmail.com Aug. 4, 2023

Aug. 4, 2023

If a SIP carrier wanted to support equal access, is there anything like a SIP tandem provider that can accept any Carrier Identification Code (cic=) and route to the appropriate LD carrier? The TDM equivalent might be something like Neutral Tandem. Thanks

2 1

Call term misrouting?
by nathana＠fsr.com July 26, 2023

July 26, 2023

Mike Johnston wrote: > On 2023-07-26 17:43, Paul Timmins via VoiceOps wrote: > > 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. > > I've heard of this! > In one instance, the call would come through every one in a dozen or so > attempts. And it would often have the wrong calling number. Generally > belonging to a cell provider. Audio was not great and there was > noticeable latency. The call would only go for a few minutes before > dropping. Going back to the "wrong voicemail system" thing, though...I could easily see a call being placed via a GSM gateway carrying the wrong CLID info (call being sourced from phone # owned by the cell carrier, rather than the original caller). But whenever we would hit these voicemail systems, they would clearly read back to me the number that I *dialed* (e.g., "2125551212 is not available"), demonstrating that -- IF this is a legit voicemail system -- the diversion/RDNIS info is being properly signalled to it. Having RDNIS pass through unmolested over wireless via a gateway seems 1) unlikely (how would that even work? is it possible for a wireless endpoint to signal that??), and 2) the sensation one gets is that the mobile carrier's OWN voicemail system has somehow mistakenly been sent the call, which still doesn't make sense. So your theory about it being a fake termination makes way more sense to me. -- Nathan

1 0

Call term misrouting?
by nathana＠fsr.com July 26, 2023

July 26, 2023

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

3 2

Call term misrouting?
by nathana＠fsr.com July 26, 2023

July 26, 2023

I suppose a GSM gateway is a remote possibility. But I don't see how that explains the voicemail system answering the call. If I place a call from my personal cell to some number, and for some reason my cell carrier fails to complete that call for me, that call is not then sent to my cell carrier's *own voicemail system*. Something would have to be really screwed up for that to happen. -- Nathan -----Original Message----- From: Paul Timmins [mailto:ptimmins at clearrate.com] Sent: Wednesday, July 26, 2023 3:44 PM To: Nathan Anderson Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Call term misrouting? 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

1 0