What it Takes to Get a Green Checkmark Displayed With Your Call: Understanding Termination

Rebekah Johnson, CEO, and Anis Jaffer, Chief Product Officer of Numeracle host a live Q&A podcast series covering all things related to call center communications, including call delivery, STIR/SHAKEN, caller ID technology, TRACED Act, brand identity, and more. In the episode below (transcript edited by insideARM; listen to the full episode here), Rebekah and Anis have the second part of their discussion about what it takes to authenticate and achieve the elusive "green checkmark" on the end subscriber’s device. Read the first part here.

Let’s start with a recap of the origination side as it relates to authentication.

Rebekah Johnson: First and foremost, the originating service provider must establish a local policy for how they will attest to the authenticity of the calls originating on their network. This will be achieved through policy and procedures with the help of identity management tools if needed. The indicator in SHAKEN that relays this authenticity is through the Attest Claim, which can be one of the following three values: A, B, or C, as defined in the ATIS Standard.

We also learned an originating service provider’s reputation is dependent upon how rigorous a local policy they implement when making the claim of A. Meaning, the identity of the caller, and authorization for use of the TN can be proven.

We concluded part one of What it Takes to Authenticate by exploring the challenges related to the gap between the originating service provider and the identity of the caller due to the presence of call centers, BPOs, and communication platform providers. Several options were discussed, each with their respective pros and cons. The expectation is that the industry will land with one or possibly multiple solutions.

Where should we start on the termination side? How does the terminating carrier make the final decision to display the green checkmark?

Anis Jaffer: To understand what happens at call termination, let's first talk about the various components involved. First, we have the terminating network: this is the service provider where the call is terminated. Then you have the user device where the call lands. You can also have another component used by the terminating service provider for call validation, which is the analytic service that some providers use. So, in STIR/SHAKEN when the terminating network receives the call, they would first verify the signature received as part of the SIP header. This verification service would determine whether the call received is from a trusted source.

We talked about Attestation Flags last time, so the attestation flags sent by the originating network will be used by the terminating side to determine whether the call can be authenticated. Assuming the call is authenticated, the verification service then would update a parameter, what is called a Verstat Parameter. If the call is authenticated the Verstat Parameter would be updated as “TN validation passed.” If the call is not authenticated, then the terminating service provider would set it “TN validation failed.” In this case, they can also block the call.

Rebekah Johnson: You mentioned call validation. I’ve heard this referred to as CVT or Call Validation Treatment. Would you explain that portion just a little bit further?

Anis Jaffer: CVT is the (optional) analytics service that service providers can use. After the carrier verifies the result from the SIP Header, the CVT uses analytics and reputation data sources to determine if a number is fraudulent or spam. This information is then used as an overlay on the user device to show if a call is labeled as ‘Spam,’ ‘Scam,’ ‘Nuisance Likely,’ etc. This could either be a carrier application service that's drawn as part of the verification we talked about earlier or, it can be implemented as a third-party solution. For instance, all the major U.S. carriers use third-party analytics for call labeling.

Okay, so as for the consumer display, where does the green checkmark fit in?

Anis Jaffer: We talked about carrier verification and analytics. The green checkmark is on the user equipment or the end device. Let's say the call terminates at the network level, verification is done by the verification service, TN validation is passed, and the verstat parameter is set as “validation passed.” At this point, CVT does its check, and let's say the number is determined as ‘Not Scam’ or ‘Not Spam. At this point, the CVT can pass this information to the user device or an app running on the user device, which can then display a checkmark, typically a green check, or it could be a character “V”.

This depends on the user equipment. In the case of smartphones, you can display the checkmark but in the case of devices with limited capabilities that display text-only, a simple indicator, like a letter V, can be used. For instance, Comcast recently announced a rollout of STIR/SHAKEN across the Xfinity Voice Over IP-network. They leverage both for displays that are capable of displaying the green check. For character or display-limited devices, they display the letter V.

Rebekah Johnson: Speaking of Xfinity, we led a proof-of-concept to test delegated certificates with Comcast, which was serving as the terminating provider, and Twilio as the originating provider. Through our Identity Management Platform™ we were able to verify the identity, authorization for use of TN, and elevate this information to Twilio via a delegate certificate provided by NetNumber.

