- VoiceOps - lists.voiceops.org

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

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

July 26, 2023

Mike Johnston wrote: > I serve a rural area. I do the technical "make it work" stuff. I'm > generally only involved in the business dealings insofar as determining > technical incompatibilities (draw 7 red lines, all perpendicular, some > with green ink and some with transparent). That said, please forgive > any errors in what I say, and feel free to correct me. This was all super interesting and helpful; thanks! > I try to find numbers that go to IVRs, fax numbers, automated airport > weather numbers, etc. Anything that doesn't involve bothering a human > over and over. It has to be with the same OCN though, and generally > needs to be in the same NPA-NXX too. Yes; correct. In this particular instance, a county library system that we service a lot of branches for was having trouble calling a particular branch that lies outside of our service area. I knew that branch's operating hours, and they have an answering machine, so I would run my tests while they were closed. > These are generally fake voicemails. Just a recording of some voicemail > intro, to make you think you hit a voicemail box. The call hasn't > actually been mis-routed. It hasn't been "routed" anywhere, other than > to an audio file. I suspected it was either this, or it was hitting a genuine voicemail system that was perhaps misconfigured and accepting calls for any RDNIS / voicemail boxes it received. Though I guess if I'd thought about it for 2 seconds, if it had actually been AT&T's voicemail system, then it would have told me that the destination mailbox in question had not yet been initialized / set up. > Are you sure it actually rang a line at some business? Or maybe it was, > again, just an audio file? Some wav file on a server at Bob's Shady > Long Distance Shack? [...] > I would argue it is fraud. But again, prove to me they are actually > "routing" to any number, and not some audio file. Fair point. I don't actually know. -- Nathan

1 0

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

July 26, 2023

...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

5 4

PSA - Hosting SHAKEN cert behind Cloudflare
by compuwizz＠gmail.com July 16, 2023

July 16, 2023

We were notified that some validators were unable to pull our cert which is hosted behind Cloudflare. I believe the fix is to create a WAF rule to match when the User Agent contains "Java/1.8.0" and then choose the Skip action. Please share if anyone has any better tips for WAF rules for this scenario. I was seeing Bandwidth, TransUnion, and Level3 getting blocked. TransUnion gave me the heads up and mentioned they saw it with other carriers lately also.

2 1

No-commit international calling
by ross＠tajvar.io July 14, 2023

July 14, 2023

Hi all, I have an asterisk PBX for personal/business use. I use Flowroute for both origination and termination. Recently I've started needing to make some international calls (specifically mostly to the UK, but also some other places in Europe and Australia). There've been a few numbers where completion is very hit-or-miss, and a few that seem not to work at all (in both cases I get a SIP 500 back from the carrier). I'm wondering if this is a carrier issue - maybe Flowroute just has low-quality routes to some destinations? I'd like to try other carriers, and ideally keep a second one as a fallback, but I'm not sure who's out there with no commit. Looks like voip.ms is one option. Does anyone have any other suggestions? Thanks, Ross

9 9

Historic Number Data (+1)
by calvine＠gmail.com July 13, 2023

July 13, 2023

What are some recommended sources of number data, as it has changed over time? I only need from 2019 onwards, anything before that is less useful the older it is. Firstly the actual number data: Activate/Deactivate/Reactivate/Reassign NPA, NPA-NXX, Thousand Block, TN Mobile/Landline I presume everything but TN can be obtained from NANPA or National Pooling reports. I think neustar PortPS might have TN porting history, are there any lower-cost alternatives? Then the related data I'm looking for: Latitude & Longitude (Rate Center and Switch, for different reasons) Address data like City, State, Zip, or City, Census Division, Province/Territory, Postal Code (not specific TN addresses) Population I'm aware of telco-data and localcallingguide, but not if they have historical data.

4 4

Update on STIR/SHAKEN
by nathana＠fsr.com July 13, 2023

July 13, 2023

