STIR/SHAKEN — How to Stop the Robocalling Madness

FCC Robocall Blocking Updates

More recently, on the other two fronts here is that the FCC further came out with a green lighting of default robocall blocking. That was on June 6th of this year. And that introduces some interesting areas that we'll explore in more detail during this webinar.

The interesting thing that this does open up is the discussion of where we started with illegal robocalling and illegal spoofing and such, has now kind of opened up into all bets off to pretty much any type of robocall, spoof or, annoying call, and giving some safe harbors and the abilities for carriers now to offer default robocall blocking on an opt out basis. So that actually introduces another requirement for carriers looking to support that.

And then, lastly, on this slide and the legislative front, is the fact that there are bills progressing to the point now where there's a joint senate and house bill being drafted and then some compromises across these. But I think that the bottom line here is that we're looking at a potential bill going in front of the president, perhaps as early as September of 2019, which will also include some mandates around some co-authentication and so forth around the robocalls.

So from a regulatory and legislative perspective, things are really marching forward. And let me turn it over to Rahm on the actual FCC summit, which was just last week.

Thanks, Ken. Thanks everyone for joining the webinar today. I'd like to take a couple of minutes to talk about the FCC summit that happened last week. Ribbon and Neustar were part of the summit. The FCC invited Ribbon to be part of the panel, which we are thankful to the FCC for, and to Eric Burger the CTO of the FCC as well.

Again, the purpose of the summit was for everybody, all the stakeholders, to understand the status or the progress made in terms of STIR/SHAKEN implementation by the different carriers, the large carriers, the MSOs, the smaller carriers. You know, what's the status and progress made to date? And what are some of the challenges that they are facing?

All of these carriers or some of these carriers have gone through — or some of these carriers have gone through the ATIS test lab that our partner, Neustar, runs the test lab. A lot of the carriers have gone through the test lab. Some of the carriers have done interoperability tests among themselves. So what are some of the challenges, early challenges, in terms of implementation that they have seen?

And what are some of the best practices that they've used to overcome these challenges? And this is where the carriers, and the vendors, and the standards body come together to kind of recommend best practices so that the carriers that follow don't face the same issues as the carriers that have already done some of the testing and implementation. So that was kind of the purpose of the meeting, of the summit, was to check on progress, and to look at implementation challenges and recommend best practices.

Have Major Carrier Implemented STIR/SHAKEN?

There was a keynote by the FCC Chairman. And there were three panel discussions. And each one was for a different segment of the audience. The first one was for the major voice service providers. These are the tier 1 wireline and wireless providers, and MSOs as well.

The topic there was, what is the progress made by these major carriers? And some of these have already implemented STIR/SHAKEN. And what are some of the challenges that they have faced as they went through this process?

The second panel was more of a consumer facing topic, where what to end consumers expect from co-authentication and robocall mitigation solutions? And there were consumer advocacy groups as part of this panel, which is a good thing to see, to hear the consumer voice as well. And the focus here was, how do consumers benefit from the co-authentication and the robocall mitigation solutions?

How Will STIR/SHAKEN be Adopted across the Industry?

And there were discussions about display technologies. How is the industry going to display caller ID, for example? Once STIR/SHAKEN is enabled and robocall mitigation analytics is enabled, how is the industry going to implement caller ID, or enhance caller ID, so that the end consumers can make an informed decision whether to pick up a call, or just ignore the call, or send it to voicemail, for example?

So there is a lot of discussion on the end consumer experience, from a caller ID perspective, and also from a call blocking perspective that Ken touched upon, based on the June 6 ruling by the FCC, that carriers can now block caused by default. So consumes can make use of that feature. And if they want to opt out of the call blocking, they will have the capability to do that on the carrier portal, or a web app, or something similar. So a lot of discussion on consumer focused notifications, consumer call blocking opt in capabilities, were discussed as part of the panel.

Challenges Facing Large vs Small Phone Carriers

The last panel, which ribbon was a part of, and I represented Ribbon as part of the panel, was the challenges facing the smaller service providers. These are the rural providers that have anywhere from 5,000, to 30,000, 40,000 subscribers. So they face a different set of challenges than the bigger players.

So this was focused on the very small rural carrier carriers that number in the 800 to 1,000 range. There are about 1,000 carriers around the US that are categorized as smaller voice service providers. So the problems of those carriers in terms of implementing the solution, and some of the challenges faced by them, were discussed in this panel.

So some of the key takeaways for people that either were not there in person, or did not tune into the webcast, the key takeaways from the FCC summit are as follows. So from the first panel, which is for the large carriers, the key takeaways were the FCC has set a milestone for the end of the year for implementation of STIR/SHAKEN, which is basically signing and verification of calls. A lot of the carriers that participated in the panel are well under way and tracking nicely towards the end of the year milestone for signing and verification.

In terms of attestation, there was some discussion of what attestation levels. Even though there is A, B, and C, A and B are the preferred ones based on the panel discussion. And we'll talk about what A, B, and C mean as we go further in this presentation. C is not preferred for now.

Obviously, there will be cases where C may need to be used, maybe for internationally originated calls, international gateway may attest as C for those calls. But, in general, A and B are preferred. And A is obviously the most preferred that the industry would like to eventually see.

