Flowroute and TN-Validation

FreePBX Providers
1

I have a small FreePBX system for my SOHO. Flowroute is my provider.

The other day I implemented a feature to extract the verstat TN status for each incoming call and send that information to me.

Over 90% of the incoming calls show “No-TN-Validation”.
These calls include numbers that I know are legitimate, from carriers such as Verizon Wireless, AT&T, Frontier and Google Voice.

I asked Flowroute and their response was that parts of the PSTN have not been modernized and when a call traverses that part of the network then the TN Validation is lost. I have not been able to independently verify this.

Has anybody else experienced something similar?

Is anybody capturing the TN Validation data yet?

I’m looking to use this information as an additional data point for dealing with spam calls and in it’s current form it’s worthless!

2

STIR/SHAKEN is for carriers and for only IP. There are still some carriers still using TDM.

This is not a method to catch spam calls. It only verifies the callerid presented to you belongs to the originating carrier. It does nothing that involves the reputation of the number or the content of the call.

This means a warranty scam call can show as verified while grams old phone network shows no verification.

3

I’m aware that “verstat=TN-Validation” does nothing that involves the reputation of the number or the content of the call. Scammers can call using numbers that they own and are authorized to use. No issue there.

It is simply a tool.

However, it is not useful as a tool if the attestation does not somehow make it through the system to the end user. If I get a call from 800-829-1040 and the verstat value is “No-TN-Verification” then how do I know if it is really the IRS calling me or not?

If I call from one of my Flowroute DID’s to another then the number is verified. Calls from major carriers, such as Verizon, AT&T and Frontier do not have any verification.

The question I am asking is if others are experiencing an issue with calls from known, legitimate callers not being verified? (“verstat=No-TN-Verification”)

I’m also asking if anyone can confirm what Flowroute told me: that parts of the PSTN between carriers, such as from Verizon to Flowroute, are not updated (legacy) and are stripping off the verification?

4

Don’t worry about the IRS thingy unless your under their microscope already.

https://www.taxslayer.com/blog/did-the-irs-call-me/#:~:text=Typically%2C%20the%20IRS%20will%20only,to%20contact%20you%20by%20phone.

As to major carriers not being yet compliant with shaken/stir, best I have seen is that they are still " working on it . . . "
:

5

LOL! As someone that is old enough to have received real “Nigerian Prince” letters delivered via the U.S Postal system, calls from any agency at all are greeted with a raised eyebrow and a quick decision if I have the time or inclination to screw with them or if I’m simply going to ignore them.

That’s pretty much what I figured. :confused:

6

It is not for end users. Places like Flowroute, BulkVS, et al. have wholesale and bulk customers that run their own setups. Because of this they pass it through. This is very basic at its core.

CallerID number owner by originating carrier = A level. ATT number calling you through ATT.

CallerID number belongs to another carrier but the originating carrier trusts you as a client = B. Using a Flowroute number over BulkVS.

TDM, smaller than 150K lines (not required) and International are non verifiable = C or no rating.

This is part of the traceback policies used. You need a SIP system that will let you grab these headers and parse them. Since most systems/devices looking at PAI headers are doing so for callerid it breaks callerid.

For example; Asterisk will use the PAI headers, if set, to populated the callerid fields. So while you are looking at the PAI header for validation you will also need to clean up the CallerID format or the number/user part will contain the the validation tags.

So enabling these headers breaks the standard use of systems/devices as a callerid source. Without cleaning it up it will cause issues with call experiences.

7

When I call someone using a Flowroute trunk and a number that I own and has been properly ported into Flowroute, then Flowroute should sign it with an A-level attestation and pass that on the the destination carrier. In theory, then the destination carrier would let the recipient know that the number is “validated”, such as by placing a green checkmark next to the number. Or something stupid like that.

When a Verizon Wireless customer calls me from their cell phone, VW should be signing it with an A-Level attestation and Flowroute would verify the signature and signal that information to me with the verstat parameter in the PAI field. (STIR/SHAKEN methodology with Flowroute)

However, what is happening is that over 90% of callers, including Verizon, AT&T, Frontier and Google Voice, have the “No-TN-Validation” indicator. A very few, including when I call from one of my own Flowroute DID’s, do get the “TN-Validation -Passed” indicator. Have not yet seen a “TN-Validation-Failed” but I’ve only been collecting this data for a week now.

With such a high “False-Negative” ratio, the validation is worthless and provides no useful information whatsoever. It would be like if your Radar Detector only went off for 10% of the radar guns you passed. You wouldn’t even bother with it.

8

Nothing YOU can do about that apart from complain to Flowroute, the attestation is negotiated purely between them and the underlying carrier.

You just get to see the result.

9

Exactly! When I asked them they blamed the PSTN backbone, which may be accurate.

I was just wondering if anybody else had observed the same thing or if they could confirm what Flowroute told me.