Personally, I'm quite curious to know how the ITG would even be identifying these companies as being distinct from the wholesaler, at least without a traceback request for an actual violation, where the investigation (that the wholesaler would likely be not only cooperative with but actively involved in) eventually revealed that all of the violations were originating from one particular customer of theirs. But sans any violations to look into...how would they know? In particular, when asking these questions, what I specifically have in mind are wholesalers not like VI/Sangoma et al., but more like e.g. https://atheral.com/, which carries traffic for a bunch of smaller regional ISPs that want to offer VoIP but don't want any of the headaches associated with doing so. So most of them I presume literally own no infrastructure of their own...no softswitch, no SBC, no nothing. They might be 499 filers, but that's likely the extent of their direct regulatory involvement. I believe Daniel might be hanging around on this list, so perhaps he can shed some light on how they have been advised to approach this (whether they are signing all calls with their own SHAKEN cert/key, or whether they can host SHAKEN certs owned by their customers and sign the end-users of that customer's calls with that customer's own cert, or a mix of both). -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mary Lou Carey via VoiceOps Sent: Wednesday, July 12, 2023 1:29 PM To: voiceops at voiceops.org Subject: [VoiceOps] Update on STIR/SHAKEN I spoke with my FCC contact today and was told to read the last order issued in March so his response wasn't crystal clear. He said the FCC is still in the process of deciding which types of companies can sign with a third-party vendor's token and which ones can't. I told him my concern is that the ITG is going to start blocking traffic in August and companies won't know that they aren't compliant because their wholesale provider told them they were fine. I specifically asked, "If the ITG decides a company should have had its own token, will you give them time to get one?" He said they have a process for handling these issues, but he didn't come out and say "Yes" so here's what I would suggest since the process can sometimes take longer than the 30 days they give you to comply. If you are using a third-party provider whose signing with their token. At least complete the preliminary steps to qualify for your own STIR/SHAKEN token. That way if they do come to you and tell you that you need to get it on a moment's notice, you won't be fighting the clock so much. The pre-requisites for filing with the STI-PA to become an approved carrier are: 1. Order your own OCN (aka company code from NECA) IPES is the correct type for all VOIP carriers 2. Have your 499 up to date and fees paid. If you've never filed a 499A yet, get your 499 filer ID and submit your first 499-A. (All carriers delivering long-distance traffic in the US should have already completed this step anyways). 3. Robocall Mitigation Plan filed. There are multiple companies helping carriers get their STIR/SHAKEN certificate, so it doesn't matter if you use my services or anyone else's. I just want to make sure everyone is aware of what they need to do to make sure their traffic doesn't get blocked because thats a lot harder to fix than getting a certificate/token is! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

4 3

STIR/SHAKEN warning!
by nathana＠fsr.com July 13, 2023

July 13, 2023