The panel also looked at some of the evolving standards. So once we do the basic signing and verification, there are other things that are being discussed in the standards, such as TN delegation, where the carrier, for example, delegates the signing responsibility to an enterprise or a non-carrier. There were discussions about enhanced caller ID and enhance see name.

This is how we can really tell an end consumer whether it's a landline or a wireless end consumer. We can notify them on the validity of the call, or really who is calling them, so they can make an informed decision whether to pick up the call or not. Also, there were discussions about the policy administration framework.

So this has been awarded. The contract has been awarded. So the policy administration framework, which basically is this is the certificate management authority, the framework has being defined, and will be available by the end of the year, based on the panel discussions.

The second panel, the key takeaways from the consumer facing part of this topic, is, basically, it was focused on two aspects. One is the caller ID display. The display need to be really simple, give as much information as possible to the end consumer, while making it very simple for them to understand.

So that was the key focus here. There are many different proposals out in the standards bodies today on how to display caller ID in a standard way. So whether you're subscribing to one carrier to or another if the caller ID displays uniform and simple to read and understand, that will help end consumers make an informed decision. So there was a discussion on that topic.

The other part of the topic was on call blocking, which the FCC has made a ruling on June 6th that carriers can now block calls on behalf of customers. Customers will have the capability to turn that off. Or if they want to accept all the calls, they can do that. But by default, the preference is to turn on call blocking for customers. And that was a topic of discussion as well. And analytics will play a big role, in terms of call blocking that we'll discuss as we go along here.

Carrier Cost and Flexibility and Deployment Models

The last panel for the small carriers really focused on cost and flexibility and deployment models. So the small rural carriers, as I said before, range anywhere from 5,000 to 30,000 subscribers. So cost is certainly something that vendors need to consider. But also, the flexibility and deployment models, in terms of managing the solution itself, needs to be very easy and flexible.

So we'll talk about some of those challenges, and how to overcome those as part of this presentation. And also, by the way, TDM is still in play in some of these networks, not just the small networks, but in some of the larger networks as well. So we need to consider that as part of the solution when we talk about STIR/SHAKEN and analytics.

So that was kind of the high level takeaways from the FCC summit. With that, I'll turn it over to Ken to take us through some of the basics of the STIR/SHAKEN standards. And then we'll go forward. Ken?

STIR/SHAKEN Authentication Standards

Thanks, Ron, and we got to stop meeting like this. If you back up one, please. I just wanted to mention that again, on the call authentication front, we have got a set of standards now, shaken not stirred. We'll talk more about that. And as analytics has become more important, that still remains pretty much a fragmented marketplace that is spawning different levels of collaboration and such.

But the other blurring, you know, as we mentioned, the blocking of robocalls, that robocalls are not necessarily being distinguished as illegal or legal, or annoying, or nuisance type calls. The analytics and the use of STIR/SHAKEN are kind of being blended together as well. So next slide?

Just to provide some context for folks who may just be jumping into this, just to give you the foundation here, STIR is a set of protocols defined in the Internet Engineering Task Force. There are three key RFCs — well, there's several others. But there's three key for the basic functioning of STIR.

If you look at these, they're co-authored by Neustar. And this is kind of a second shot at this problem statement. So that's why the revisited piece.

These standards define a security token, a mechanism for signing that token, having it certified by an approved or recognized certificate authority, and then actually transporting the information in the form of an identity header on the wire in sit. The SHAKEN is really more of the framework and an architecture that defines a profile or implementation for the service providers. And we'll get into more detail around that aspect of it.

But it really forms the basis for end to end authenticating and verifying across traditional service carrier boundaries in the network. Really, the analogy that I think is closest is that we're looking at existing standards that are out there and applying them to phone calls, similar to the way we've applied those to securing financial transactions on the internet.

The phone network has become much more open to the internet. So we're applying those same kind of mechanisms to secure phone calls on as much of an end to end basis as possible. Next slide.

Call management layer

A good way of looking at this is really kind of a layered approach. What this shows is the three layers. There's a call management layer. And this is why most people talk about.

They just talk about the actual signing and the verifying of the phone calls. And that, really, is the real impacting aspect of this model for call time, and actual calls being placed, or coming into your network, or egressing your network. The second level is the key management layer.

Key management layer

And this is a set of functional components, again defined in the standards. And this is actually where you manage the digital signing, as well as the requests of being able to have an approved or recognized certificate authority sign your key materials so that you can actually be a recognized participant in signing and verifying calls in the ecosystem. Since we are in operation with several carriers, we're functioning at this key management layer, where the carriers are pretty much agreeing on mechanisms to allow signing, and verifying, and recognized certificate authorities, whether they're like self-signed by the carriers themselves or using a third party that is using a kind of pre-standard format of certificates, since the SHAKEN certificates actually requires some extensions and some other aspects to be fully compliant.

Governance and policy layer

Now, the new layer here is the governance and policy layer, which is now moving toward implementation from an actual ecosystem perspective. We do have a governance authority, which is a governing board. But the policy administrator vendor as being selected in May with a target implementation date of December 11th of 2019, and also a recent press release soliciting certificate authorities to participate in the approval process, and in this actual governance structure, for the US at least, just went out recently.

