Where should I implement STIR / SHAKEN in my network?

Unless you have been hiding under a rock – and admittedly there are an awful lot of large distracting rocks that you could be hiding under right now - you should be aware that there is a requirement for all voice service providers to implement STIR / SHAKEN in the IP portions of their networks by June 2021 in the US and September 2020 in Canada.


But what does it mean to implement on ‘the IP portions’ of your network? In this post, I will explain how we interpret this at Metaswitch, the recommendations we are making to our customers and the rationale behind it.

Where is there IP on my network?

There are potentially several different parts of your network that could be considered IP capable.


Using this picture as a somewhat simplistic guide, you could have IP at any of the following places.

  • Between your customers’ phones and your switching system, e.g. if the customer is using a VOIP phone registered on your IP softswitch.
  • Between your switching system and the edge devices on your network. You could be talking SIP to a network-side SBC. Or, if your telephone switch does not support IP, then you could be talking (non-IP) ISUP to a gateway (or gateway controller) and then SIP to an SBC.
  • Between the network edge and the PSTN. If you have SBCs at the network edge, then you are talking IP to the PSTN.

No two networks look the same, and in talking to several customers about options to deploy STIR / SHAKEN, I have seen all the combinations you can imagine.

For example, some of our larger customers have several different switching networks including legacy Class 5 switches (for some of the older parts of the fixed residential network), IP softswitches (for some of the newer parts of the fixed network, e.g. in a metro area) and an IMS network for their wireless operations. In this situation there is a tremendous mix of IP and non-IP throughout the network.

Many of our smaller rural customers have done a great job of modernizing their networks to IP and have consolidated their voice operations down to a single IP softswitch and SBC. They would love to retire their network-side TDM trunks, but cannot because they can obtain only TDM interconnects in their markets, so continue to maintain a gateway for those interconnects.

A little bit of trust goes a long way

That’s quite a lot of variation between networks, so how do we determine where to enable STIR / SHAKEN?

Firstly, let’s not forget that STIR / SHAKEN’s primary purpose is to provide trust to Caller ID, the caller’s identity. If you read the ATIS standards in this area, the thrust of the language is about communicating trust between different service provider networks, i.e. one network asserting and authenticating the identity of the caller and another network verifying it. In other words, while you should be able to trust the identity of calls originating on your network, you can’t trust those originating on other carrier networks (and they can’t trust yours!).

Secondly, the whole process of signing and verifying calls with STIR / SHAKEN involves a cryptographic operation to securely create the digital signature at the originating carrier (signing) or securely verifying the signature at the terminating carrier. Cryptographic operations involve intensive algorithmic computation and so there is no getting around this taking a few milliseconds. Bearing in mind that we always want to keep post-dial delay as low as possible, then we should carry out this operation only when absolutely necessary.

Taking these two together leads us to recommend that calls are signed and verified as close to the network edge as possible, ideally from the SBC sitting at the edge of your network. This means you are only signing and verifying calls that leave your network, so not introducing a delay (albeit tiny) for on-net calls. It also simplifies deployment – it doesn’t matter how complex your internal network is and how many different protocols it is talking, you have a well understood point in the network where the signing and verification happens.


Of course, this may not necessarily be the direction that you want to go. You may have your own reasons why you want to sign and verify on-net calls, i.e. calls that are both originating and terminating on your network. But there is no regulatory requirement to do that, and there are standards-based mechanisms to signal the trust of those calls within your network using ‘tags’ without having to go as far as full STIR / SHAKEN signing. I’ll talk about this in my next STIR / SHAKEN blog.

For more, please visit our robocall blocking solutions page; customers can read more on our Call Guardian Authentication Hub Communities pages.