[VoiceOps] STIR/SHAKEN for call centers

[Patrick Labbett]

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>