The reason Comcast seems to be progressing very quickly on the display side of termination is their control of the display on the TV and their mobile service. Does this mean the display is dependent upon the user and the equipment?

Anis Jaffer: Yes, that's a very important layer that influences how the calls are displayed on the device. Assuming verification process CVT checks and calls actually land, the app running on the device can layer its data on top. It could be a green checkmark, it could be a CNAM look-up where it can pull up the caller’s name, or it could look up its own data source for logo and call reason for that number and display that. There are several apps that do this today and typically they use pre-loaded data either from an internal database or by connecting to a third-party data source. They match the number to the corresponding name, logo, and call reason, and they overlay that information on the device. Today it’s usually caller name, but more and more we are seeing rich call data and logos being displayed.

Does the rich call data provide information, such as logo and call reason, as part of the STIR/SHAKEN certificate?

Anis Jaffer: There is a way to pass RCD over SIP as part of the SIP header. An originating service provider can add an RCD claim and when that information is received by the terminating service provider, they can choose to display this information on the device. However, this is not part of the BASE STIR/SHAKEN specification and the originating service provider does not have to do this. The delegated cert specification allows RCD to be added to the header, however, adoption is still early. We have to get through the STIR/SHAKEN implementation first before we can take full advantage of RCD claims on the SIP header.

With that said, while STIR/SHAKEN implementation is ongoing, some other solutions have sprung up. These are essentially using the data network to transmit rich call data to the user device by bypassing the communication network; these are called out-of-band solutions. For example, Google introduced Google Verified Calls, which works this way.

Out-of-band means out-of-telecom-band. What exactly is this and how does it work?

Anis Jaffer: In an out-of-band model the originating enterprise and its information, such as business name, logo, the numbers they are using, and the reason for those calls, are registered ahead of time with the service. When the business originates the call, they can attach the From: Number and the To: Number to the service right before the call is made. They have to do this right before the call because this information is short-lived and it is only alive for a few minutes.

In the case of Google, for instance, they can push this information to a specific Google device. As soon as the call lands on the device, Google can overlay the logo and call reason when the call rings. So as the data is sent, not using the communication network but essentially using the data network, it's called out-of-band.

Rebekah Johnson: This raises interesting concerns. If it's outside of the communication network, then is it outside of the Standard?

Anis Jaffer: That's a tricky question to answer. It's outside the Attest or STIR/SHAKEN Standard, but they are part of an IETF STIR Standard called STIR Out-of-Band. So it’s not something that's completely out of standard specification. In fact, even in the case of STIR/SHAKEN, there are networks that are not fully SIP enabled and this method can be used to pass data. Surprisingly, there are a lot of networks that are still TDM-based, and since they cannot handle SIP headers, one proposal that has been presented is to send this STIR/SHAKEN information using the data network, or basically, an out-of-band solution.

What should we expect from the FCC’s June 30th deadline?

Rebekah: While I'm hopeful for a June 30th, 2021 deadline, I don't believe that we're going to see an environment where authentication from origination to termination exists throughout the network; it's going to be a mix. I think we're going to have to continue to watch the progression of where this goes and how the industry responds. Especially, it seems the terminating carrier side has a lot of control over what eventually gets displayed no matter what you do on the origination side.

Anis Jaffer: At the end of the day the call gets terminated and the user device has to display the information. You can add information at origination, but then it needs to get transported first to the terminating service provider, and then they have to figure out how to send this data to the end device. Then we have this added complexity of multiple service providers that are not SIP-enabled, there are several TDM-based networks, so how do you pass the information through their network? Calls don’t go on a single hop, there are multiple hops that happen before the call actually goes from origination all the way down to termination, so there is also this added layer where you should be able to send data.

I think the space is going to be evolving; the first step is to implement STIR/SHAKEN and get as many carriers as possible and networks as possible to handle that. Then over a period of time, we'll be able to add rich call data. In the meantime, devices also need to have the capability to display the information; that is also evolving. We saw Google doing something. Apple could do similar things, but we don't know at this point.