[VoiceOps] STIR/SHAKEN for call centers

Patrick Labbett patrick.labbett at gmail.com
Thu Dec 3 12:53:18 EST 2020

Thank you Glen and Paul, much appreciated!

On Wed, Dec 2, 2020 at 5:19 PM Glen Gerhard <glen at cognexus.net> wrote:

> Sounds like a good plan to me. It might help to figure out a few test call
> paths to verify the verstats directly.
> IMHO much of the S/S technology will be overshadowed by the analytics
> providers in terms of call presentation/blocking.
> That said, S/S will be helpful to law agencies in tracking malicious
> intent groups. This alone makes it worth the effort. A lot of the work
> /benefit takes place at the vetting of corporate ownership. S/S also
> provides Rich Call Data which replaces the pathetic CNAM.
> The Delegated Certs extension will help with the call center attestations
> but is still a ways off. Then you need your SBCs and PBXs to support it.
> SIPNOC is next week and it's usually helpful.
> https://www.sipforum.org/news-events/sipnoc-2020-overview/#topics
> ~Glen
> On 12/2/2020 1:49 PM, Patrick Labbett wrote:
> Hello, I'm looking for guidance/feedback on the impact of STIR/SHAKEN on
> the call center and answering service industries. Very few are
> interconnected VoIP service providers themselves.
> Specifically, customers of these industries often desire the call center
> utilize their company phone number when contacting their employees or
> customers for an improved end-user experience.
> The worry is that STIR/SHAKEN will be implemented in a way that causes
> these "spoofed" calls (that have legitimate business relationships in
> place) to be marked as such or eventually blocked as STIR/SHAKEN tightens
> it's grip on malicious intent.
> Here is my understanding of the situation: As a customer of an Originating
> carrier, the Call Center's outbound calls will be signed by their
> Originating carrier's STIR/SHAKEN certificate - so as long as the SIP
> Identity header isn't modified in transit and the certificate is validated
> on the Terminating side, everything should continue to work normally for us
> as end users. So this is largely the carrier's problem, and not the call
> centers.
> However, it's not clear (to me) how the Attestation aspect of things will
> work (and if it even effects the typical customer):
>    - Does just being a customer of the Originating Carrier give the Call
>    Center's calls Full Attestation?
>    - As a call center, if spoofing a number not owned/in inventory, would
>    that be Partial Attestation?
>    - Does the owner/location of the spoofed number matter, i.e. :
>       - Partial Attestation: Number owned by Originating carrier, but not
>       by customer making call
>       - Gateway Attestation: Number not owned by Originating carrier (and
>       by extension not owned by customer making the call)
>    - Will different Terminating carriers treat Attestation designations
>    differently?
>    - Is this largely a framework that carriers will implement some day in
>    the future?
> Am I way overthinking this? (Yes.)
> Thank you in advance for any perspective you can offer, or resources you
> can direct me to.
> My personal plan of attack for call centers:
>    - Document permission and business use case for numbers spoofed on
>    behalf of customers
>    - That's it - that's the whole plan.
>    - ????
> Aside from making sure my carriers know I exist and that I have permission
> to use those numbers, what else is there?
> -Patrick Labbett
> _______________________________________________
> VoiceOps mailing listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
> --
> Glen Gerhardglen at cognexus.net
> 858.324.4536
> Cognexus, LLC
> 7891 Avenida Kirjah
> San Diego, CA 92037
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20201203/01038707/attachment.htm>

More information about the VoiceOps mailing list