We're looking at an operational, or targeting an operational governance policy structure here toward the end of this year. That will require existing carriers to make some changes to adopt into that. But our joint solution supports both the key management with and without a governance and policy infrastructure in place, and gets much more complex when you add in the governance policy mechanism here.

As you can see, just to walk you through that process, there is a key element, the service provider key management server. That is an interface between the policy administrator and the approved certification authorities. The arrows there are indicating a three way handshake. So the first step in this process is that the service provider, which is operating these five green components, would be requesting a service provider code token using some identifier.

Typically, we think it's going to be an OCN or a SPID type identifier. They will request to get validated and approved to join the ecosystem through the policy administrator. Once that token has been assigned, that token then is embedded in a certificate signing request with your private and public key that you generate, or a third party generates.

And then it actually works through an automated interface as well, a different one then with the PA, but an interface for managing designing and validating of that certificate signing request. And then, ultimately, a signed certificate, and then as part of that process there's validations that are done between the CA and the PA. So that's complete the three way handshake there for providing the actual SHAKEN certificates that will be used in a more broader deployment model. Next slide.

OK, so we have now, to break things up, a little poll. As you know, there's been a lot of webinars, education seminars. So just to try to get a sense of that, we'd just like to get some read on the effect of this, or just your own involvement with STIR/SHAKEN and associated robocall analytics.

How Well Do You Know STIR/SHAKEN?

So if you could take a minute and take a look at this poll. We're looking for a different characterizations of your knowledge in this area. Do you view yourself as an industry expert, competent to architect a solution in your network, know enough to partner with a vendor to architect a solution, know enough to be dangerous, or still trying to sort some things out and kind of earlier in the game?

And then Lance, I'll let you close the poll when you think we have a sufficient amount of responses.

Yeah, we have about half the audience has voted at this point. So I'll give it another minute or two to get that out here. Just one moment. We're actually up to 60% now. So we'll give it a minute.

OK, sure.

I'll just take this time to remind everybody, please feel free to ask us whatever questions you may have, as we go through the material today. If we don't get to your question during the webinar, we'll certainly follow up. So just wanted to point that out again.

All right, Ken, about 75% have taken the poll. So we have the results being displayed right now.

OK. Probably not quite what I would have expected. But it is good to get this kind of feedback. Rahm, any comments? As I hand it over to you as well, you can respond on your thoughts based on the poll.

Yes, so same thing here, Ken, I would have expected more people to be on 3 and 4, as opposed to 5. But it's good feedback. I think for people that are still sorting things out, I think these webinars hopefully would be helpful. And we plan to do more of these. So that's good feedback. Thank you.

OK, so with that, let's get to the next section here. So, Ken, thanks for taking us through the standards activities and the different components that make up the SHAKEN framework. So I'll now get it to the next level of detail in terms of the joint STIR/SHAKEN solution between Ribbon and Neustar that we bring to the table here.

So I showed the STIR/SHAKEN framework components at the top that Ken just described, and was pretty articulate there. So with that picture, I'm bringing in the network components of the call processing components now. Typically, in a voice network, we'll have feature servers, gateways, SBCs, routing servers, and other network elements.

STIR/SHAKEN Protocol and SIP Networks

And talking to customers, and talking to industry folks, standards body folks, the key network elements that are involved in the STIR/SHAKEN call flows are the SBCs that really peer with other SIP providers. And as we all know, STIR/SHAKEN is really geared towards SIP networks, not towards TDM networks.

We'll touch upon the TDM network towards end of the call. But, really, STIR/SHAKEN protocol and framework is geared towards SIP networks. And SBC is is the right place for us to implement STIR/SHAKEN, in terms of signing and verification and tagging, in these SIP networks.

So as shown in the picture here, the Ribbon SBC is key to the STIR/SHAKEN framework. And the Ribbon PSX is really the centralized routing engine that does the signing and verification on behalf of the SBCs, among other things, like lease cost routing, and number of translations, LNP lookups, and so on. So the PSX is really the anchor for the call flow, in terms of providing that routes, but also signing and verifying the calls on behalf of the SBCs.

So it's really the two pieces of the puzzle, the call processing elements, which are the SBC and the PSX at the bottom of the picture, and the STIR/SHAKEN framework, the certificate authority, the authentication and verification server, at the top. These two pieces really come together in a nice way to basically sign and verify calls, and sets the framework nicely for extending it to an analytics solution of the future that really enables call blocking.

So that's how the two pieces of the puzzle work together across the two companies. And we've run quite a bit of interoperability testing across the two solutions. And we have joint customer testing going on currently with these two solutions.

Challenges Facing STIR/SHAKEN Framework

So that is how the two solutions come together. Now, let's look at some of the challenges that we are seeing in our testing with customers, and we are hearing from customers as well. And we'll look at each of these challenges, and also provide recommendations and best practices on how to overcome these challenges.

Minimizing network impact during implementation

And as I said before, in terms of the FCC summit, there are different challenges for different carriers. It's not a one size fits all. So for the larger carriers, some of the big challenges here are, how do I minimize the network impact? So as I implement STIR/SHAKEN, I have a huge network of potentially hundreds of SBCs, hundreds of gateways. How do I make it easy for me to implement STIR/SHAKEN without it impacting the whole network? If I don't have to upgrade all the elements and still implement STIR/SHAKEN, that's a big benefit.

