Simple How-To on removing STIR/SHAKEN?

[SkinnerVix]

Hello All,

As you may be afflicted with being short-staffed, I don't have the time to sink a couple hours into debugging what variable and string I need to put together to get my staff to stop crying about the verstat validation screwing up their redial, CID display, etc. You folks have a down/dirty guide for removing this from a Flowroute Trunk? Yes, I saw the "solved" article, but the resolution was it magically resolving itself (which is the non-solution). Can someone save a brother some time here? Here is the Methodology from their support (FYI, their standard response is contact the PBX for stripping the crap off):
____________________________________________

STIR/SHAKEN methodology with Flowroute​

For inbound calls to customers, our current plan is to provide both of the following STIR/SHAKEN-based insights:

1. TN validation info via the ‘verstat’ tel URI, a parameter in either the P-Asserted Identity (PAI) header field or the FROM header field. This parameter will contain one of the following 3 values denoting the result of a TN validation check:
   1. TN-Validation-Passed
   2. TN-Validation-Failed
   3. No-TN-Validation
2. If we get a "TN-Validation-Passed” result in the verstat, we will prepend “[V]” to the CNAM, right-truncating CNAM if the addition of “[V]” causes the 15-character limit to be exceeded.
   1. For calls that have the above-mentioned verstat result, we’re also putting logic in place that will overwrite any CNAM content that originating networks or customer’s PBX would supply, so that the pre-pended [V] doesn’t inadvertently communicate invalid/nefarious CNAM content.
   2. Finally if the CNAM content from our content-provider is either blank or the response is NULL, the CNAM will simply be “[V]"
   3. All other calls will be have normal CNAM treatment.

A couple of additional comments regarding inbound calls:

1. We do not plan to block inbound traffic based on a STIR/SHAKEN verification result at this time
2. The spirit of offering both (1) and (2) together is to allow customers who can handle/parse SIP headers to apply their own treatment, if they so choose, while also providing for others who cannot; the CNAM-based approach solves for a large variety of end-customer-device restrictions without the need for service providers to individually do so.

For outbound calls from customers, generally speaking,

1. Calls from TNs that a customer purchased from Flowroute, and are associated with that specific customer’s Flowroute account, should get attestation A.
2. Calls from TNs other than those that a customer purchased from Flowroute, should get attestation B
3. Calls from a customer whose Flowroute account is in ‘Pending’ status will get attestation C
4. Calls from invalid TNs (invalid per North American Numbering Plan) or with caller ID “Anonymous” will get attestation C
5. We will pass-through, unaltered, any attestation we receive on calls arriving at Flowroute.

As is the case with inbound calls, we do not plan to block calls based on a particular attestation level at this time.
___________________________________________

Thanks,
Mark

 

[YiannisH_3CX]

Hello Mark,

Its more simple that you think. If you use the 3CX default template with the settings provided you do not need to do anything. The STIR/SHAKEN validation is sent to the P-Asserted-Identity value which does not affect where the PBX reads the caller name and ID from.
If the call is validated a [V] is included in the FromisplayName in front of the callers name and not the number. The PBX will read that as part of the name but the callers name should still be visible and the number for callbacks is not affected. So given you are using the default template you should not have any issues .

Also disabling it is not possible from the PBX side since it is something added by the provider and since all US providers will be using STIR/SHAKEN in the immediate future we need to get used to it.

If you are having issues however with the PBX settings and you need some assistance you can always contact a 3CX partner to assist you.

 

[SkinnerVix]

We're a little behind, running 15.5. Is that available (template wise) on that release or will an upgrade be needed. If not, just hose the SIP trunk and refresh it, or do you have some suggestions on best path/practice to make that happen?

Thanks,
Mark

 

[YiannisH_3CX]

I would recommend upgrading to the latest stable version which currently is V16.0.8.9 as the updated template is not available for V15.5 and to take advantage of future updates which V15.5 no longer benefits from.
Just make sure you are on the latest V15.5 update and you can directly update to V16.
If you are running Debian and you are still on Debian 8 I would recommend taking a backup of the system, save it to an external source and then upgrade your OS and reinstall the system using the backup. For Windows make sure you are running a supported Windows version and the procedure is the same. Make a full backup, save it somewhere safe and then uninstall V15.5 and install V16 using your backup.
Once you are on V16 you will need to rebuild your trunk with the included template.

 

[SkinnerVix]

Good Info there. Does the path, now that you are in V18 RC, end up being the same: 15.5 ->16 ->18 or can I jump from 15.5 to 18? We usually like to do every other just as a time expediency thing. I'm pretty sure we'd roll the Debian 10 ISO if we're going to take the time, not to do it again soon.

 

[YiannisH_3CX]

The path is 15.5 to 16 and then to 18. You shouldn't keep a version to void any issues with the backups. If you want to upgrade to V18 I would recommend waiting for the final release to come out. We are pretty close.

 

[SkinnerVix]

OK, with that in mind, I'm thinking about the best path. I'm in v15.5 Windows, my ultimate destination is V18 Debian. So, to get the new template proper, do the backup, uninstall, install V16 and restore. Then, lather rinse repeat on Windows to V18 then make the jump with restoring a backup to the Linux or is there a better stop somewhere along the way? At what point do I pull the SIP Trunk in the backup/restore context as to lessen opportunity to screw things up (like pull it from the start, etc)?

 

[YiannisH_3CX]

You can switch to Debian at any time in the process. If I was doing it my self then I would upgrade to V16 on Windows and once the time came to upgrade to V18 I would switch to Debian 10. The backup will work between the OS versions. So you will have your V16 backup from Windows and then restore it to your V18 Debian installation.

A note here, when you are upgrading you need to import your backup during the installation process and not after the installation is complete.