stir/shaken support
- Thread starter mrjoli021
- Start date
- Status
going to bump this -- end of june service providers in the usa will need to be sending it per FCC mandate, so we should at least get inbound verification coded in...
From my understanding the requirements apply to interconnected service providers like Bandwidth.com, T-Mobile, or Verizon.
If you are a hosted voice provider just managing phones and get your dialtone from someone like Bandwidth.com, they will take care of all the STIR/SHAKEN stuff and send you the results in the SIP header.
This article has a good explanation of how it will work for Bandwidth.com customers.
I think we'll be able to do some cool stuff with this new SIP header though.
You could modify the Caller-ID and add "Verified" or "Unverified" to the name. Or you could create dialplan rule that allows verified callers through, but sends unverified callers to an IVR.
If you are a hosted voice provider just managing phones and get your dialtone from someone like Bandwidth.com, they will take care of all the STIR/SHAKEN stuff and send you the results in the SIP header.
This article has a good explanation of how it will work for Bandwidth.com customers.
I think we'll be able to do some cool stuff with this new SIP header though.
You could modify the Caller-ID and add "Verified" or "Unverified" to the name. Or you could create dialplan rule that allows verified callers through, but sends unverified callers to an IVR.
While I agree that filtering via SIP headers provided by bandwidth would be an easy solution, not everybody uses Bandwidth and different carriers will have different solutions
I view the best way to do what would be build in the spec so that we can fully decode it on our end versus having to rely on another service provider. Y
I view the best way to do what would be build in the spec so that we can fully decode it on our end versus having to rely on another service provider. Y
Last edited:
Late reply but not all append the caller id. The other issue is that most calls will be B level attestation calls that are legitimate and partially verified. C level attestation calls are unverified and those are the ones that need to be sent to the IVR. A level calls will show as verified in the headers, C level will show as unverified. B level calls are partially verified in that the outgoing CLEC knows you but does not recognize the CID you sent since they do not own that DID. For one of my SBCs, BulkVS, I had to fill out a form and tick off boxes as to how I would and would not use their service so I get B level attestation because they do not handle my DIDs yet now I am legally bound by the form I filled and signed so any abuse by me and they have legal recourse.
freeswitch now has libstirshaken built into it so it will do the heavy work of decoding and verifying the certificates for verification, so, anything bought into FusionPBX would be a bonus. Right now I'm using lua to base64decode the string and then inject that into my spam system.
Also, we are getting a ton of unattested calls that come "from the ILECS" because SS7-originated calls doesn't have to send stir/shaken.
Also, we are getting a ton of unattested calls that come "from the ILECS" because SS7-originated calls doesn't have to send stir/shaken.
I noticed that too in my case, otherwise I see A, B, or C level attestation applied. Since the PSTN is starting to go away now and is supposed to be globally phased out by 2030, will the ILECS simply stay in the game and use VOIP, do they use some VOIP already?
I should also acknowledge that Stir/Shaken is a USA construct as of now. I cannot verify this but it has been said that the EU is watching to see how it works here and has plans to implement it or something like it that suits their needs. Perhaps someone from across the Atlantic can educate us on this?
- Status