Testing STIR/SHAKEN without impacting carrier networks

Then the next thing is testing. So as I said before, there is the is the ATIS test lab run by Neustar that can be used by all carriers to come together and test with third party solutions. But not just that, even testing within their own network is very key, because they don't to break any existing call flows, or any existing custom logic in the network. So how do I test STIR/SHAKEN without impacting the existing situation in the network?

Collaboration and interoperability across IoT

The third big challenge here is the IoT with other carriers. You might have seen some press releases from the big carriers about interoperability with other carriers. But this is another challenge where carriers have to work together. And I see a lot of collaboration in the space, which is really encouraging.

But the carriers really have to work together to make sure the interoperability between the different carriers work. And this is key, really, for the whole STIR/SHAKEN framework to really function in a nice way, is for all carriers to eventually implement this, and be interoperable, so we don't see any issues with calls going back and forth.

The next challenge is scalability. So a lot of these big carriers have multiple data centers spread throughout the US, and maybe internationally as well. So how do we scale the STIR/SHAKEN solution across these different data centers so that there is no single point of bottleneck in the network?

Future-proofing STIR/SHAKEN solutions

And the last piece is how do we pick a solution, the STIR/SHAKEN solution, that is extensible into the future? So 2019 is all about complying to STIR/SHAKEN, in terms of signing and verifying calls. But it doesn't stop there. So how do I pick a solution that gets me to 2019 compliance, but then keeps me future-proof by implementing, or providing me a roadmap, of things that evolve from STIR/SHAKEN standards bodies, including delegation, enhanced calling name, other things that come up in the future.

Let me pick a solution that gets me compliant today, but also lets me keep my eyes on the future as we go through this evolution. So those are some of the challenges that large carriers are facing as we talk today. The smaller carriers, some of these challenges that the larger carriers have, the smaller carriers do have as well.

But the biggest overarching theme is the resources that they have, not just the cost, but also the personnel to manage the solution. So how do I make sure that I comply to STIR/SHAKEN standards, but by being within my cost footprint and also my employee footprint, and get a solution that's easily — that I can operate, and use, and troubleshoot going forward? And as I said before, some of these carriers do have some TDM in their networks today.

It could be within their networks. It could be the interconnection with other carriers. It could be TDM. So how do I get a solution that also addresses some of the TDM and subscribers as well? So those are some of the challenges that we're hearing from carriers, as we test with these carriers, and deploy into production as we go forward.

How Do I Enable STIR/SHAKEN without Touching my Entire Network?

So taking each of these challenges one at a time, I'll address a couple of challenges, then hand over to Ken to address some of the other challenges. So for the larger customers, the biggest challenge is, how do I enable STIR/SHAKEN without touching my entire network, or without upgrading my network? Which is not an easy thing, it'll take months, and if not years, to upgrade the entire network. So how do we make it as easy as possible for myself to implement STIR/SHAKEN while keeping a lot of the existing network as is?

So we have a solution across Ribbon and Neustar for such large customers. And as I said before, just to look at this picture on the left here, the SBC is really the anchor for the call flows for STIR/SHAKEN, as STIR/SHAKEN is really geared towards SIP calls. And the SBC is really the anchor point for such calls.

The SBC, in Ribbon's case, talks to the centralized routing engine, which is a PSX, to get routing and policy updates from the PSX. So as part of getting the routing and policy, now the PSX also enables signing and verification as part of the call flow.

And the PSX, in turn, turns to Neustar with their SDI components that Ken just described a few minutes back. The PSX extends Neustar components to sign and verify calls that the SBC is looking at. So that's kind of a solution at a high level, where SBC does the call anchoring. The PSX does routing, policy, and signing. And the Neustar piece really handles the certificate repositories and the actual signing and verification with the certificates with the public and private keys.

So with this architecture, the larger carriers don't have to really touch every single element. They don't have to touch the axis switches. They don't have to touch the gateways. They don't have to touch other elements in their network, policy devices in the network.

All they have to really upgrade or enable is the SBC and the routing infrastructure. So once they enable or upgrade their SBC and routing infrastructure, that will enable calls to be signed and verified with the Neustar SDI piece of the solution. So we call it the centralized deployment model.

So with this centralized deployment model with the PSX, it really minimizes the network impact for large carriers. It is also localizing the testing to a couple of key elements in the network. So you don't have to test every single call from the network. The testing that you have to do is really localized to the SBC and the PSX call flows. So that is from minimizing the network impact for a large carrier.

How Do I Maintain a Flexible PSX Policy?

The second piece is really the flexible policy on the PSX. So as we are centralizing the STIR/SHAKEN implementation, there will be questions from carriers about, how can I enable policy on the PSX? Because you're doing it in a central place. How do I have granular policy on the PSX?

So the PSX does have ground level policy for attestation and other STIR/SHAKEN policies, where you can assign different types of parameters, ingress parameters, as well as egress barometers, to define attestation profiles on the PSX. So it doesn't matter if the call is coming from a particular trunk group or from a particular business unit. The PSX knows about those ingress perimeters, and can make an informed decision based on configuration to assign the right level of attestation for such calls.

