Question:

ECG said on a webinar that carriers must use STIR/SHAKEN on calls between their customers within the same network. Is this true for carriers that only have one switch and obviously know that a call from one customer to another customer is legitimate? All of the lines on the switch are using SIP to Fiber-to-the-home VoIP device (ONT) and regular POTS on the customer side of the ONT. We don't believe this network could be used to generate a nuisance, fraud, or robocall. How do we use SHAKEN/STIR in this network?

Answer:

The FCC requires Voice Service Providers to track and tag calls internally to its own network, "in a manner consistent with the STIR/SHAKEN framework." (35 FCC Rcd 3241 (4), Paragraph 34) Remember: As Service Provider, my big goal is to know where any given call originated, and to be able to give an A-level attestation ("the highest level of trust," from the TRACED Act) to every call I send out to the PSTN when that call is placed by a user that has the authority to place calls from the number they used.

If I'm doing SHAKEN/STIR signing at basically one point in my network -- the place where I send calls out to the PSTN -- then I need a way for that point in the network to know that the calls were being placed by a user who had the right to use the number.

A Simple Case and a Complex Case

In the simplest case, I might have a single Softswitch/application server (AS) that performs user authentication and blocks all calls from unscreened (i.e., unverified) telephone numbers placed by customers and doesn't do any call forwarding. Because of the policies/configuration in place on that AS, I might be able to say that every call that it sends to the PSTN deserves an A-Level attestation, so by virtue of that AS sending calls to my Signing SBC, the Signing SBC might reasonably be configured to add an A-level attestation to those calls. (Note -- There are a lot of provisos and caveats on this situation!)

But in a more complex case, I might have multiple SBCs, or multiple application servers, or call routing servers, through which calls may route. If I don't have a way to track the call back to the originating, then by the time the call arrives at the STIR/SHAKEN signing device, I might not have confidence about precisely where the call originated. In a case like that, I need to do something more. Austin Spreadsbury of Metaswitch has a nice article about tagging calls where he dives into the Attestation-Info and Origination-ID.

What about my ONT / POTS Device?

A voice provider with a single switch or Application Server (AS) might not have a true "intra-network" network in which to implement SHAKEN/STIR or even a way to do tagging. An ONT -- or even a large POTS gateway like a Zhone MXK -- could qualify as a customer-side access device, not as an interior component of the IP portion of the service provider's network, as long as the Application Server (AS) performs authentication to confirm the identity of the original caller. The POTS device more like a VoIP phone -- a User-Agent than it is like another switch -- and there's no expectation that User Agents would themselves participate in SHAKEN/STIR tagging, verification, and attestation.

When is Intra-Network SHAKEN/STIR Required?

The FCC rules talk about "intra-network" consistent with SHAKEN/STIR. The October 2020 NPRM summarizes and explains the intra-network requirements --

61. Intra-Network Calls—An Extension Would Be Counterproductive. In the First Caller ID Authentication Report and Order and Further Notice, we established distinct authentication requirements for inter-network calls and for intra-network calls. In the case of inter-network calls, an originating voice service provider must “authenticate caller [ID] information for all SIP calls it originates and that [it] will exchange with another voice service provider or intermediate provider.” Because establishing trust between providers is not necessary for calls that transit a single network, we adopted a different obligation for intra-network calls that solely transit the network of the originating voice service provider. Specifically, in recognition of the fact that “certain components of the STIR/SHAKEN framework . . . are not necessary for calls that a voice service provider originates and terminates on its own network,” we concluded a voice service provider satisfies its intra-network authentication obligation so long as it authenticates and verifies “in a manner consistent with the STIR/SHAKEN framework, such as by including origination and attestation information in the SIP INVITE used to establish the call.”

(The FCC is quoting from the March 2020 Report and Order.)

But Robocalling / Fraud Calling Is Still Possible From POTS

How can robocalling, or fraud, or nuisance calling be produced if the customer is connected via POTS? Even if you know your customers, the customer's equipment could generate a fraud call or robocall if the customer has an IP-accessible system that can be attacked by a bad actor via the Internet. For example, if their POTS line is connected to a PBX that can be attacked through the Internet, then the calls could be placed through that POTS line out to the Internet.

So, where do I need to implement intra-network tagging or labeling?

If the technology allows you to verify the origin of the call back to the customer from which it originated, then I'd expect it satisfies the goal of authenticating and verifying in a manner consistent with the STIR/SHAKEN framework.

But if you have some portion of the network where the certainty of the chain of information from the calling device to the signing device breaks, so that you can't be fully confident that you know the origin of the call, then you need to look at tagging as Austin Spreadsbury discusses in order to retain the data through to the end.

ECG provides this technical information for general information only. It is not legal advice.

200 OK Q&A: Do I need SHAKEN/STIR on a simple network? Understanding Intra-Network Tagging