Just wondering, is it possible to modify an incoming caller ID name string based on the verstat parameter added to the P-Asserted-Identity header for calls verified using STIR/SHAKEN? For example, prepend the name with [V] or something similar for verified calls, e.g. [V]SMITH, JOHN. Or conversely, indicate unverified calls.
Is this possible? It would be a really cool feature as STIR/SHAKEN use increases.
STIR/SHAKEN is not an end user service/feature. It is meant for actual Operating Carriers, the fact many will pass this along to their wholesale partners is a curtesy to those partners. Non-IP carriers do not use STIR/SHAKEN, Operating Carriers with less than 150K lines are not required to use STIR/SHAKEN at this time. STIR/SHAKEN is also not a SPAM/Fraud solution, it is a piece of the puzzle. You can still get a spam call with an A level attestation.
Right now you would have to send calls to a custom context that grabbed the user portion of the PAI and parsed it out to get those details and do something with them.
My understanding is that it is very much an end user service, as far as consuming the information is concerned, and that the SHAKEN part refers to forwarding information over non-IP networks.
STIR/SHAKEN verifies that the call originating from Bandwidth is presenting a callerid that Bandwidth verifies as trusted (currently that means a Bandwidth number). Bandwidth will sign that call and give it an A level. If I use an Onvoy number, they will sign the call and give it a B. It gives the terminating carrier a validation of the callerid, not the caller themselves or the context/content of said call being made.
In order to participate in STIR/SHAKEN, that is to sign and validate calls yourself, you must be an active 499A filer with the FCC and have an Operating Carrier Number. Otherwise the only part of STIR/SHAKEN you’re involved in is before and after the fact of STIR/SHAKEN. You need a third party to do the signing and validation for you.
This is also being looked at through the lenses of “I have an IP PBX” which is not always the case. I have customer that have FXS devices for their use of service. How will me giving them STIR/SHAKEN headers matter? A) They have analog devices. B) What are they going to do with that information? What should be happening in this case is, as their provider, I should be using STIR/SHAKEN plus other services like RoboCaller Mitigation, checking fraud/spam databases, number reputation, etc to provide a more complete service and tag the [V] or whatever other indicator I want on it.
As I have said in other threads and other places, relying completely on STIR/SHAKEN is a poor decision. You could receive a “get a car warranty” call with an A level attestation because the callerid belongs to the originating carrier, while mema’s call gets a B or nothing because the callerid didn’t belong to the originating carrier or the originating carrier isn’t using STIR/SHAKEN because they are small or non-IP.
So I’m not sure how this is for end users when a huge chunk of them won’t being able to do anything with that data or those headers because they aren’t using an IP-PBX. Additionally, the end users can’t participate in it. This is why even Kari’s Law and Ray Baum’s where agnostic about things. They knew IP-PBXs could do way more but since they aren’t the only types out there, they made it more even for the market fields.
Right now, I can’t do my own STIR/SHAKEN because I lack the OCN part but I had to submit to the RoboCaller Mitigation Database in order to continue to be able to complete calls to the PSTN. Part of that was agreeing to trace back compliance and other tracking/reporting methods. Since September 30th three VoIP carriers were issued warnings due to reports from consumers and the results of tracing the call back through multiple carriers to the originating source. They had 30 days to clean up the bad call actors or all their downstreams (underlying carriers) would be ordered to block their traffic.
Thanks @david55 and @BlazeStudios. I know that STIR/SHAKEN is by no means a panacea for ending robocalls and other undesirable calls. I was simply wondering whether FreePBX can do anything with the “verstat” parameter in the PAI header, which my carrier passes along. It seems the only way is via a custom context and code. I might play with this further at some point, but not for now…
Thanks!
Well if you use a PJSIP trunk and are on later versions of 16 (or any of 18) trusting the inbound callerid will pull from the PAI header meaning the callerID number will be +1NXXNXXXXXX;verstat=TN-Validation-Passed so you will need to look for and parse the CALLERID(num) variable to strip that out.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.