So while the deployment model is centralized, you have the flexibility, so that you can customize the policies for different ingress and egress points of your network from a centralized place. The PSX also enables calling name support. So as we go forward, when we have enhanced calling name, we'll support that as well. And also, the PSX provides subscriber policy.

We described the FCC ruling on call blocking for subscribers. So we can go much more fine grained beyond that. So the subscriber not just has a capability to enable and disable call blocking. But they can go further down and enable white listing and blacklisting based on their choices. So there is a full fledged subscriber policy database on the PSX as well, where subscribers can manipulate their own policies.

And also, this solution interfaces nicely with our analytic solution, which we'll talk about in a few minutes. So you have a single piece solution that's centralized, minimizes network impact, and provides the flexibility that large carriers need.

So the other piece of this is, also, it builds on the previous use case. But if you have third party network elements, the previous use case focused on Ribbon network elements, if you have third party network elements, could be a third party SBC, could be a third party gateway, the Ribbon Neustar solution also addresses that, using the PSX again that acts as a centralized routing engine. But now acts as a SIP redirect or proxy in these networks, in these third party networks.

And it has the same advantages as I talked about in the previous slide. And on top of that, it provides a network wide solution. So it's not just a Ribbon solution. Any third party network elements we have that talk SIP, we can accommodate that into this framework.

So it's really a network wide solution. And it's one solution for Ribbon and third party elements. It's one interface for STIR/SHAKEN, least cost routing, LNP, calling name, number translations, analytics. So it's one interface by which third party elements and Ribbon elements can get policy and STIR/SHAKEN in one interface. So it's very simple to use, centralized solution, with the flexibility that the larger carriers need.

For that, I'll turn it over to Ken to take us through the rest of the challenges, and how to overcome those with the Ribbon Neustar solution.

Deployment Using the Centralized PSX Approach

Thanks, Rahm. Yeah, so from a deployment perspective, we support multiple deployment models. These are software based solution deployments. So looking at the architecture here, just from a scalability perspective, there's many options for local active, active redundancy, as well as georedundant redundancy as well. The key here is using the centralized PSX approach, we can focus most all the capabilities in two data centers.

And then from a rest implementation standpoint we provide software based load balancers. If you wanted to extend capabilities of signing and verifying, those capabilities, the AS, the load balancer, the VS, and the PSX could be in other data centers, while the provisioning functions that are shown on the above there are pretty much geographically centralized across maybe two main data centers. And this is important, not just for your local deployments, but also from a hosted perspective. These capabilities are also available in a hosted service, which you want the same level of scalability in terms of expanding capacity as you need.

So on the next slide, Rahm, OK so this slide is showing a lot. Let's start from the bottom here. So we're showing a carrier environment. We're showing two different types of environments, as you go and look at different carrier environments. We're showing kind of the IP aspect of this, with a VoIP switch going to an SBC.

But we're also showing, as Rahm had said earlier, that the TDM prevalence and technology is still out there, if not from an interconnect perspective, but also within a carrier's network. And the two approaches here are pretty much to apply STIR/SHAKEN directly on the IP side of things. But another recommendation is the call originates on a TDM aspect, and remains on a TDM at the point of a gateway, whether that's within your own network or possibly with a partner.

And that would be your interface point to be able to start signing and verifying phone calls. The interface to the hosted cloud, which we're leveraging Amazon for the ability to spawn up different data centers and manage latency, we're showing an option here where the PSX is actually part of the cloud. Or it could be part of your own network. And then the request to the authentication and verification services are just the remote queries coming from the locally deployed PSX.

We're also showing the certificate management, I guess, if you click the animation. So a key step here, this is the provisioning. This is done pretty much — this can be done mostly transparent to you, working with you. But this is not something that you would have to be actively engaged in.

As I mentioned earlier, we can support that pre and post the actual US governance structure shown on the left there, again with that target of 12/11/19. And then the actual call management functions are then managed by the actual AS and the BS. So you have calls that are originating and coming in from your networks.

So your customers are placing calls, SIP invites, with identity headers that would be leaving your network, and also coming into your network. And then the PSX and the Neustar solution through the SBC, whether it's a Ribbon or a third party element, is handling those calls via a REST API. Our interface is compatible with the ATIS recommendations.

However, it's expanding over time to enable some other capabilities that are critical and essential, basically, for a complete solution. So this solution, we could have said that that was for small providers only. But I think folks are looking at this as a way to provide compliance, if needed, in 2019.

But this will move down market fairly well. And the price points are, we think, pretty attractive for most. And we recognize there could be still some challenges at the very low end. But we're more than happy to work with folks on something that would work in that environment.

Next slide. So the new ruling from the FCC really gets down to four key ingredients, as we move forward in this journey. When we talk about call blocking, it makes a pretty specific requirement around handling call treatment.

And call treatment, when I say call blocking, it really covers a range of types of treatments, from either displaying warnings to a customer, or just blocking the call, or other network triggers. The subscriber opt out becomes a new requirement, because you can opt a customer in by default. But if someone does not want the service, then you need to have some type of a portal that is going to manage that capability, since probably you'd want that to be a pretty automated feature.

