- 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:
- 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.
- 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.
- Finally, if the CNAM content from our content provider is either blank or the response is NULL, the CNAM will simply be “[V]”
- All other calls will have normal CNAM treatment.
- We do not block inbound traffic based on STIR/SHAKEN verification results.
- 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.
- Calls from TNs that a customer purchased from Flowroute, and are associated with that specific customer’s Flowroute account, should get attestation A.
- Calls from TNs other than those that a customer purchased from Flowroute should get attestation B
- Calls from a customer whose Flowroute account is in ‘Pending’ status will get attestation C
- Calls from invalid TNs (invalid per North American Numbering Plan) or with caller ID “Anonymous” will get attestation C
- We pass through, unaltered, any attestation we receive on calls arriving at Flowroute.
As is the case with inbound calls, we do not block calls based on a particular attestation level.
NOTE: Call routing information is carried by SS7 protocol when origination is not VoIP. Due to the way, SS7 is handled by public telephone lines, SIP headers cannot be sent to VoIP end users and will cause an unreliable check on a STIR/SHAKEN event. This makes the usability of the SS7 protocol specifically over the PTSN to VoIP problematic and often incorrect when analyzing for STIR/SHAKEN.