I just realized that my Verizon iphone call-history has a teeny-tiny faint grey checkmark placed next to numbers that have “been verified by the carrier”. The scam callers do not have that checkmark but the legit callers do. When I call from any of my Flowroute numbers I don’t see any indicator on the incoming call screen, but they are checked in the call history. I’ll have to pay closer attention to the incoming call display for the scammers to see if there is something there.

I don’t see anything similar on my Android phone.

More testing and research to do!

10

I did. I told you pretty much how this works. Again, not for end users or line subscribers.

You are now falling down the same rabbit hole that many “power users” have fallen into over the last 8 months. They thought that because certain bulk/wholesale carriers were passing the final results they could really do something with it. Turns out, not as much as they thought. Let me help you with your research.

STIR/SHAKEN was a result of the work around the TRACED Act (active in Dec 2019). These are all part to combat SPAM/robo calls that have climbed through roof. Now STIR/SHAKEN involves security tokens, TLS signatures and all that good stuff so it must be done over IP. The originating carrier must sign the call with a validate certificate and token that has been provided to them. I spent almost 8 months going back and forth with the FCC, compliance consultants and even the STI-GA/PA’s to verify what I needed to do to be in compliance.

As it stands right now, carriers that have TDM networks can’t do digital signatures and add headers. There are numerous rural and small carriers that are still 100% TDM. There are major carriers like ATT and Verizon that still have big portions of their network on TDM (though they are moving fast to kill that). Finally, any carrier that is IP but less than 150K lines are not required to do STIR/SHAKEN at this time.

A little context, I would say that right now roughly 20-25% of the calls still hitting the PSTN are from TDM networks. Right there, up to a quarter of the calls already don’t need to be signed. Then you get down to the under 150K, which there are quite a few of around the country, so now that 25% is up to 30-35% (roughly). Then, of course, you have calls from outside the US that probably through another 10% or so into the mix. Now you’re at roughly 35-45% of the calls going over the PSTN that either can’t sign calls or have no requirement to sign calls.

Now your silver lining there is that the 150K limit is going away by June 30, 2022. So small operating carriers will have no choice but to start signing their calls. This means more signed calls will appear. As well August 2nd 2022 is the deadline for many carriers like ATT and Verizon to turn down their TDM portions of their network. This will have a wide reaching impact as all the CLECs that use incumbent networks are forced to do the same.

Soon the only TDM based networks will be non-competitive incumbents that haven’t made a single innovated move in decades. Even then, the FCC has them in their sights in the near future. TDM is not something anyone wants anymore.

So again, STIR/SHAKEN is a method of CallerID validation to help combat CallerID Spoofing which is highly related to robo/spam calls. It is something that the carriers, the FCC and FTC can use as part of the traceback process for finding bad actors based on reports that have been filed.

Earlier this year the FCC, since it’s a public body, released the reports of three providers that violated all this. In one instance the calls traversed three different carriers from the originating caller to the callee. Because, as I’m sure you know, not every calls is a single straight A-to-Z connection. Sometimes calls have to go through a middle carrier or two because carriers A and Z don’t have a direct relationship.

You are going to find that a lot of calls aren’t signed yet and that signed calls don’t mean anything outside of “we vouch on the callerid”. Getting a full “A” level call can still end up being a car warranty scam, while “B” or “C” can be legit calls.

11

Thank you for the information. It agrees with my understanding and provides a some details I did not have before.

I am aware that STIR/SHAKEN is a carrier-level protocol that we mere end-users do not participate in. I disagree however, with your assertion that it is not for the “end-user”, e.g. the PBX operator.

The carrier really cannot make much use of it because they are just the carrier.

Even once STIR/SHAKEN is fully implemented as envisioned, as you correctly point out, it’s value is still limited. It is only a single piece of information, not useful on it’s own. The A/B/C attestation is however, useful to the end-user as an additional data point than can be plugged into an overall plan.

Much like SSL certificates and your browser. It is useful for my browser to alert me that a certificate does not match the domain or has other issues. I can then, using additional information that I have but the browser does not, make a decision.

12

The carriers developed this for their use. Considering it was designed to validate callerids and as part of the TRACED Act they very much make use of it. Also, wireless carriers are using this as well. They actually do use as part of their own verification services they provide their users.

Again, an A level call can be a spam/robocall. I’m not sure how that is an extra data point for blocking spam/robo calls. Which circles me back to this:

Correct, because not everything out there on the PSTN is a PBX. Not every call being received from the PSTN over a VoIP/IP connection is going to a PBX. Even more importantly, not every PBX out there will allow you to manipulate the headers they pull from for a certain piece of data. Some won’t even let you add custom headers let alone let you pull data from them.

You are using an open source PBX system that lets you do this. In the grand scheme of things, you are a percentage of the use cases out there. Not one of the higher ones, either.

13

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.