The third element is the STIR/SHAKEN, which fortunately we have a core set of standards for providing the ability to authenticate the calls on, on originate determination perspective. And that provides valuable input into the fourth component, which we're really excited about expanding together in the area of analytics. This is going to be interesting territory, where you're going to have to have mechanisms for determining how you're going to treat these different calls.

Our goal is to provide the use of as much valuable data in that process, and also cover a broad range of blocking, from display capabilities all the way up to actually blocking the call. So we have the SIP invites coming in. We're looking at the terminating network here.

We've got the verification requests being triggered from the PSX. And then the VS service from Neustar is pre-integrated with our back end. So we cover services, such as conventional CNAM, the 15 character CNAM, number ownership capabilities to be able to help on the validation of calls coming in, the ability to retrieve and provide enhanced CNAM data to be provided through the devices that can support that. And then also from an analytic standpoint, we have a robocall mitigation service and a database that allows from an open API the ability to get information about the fraudulent nature of phone numbers, and incorporate that into an expanded PSX capability and analytics capability using their protect product, and specifically Robo Protect, which actually takes in the network data, and also combines it with other third party and also the Neustar assets that we've been building, and have pretty much leveraged from an identity management company.

So with that, and then ultimately the last step of this is taking all that information together, and applying this call treatment. And in this case, we're showing a blocked call. And I'll turn that over to Rham, just talk a little bit more about the detail on the analytics.

STIR/SHAKEN signing and verification

So analytics, this is going to play a big part. So STIR/SHAKEN signing and verification absolutely is phase one. So that's how we get started to get compliant. But analytics is going to play a big part in the phase two of the robocall mitigation strategy here. So analytics equally applies to TDM networks as it applies to SIP networks.

But this is one way of bringing the TDM networks into play here, so that you're not leaving any subscribers, even the ones that are on TDM networks, behind. Analytics is a key part. And if you think about this, once we start plugging holes on the STIR/SHAKEN side by signing and verification, the robocallers will basically, once you plug one hole, they're going to look for another hole to basically attack the network.

So analytics is really the long term way of , once the low hanging fruit is — we get that using STIR/SHAKEN. Analytics is the way to really plug the network, and keep it steady and solid, and mitigate robocalls into the future. And analytics means different things to different people. In terms of call blocking analytics, we have a very strong solution across the two companies, Ribbon and Neustar.

And the Ribbon product is called Robo Protect, as Ken just mentioned. And Neustar does have a robocall mitigation product as well. The way these things work together is basically it's a big data product that brings in data sources from different places.

We do bring in a data source from third parties. These are the crowdsourced databases that get data from the real end users on if they are blocking calls or not. We do get information from the FCC database.

We do get information from the assigned numbers, and do not originate numbers. They get information on the Neustar calling name robocall mitigation database. So we put all of this together.

And what Ribbon brings to the table by putting all of this together is to really add the network capabilities to this database, because Ribbon, with its SBC and the PSX is really in the call path. It looks at all signaling messages going back and forth in the network. It looks at all the media packets going back and forth.

So it's really in the network. Ribbon elements are in the network. And they get the network level statistics into this big data database. So by putting all this pieces of information together, the network statistics, the third party crowdsourced data, the calling name data, and different other databases, they come up with a kind of a curated list of numbers.

And this takes time. I mean, this is not day one you'll not have analytics functioning. But as the big data platform learns the network, and looks at the patterns, looks at the network behavior, it builds a really well curated list of numbers that can be blocked. And this takes time.

And, eventually, this could be federated, where different companies can share data. Obviously, it needs to be anonymous to keep privacy with the networks. But this could be federated as well. But the concept is, analytics takes time. But if you're building the right technologies and the right architecture, this is the way to really mitigate robocalls for the longer term.

In terms of just explaining the process quickly, the SIP invites come in to the SBC. And this is on the verification side, on the terminating side. And as Ken described, the Ribbon solution, that's PSX, is going to make a verification query toward Neustar. And Neustar SDI VS, in this case, is going to verify the call.

Along with that, it's going to get a fraud score. At a high level, it's nothing but a fraud score on a call-by-call basis. So this combined analytics platform, it's going to look at the number. It's going to look at the network behaviors, and all the databases that I talked about before.

And it's going to basically give a fraud score, or tell what type of call it is, back into the Neustar, and back into the Ribbon solution, so that now, the carrier, the terminating carrier, has knowledge about the call, knowledge about the verification status. It also has knowledge about what type of call it is, and what the fraud score is. So based on consumer behavior, we can now provide an enhanced caller ID to the end subscriber, providing as much information as possible in an easy to use fashion so customers can make an informed decision on whether to pick up a call or not.

How Soon Can I Implement STIR/SHAKEN?

So with that, let's break into a poll, the second poll question. So, Lance, if we could launch the poll. The question is, when is the earliest that you see being able to implement STIR/SHAKEN?

And this is for the large carriers, small carriers, MSOs, wireline, wireless, all types of voice service providers. What is the earliest that you see being able to implement STIR/SHAKEN? Before 2019, first half of 2020, second half of 2020, and then we have other options. It may not be applicable to you. So let's take a poll. Again, the point here is to get some feedback from the general audience here so we can tweak our webinars going forward.