I guess I should clarify that what I intended to communicate by "a few years ago" would be more, like, 5-10 years or even more; heh. And I'd wager that even for as rapidly as SIP has been adopted in the corporate world, even a decade ago there had to be considerably more Fortune 500s out there with a wide installed base of PRI trunks relative even to today. And of course, if anybody were using their TFN as their outbound CID more than 2-3 years ago, not only would S/S not even have been much of a thing yet at that point (to the extent it was implemented at all, my understanding was that it was mostly being bootstrapped with self-signed certs), but apparently there was also no authoritative CNAM database for TFNs prior to March 2020 as was just clarified in this thread. So it makes sense that now that both of those things exist + how many inroads SIP trunking has made into enterprises that the use of TFNs in CID has exploded in just a couple of years' time. Just as a potentially interesting data point, we have had TFNs parked with various SIP-first providers (who also act as RespOrgs as well), none of which have yet to pass a single S/S PASSporT/Identity header our way on any calls made to any of those numbers... By the way, love your service. Thanks for putting it together and maintaining it...what a gift to the community. There are a handful of S/S testing tools out there, but yours is easily the most comprehensive...most just audibly read back to you whether or not your call was attested, and if so at what level. Nothing about who signed it, whether the backing cert and entire chain of trust is valid or not, and so on, as yours does. And since most other tests only provide one call-in number, if the call path between you and that testing tool happens to go through an intermediate carrier that strips out our PASSporT and either replaces it with their own or drops it entirely, tough noogies. Whereas you provide multiple call-in numbers across multiple carriers, which not only provides opportunity to work around such issues, but gives you some idea of call paths that might be breaking transmission of your PASSporT and which ones are okay. Super helpful! From: David Frankel [mailto:dfrankel at zipdx.com] Sent: Friday, July 7, 2023 3:21 PM To: Nathan Anderson; 'Voice Ops' Subject: RE: [VoiceOps] STIR/SHAKEN warning! Nathan, Regarding TFN???s as caller-ID: This became quite popular more than a mere few years ago. Many customer support operations (banks, brokerages, airlines, insurance companies, credit card companies) place outbound calls using their toll-free customer support number as caller-ID. In our RRAPTOR robocall surveillance platform, we have captured many, many thousands of calls with a TFN as the calling number. And the majority of those calls are signed, with varying levels of attestation. Most enterprise calls these days that I???m familiar with are initiated over SIP trunks (not PRI or analog trunks or POTS lines) and include the calling (FROM) number in the SIP INVITE. Regarding signatures on calls TO TFNs: This also definitely happens. Our SHAKEN identity test tool (at https://portal.legalcallsonly.org/Info/Identity) lets users call any of several test numbers, including some TFNs. We see signatures on many calls to those test TFNs. (We don???t save data for calls that do NOT have signatures, so I can???t tell you the fraction.) I do know that there are some toll-free providers that ALWAYS (or usually) have TDM in the call path. Since IDENTITY headers don???t travel over TDM, those calls will not have signatures at the terminating end. David From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Nathan Anderson via VoiceOps Sent: Friday, July 7, 2023 3:55 PM To: Voice Ops <voiceops at voiceops.org> Subject: Re: [VoiceOps] STIR/SHAKEN warning! Thanks; I had no idea this was a thing. -- Nathan From: Paul Timmins [mailto:paul at timmins.net] Sent: Friday, July 7, 2023 2:39 PM To: Nathan Anderson Cc: Voice Ops Subject: Re: [VoiceOps] STIR/SHAKEN warning! Always worth pointing out that in March 2020, Somos rolled out TFNIdentity. We have it set up on customers who want to source from their TFNs, I haven't seen many carriers actually look it up, but it does exist. On Jul 7, 2023, at 5:34 PM, Nathan Anderson via VoiceOps <voiceops at voiceops.org > wrote: I suspect things might be different now (& I just haven't kept up), but although it is clearly *possible* to transmit a TFN as the calling number / CID, I seem to remember that even just a mere few years ago, it was HIGHLY discouraged, and if you ever were to receive a call bearing a TFN as its CID, it had a very high likelihood of being fraudulent or spam. This was of course back when the vast, vast majority of TFNs were essentially implemented as a call forward or alias to a number that hung off of a local exchange. So of course outbound calls that many? most? companies with TFNs would make would typically be sourced from their local exchange number(s) and not from the TFN (s) (unless maybe a given company had a PRI and their provider allowed them to source calls from their TFN?). Thus the expectation for a long time (as I understood it) was that TFNs were truly inbound-only and should be treated as such. Loosely tangentially related, as a purely anecdotal report, I will note that I have yet to see a S/S signature/PASSporT attached to ANY calls made *to* ANY of our TFNs, via any of the 3 SIP wholesalers we have used as both RespOrgs & for actual traffic. -- Nathan From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Frankel via VoiceOps Sent: Friday, July 7, 2023 7:52 AM To: 'Ivan Kovacevic'; 'Voice Ops' Subject: Re: [VoiceOps] STIR/SHAKEN warning! Ivan asks: ???How are you handling TFN atestations???? When the signer of a call gives A-level attestation, it means that the signer knows that the caller ???is authorized to use??? the calling number. The signer can ???know??? that in any of a variety of ways. For toll-free numbers, the most sophisticated and secure is probably via Delegate Certificates. SOMOS, the North American Toll-Free Number Administrator, has commented about this in a current FCC proceeding: https://www.fcc.gov/ecfs/document/10605623514445/1 As the signer, there are other ways you could determine that the caller is authorized to use the number. For example, you could solicit some documentation from them (like an invoice from their RespOrg and/or service provider) and you could call the number and verify that your caller answers. The regulations (today) do not specify exactly how you ???know??? so you (as the signer) need to act in the spirit of the rules. This problem is not unique to toll-free numbers. I might have a geographic number that I obtain from provider A (and that???s how I get inbound calls to the number), but I make outbound calls from that number via providers B and C for redundancy and cost reasons. Bear in mind that providers can set their own rules for what calls they will accept and what attestations they will assign, and those rules can be more restrictive than what might be dictated by regulation. For example, a provider might say ???I will only assign A-level attestation to calls that use calling numbers assigned by me.??? That???s their prerogative. In fact, a provider might say: ???I will only accept calls that use calling numbers assigned by me. Those calls will get A-level attestation. I will reject all other calls.??? There are no rules (to my knowledge) that prohibit providers from setting these kinds of rules. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Ivan Kovacevic via VoiceOps Sent: Friday, July 7, 2023 7:27 AM To: Voice Ops <voiceops at voiceops.org> Subject: Re: [VoiceOps] STIR/SHAKEN warning! Hopefully on-topic. How are you handling TFN atestations? Although a part of NANP - it's a different technology at the network level in terms of chain of authority and routing. RespOrg manages the number, but can provision and use many carriers to make outbound calls using the TFN Caller ID (and to receive inbound calls via the same TFN)... RespOrgs is not necessarily a carrier - who and how checks that RespOrg has the authority in case of delegated attestation. I may be overcomplicating it in my mind.. but it doesn't feel like the regulation maps 1-to-1 over to TFNs... Just wondering what everyone's experience is. Thanks, Ivan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops nt-family:"Calibri","sans-serif"'> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1