And Rahm just an update, we have about 30% answered right now. So we'll just give it another second. And we'll release those results here in just a minute.

OK, sounds good.

And this is another reminder, thanks to everybody who's been submitting their questions. They've been pouring in. We'll definitely be following up with you after the webinar today on your questions. So just another reminder, you still have plenty of time to ask those questions.

So looks like we're about getting close to 70% here. So I'll let it keep going up for a minute. And then I will release those results.

OK, so I do see the poll results here. So I'll give my view. I would have expected more of the folks in the first half of 2020. But it looks like a bell curve, almost a bell curve. So a lot of the responses are leaning towards the second half of 2020, and before any deadline by the regulatory authorities, so slightly different than what I expected. Ken, do you have any views there?

Yeah, it sounds like we'll be doing a lot more webinars.

Absolutely.

No, thanks for the feedback on that. It's always good to get a reality check, and understand the folks that are participating, and what their views are.

Great, so, Ken, if you can continue. So we're getting into the next section, where we talk about, what is the future beyond STIR/SHAKEN signing and verification? What are some of the things that we are looking at, the standards bodies are looking at? Ken, if you can take us through the section, that would be great.

Sure, and time flies when you're having fun. Hopefully, you can sense that both Rahm and I, and our companies, are very passionate about this topic. And definitely feel free to reach out to us, because we will probably run out time of doing things justice here.

Next Big Trends in Robocall Prevention

But the idea here was that we were going to try to touch on some of the most newer type — or now that we have an implementation that folks can use in the 2019, what are the next big things and horizons here to address? And I'm not going to go through everything on here. We won't have time.

But we did highlight four on the top here. And I did want to mention, we're going to talk just quickly about delegation. I'm going to tee this up.

I'm sorry. Stay on, if you go back, Rahm. Yeah, I'm going to just tee that up. I don't think we'll have time to do this. I want to at least tee up the challenge.

And for folks who think that they are in that kind of situation, we would love to talk to you, and talk about some of the things that we're specifically doing there. But the other three areas I think we tried to touch on, and I just want expand a little bit, the governance — the key thing here is going to be a change from those providers that deploy, or have deployed, or will deploy probably before December of 2019, and then adopting and integrating into the governance framework that we talked about.

I want to point out that there are going to be some standard changes to support that. There were some in February. And there's some more coming. So stay tuned on that.

They're not overly significant. But the point is that there is still some evolution here to get to kind of a target state of where the initial standards set out to be. On the display side, a very emotional topic.

So I'm not going to spend too much time on that. Rahm did indicate this was a key focus of the summit. But this is really a decision, and a local decision for service providers, knowing their customers, and how the best way to display — whether they display anything, whether they take an aggressive blocking policy that's backed by analytics that they can truly trust. But there may be some — it's going to be hard to reach consensus in this area, I believe. But that's another key area that is definitely out there, and ongoing discussion.

Evolution of default call blocking

And then on the default call blocking, this is fairly recent. But I think we talked pretty clearly about the key elements here, and some new things and new requirements that carriers will need to meet to support this if they want to go down this path, and then also the importance of the analytics. Again, the bottom part, I'm just going to leave there. It's really just to indicate that beyond 2019, there's still a lot to do, a lot of territory to cover. People are working actively, and are committed to doing this. But there is going to be several evolutions of this as we move forward.

So just lastly on the delegation side — again, I won't have enough time to go into too many details. But let me tee up the challenge here. It is important that you understand the concept of attestation. Attestation is, as Rahm I think mentioned earlier, is an ability in the standards — and on the right hand side here, the three levels are actually defined based on the current 1074 ERATA standard.

Improving delegation and attestation

These are really defining an association from the participant and the carrier that's been approved into the ecosystem, the relationship that they have between themselves, the customer, and the telephone number identity. And I'm not going to go through the standards piece of this. But the verbal, more human kind of examples on the left there are things that we will build on.

And we mentioned the A, B, and C. And the fear here is that, depending on how these outstations are applied, you start to potentially define different tiers of credibility of originating providers that may fall into a certain use case. So let's tee that up.

So let's look at the next slide on it, just a typical, the most standard, consumer — oriented SHAKEN per call authentication. We have the originating carrier responsible for the 908-666-1000 block here. And if you click the slide — so they're going to make a phone call from a number that they've assigned from that consumer.

It gets signed. And carrier A tells carrier B, this is my customer. I gave them this telephone number. And the call originated on network. Truly, an attestation A can contest that.

And then one more click, everything on the analytics and the STIR/SHAKEN verification should, under normal conditions, should verify. And the terminating provider has no real information in this case to treat this call any differently than what I would say as highly trusted, unless the analytics really showed something otherwise.

But I'm assuming that the analytics is going to support this consumer case here. And then, lastly, you can see that — I'm sorry. Go back one.

The last thing here is that the indicator that gets sent on the wire is this concept of a VERSTAT attribute. And that's defined in the 3GPP standards. But it's a simple indication of what happened as part of the verification process at this point in time. More importantly, if we go the next slide, let's look at a different example here.

Solving for complex carrier & reseller scenarios

And I'm calling the customer here a reseller. Think of that bubble as anyone who is providing phone service. And they are leasing phone numbers from multiple carriers. In this case, we'll say multiple carriers.

And I didn't mention on the other one, we're assuming end to end IP here, so just to clarify that. So in this case now, the reseller — I'm going to call it a reseller, is that they're making a call from a number that was assigned from carrier B. But by using least cost routing, and other mechanisms, that call is going to then originate through carrier A.

And they're the ones that are actually signing, because they are the ones that have that phone number. And they're the ones that are currently part of the SHAKEN ecosystem, as we see it being defined so far. So carrier A is now telling carrier C that this is my customer. The call originated on my network.

However, this is not my phone number. And, really, by the letter of the standards, that that really would fall into an attestation B. And then the question really becomes that the verification will pass, if it was constructed properly. I mean, you can have a successful STIR/SHAKEN verification with attestation B. But the question is, when you combine this with analytics and other local policies, since that's not defined in standards, how is that carrier C going to treat this call.

And I think the challenge here is that those folks that are doing legitimate calling on the originating side that may fall into this group of use cases — I'm going to go into all the use cases. But I think hopefully this will give you an idea of whether this is potentially a challenge for you participating in this ecosystem. This will give you the concern about trying to look at — from an industry standpoint, we're now looking at, how do we provide a mechanism and a structure to provide attestation A for such use cases?

And then just to close this out on the next slide, I'm not going to have time to go into too much detail here. But there are two basic approaches. I'm not going to go into the details.

The first approach is that through the STI-GA, you come up with policies that allow these, let's say, more non-traditional providers. And there's a whole class of providers of telecom service that can fall into this category. You allow them direct participation.

And they will get service provider tokens, as I discussed earlier, have the ability to sign their own phone calls, and assumes that the other carriers may be ones that are actually getting number of resources directly and leasing them to you, they actually trust you in that ecosystem. The other approach, which is really aligned in extending the use of existing digital signature technologies that take place on the internet today, is a concept of delegation.

And delegation has been drafted in the ITF standards, authored by a Neustar in this case. And it talks about just allowing a carrier who is a direct participant in the SHAKEN framework, based on the current definitions as we see them. They have numbering resources. And they have OCNs and SPIDs.

Once they have that participation, that they can on their own decide how to delegate subordinate credentials to allow others to sign calls on their behalf. And the SHAKEN specifications allow for this level of granularity beyond just that of service provider, down to ranges of phone numbers, and down to even individual numbers. But this would allow the folks to pretty much manage this directly on their own, without being tied into a more broader governance structure.

So stay tuned on this one. Apologies for rushing on through this one. But let me let me pass it back to either Rahm or Lance to summarize here.

So, thanks, Ken. So as you can see, there is a lot of topic that's coming up beyond 2019. So stay tuned on that.

Carrier adoption of STIR/SHAKEN has begun

Again, our goal, just to recap what Richard Shockey keeps repeating is, resistance is futile. Everybody has to adopt STIR/SHAKEN. So this is going to happen. And it's happening right now.

And the purpose of these webinars is to keep you updated with the experiences that we have had with customers, so it's easy going forward for newer customers. And just as a summary here of today's webinar, the 2019 solution is really to tag, sign, and verify calls. That's what we need to comply to the SEC.

And some carriers along the way, some carriers are starting, and some carriers are starting to look at it. So let us know if you need our help in getting the 2019 solution going. We'll look at challenges for bigger carriers and smaller carriers, in terms of minimizing network impact, and the cost, and scalability.

And we've provided recommendations with a centralized combined solution between Ribbon and Neustar. And the solution has been tested, not just in the ATIS lab, but also in customer labs, and has been deployed in customer production environments. And we've talked about different deployment models, cloud-hosted, on prem, whatever is the right model for you. We have those options. And we are ready to discuss that with you.

And as Ken just gave a sample of what's coming up, beyond 2019, there is a lot of topics, including analytics, including delegation, that's going to come up, including enhanced CNAM for end subscribers that's going to come up. So to stay tuned on that. We'll get back to you with more information as we go through this path together.

And, basically, from a Ribbon and Neustar perspective, it's really a strong technology partnership with a strong, aligned roadmap. We want to bring customers such as yourself the best in breed solutions in a single, easy to use package. With that, so there is more information available at both the Ribbon portal and the Neustar portal.

And here are some links to that. There is more information available there. And we'll be updating this information as we learn more, as we go through some of these customer deployment scenarios. With that, that comes to the end of the webinar here, Lance?

Thanks, Rahm. Thanks, Ken. Yeah, we were going to get a little Q&A. But I think in the interest of time, we'll just be sure to follow up with everyone afterwards. We will be sending out an email later this afternoon that will have a link to the full replay from today's webinar, as well as the slides.

I'll include these two links that Rahm has here up on the screen as well in those emails, so you can have those in your inbox. But we certainly do appreciate your time.

As Rahm and Ken mentioned, feel free to reach out to us at these websites. There's plenty of ways to get a hold of us. We certainly thank you for your time today, and look for that email later this afternoon. Thanks so much. Have a great rest of your day.