Molly Weis: Hello, everyone, and welcome to Tuesday Talks, a live discussion series where we bring truth and shed light across the brand identity and communications industry. I'm Molly Weis, the VP of Marketing and Communications at Numeracle, and I'll be co-hosting today's session with our Chief Product Officer, Anis Jaffer. Hey, Anis.
Anis Jaffer: Hey, Molly. How's it going?
Molly Weis: It's going great! It's been a while since you and I have done this together. It's pretty cool.
Anis Jaffer: Usually, it's Rebekah and or Rebekah and a guest so this is a change for Tuesday Talks to get us on this together and it's going to be fun! I'm looking forward to this session.
Molly Weis: Absolutely, me too. We planned a really good session today for our sixth episode of season two. We thought we would take some time to field all of the recurring questions that have been submitted by you, our listeners, submitted on the website, submitted live during our sessions, and also on LinkedIn.
What we're going to do is group these into three main categories where we'll cover questions about number reputation, which is all things call blocking and call labeling, we'll cover STIR/SHAKEN questions, and then branded calling. For anyone who is listening live, feel free to also drop questions into that chat window at any time as well and we'll cover those if we've got a couple of minutes left at the end.
Why don't we go ahead and start with some questions about phone number reputation. So number one is: Wasn't STIR/SHAKEN supposed to stop bad robocalls and enable good calls to go through? If I'm a legitimate business, why might I still see my calls labeled as 'Scam' and 'Spam' today?
Anis Jaffer: We get this question a lot, especially since STIR/SHAKEN got rolled out. A lot of enterprises do believe that once this got updated, their 'Scam' and 'Spam' labels would go away, but we know that's not true. In reality that's not what we are seeing. Let's start by looking at this from the STIR/SHAKEN perspective. In theory, on the origination side, call originators are required to sign the calls from legal callers and at termination, the call should be accepted and delivered because there is a certificate that goes along with the call. But in reality, it's a little bit more complex.
First, the originating service provider needs to have a direct relationship with whoever is originating the call to sign the certificate with Attestation flag A. If not, the call is either going to get sent with a B or C (attestation level). In the case of C, it's basically like not having the call signed because it's the lowest level of the Attestation flags.
Typically, it's supposed to be used when the originating service provider does not know where the call is coming from or if it's coming through a gateway from an international relation and does not have any kind of relationship with the customer, meaning they don't know what the call is for when the call was originated. That's C Attestation, and we've heard that a few service providers are signing their calls with Attestation level C if they don't know what the call is for and most calls are going like that. Then you have B Attestation when the originating service provider does not know who is calling OR does not know who the number is issued to. A-Attestation would be when you have the OSP (originating service provider) who knows the customer and who knows that the number has been issued.
Then you have the infrastructure itself, even if the call is signed as A Attested, if the call gets routed through nodes that are not STIR/SHAKEN enabled, and a lot of nodes in the network is still in TDM switches, then the certificate could get dropped along the way. So when the call actually reaches a destination it may not have the certificate attested A, it could have C because somebody dropped, and then the next node did not know where the call was coming from so they attach C-Level Attestation.
Eventually, when it gets to the terminating service provider, it doesn't have the right authentication and we've seen that in the case of rural providers. We are getting a significant number of providers that are still operating on legacy systems and most calls originate at C Attestation. Because of all this, at termination when the call is received, the carriers still run analytics and we continue to see labels being attached because that is still in place.
Basically, the algorithms would still look at these calls as unauthenticated, or even if it's authenticated, they would still look at the patterns where the call is coming from and call volume, and then they could still get labeled. That's what's going on right now.
Molly Weis: What about the blocking of those calls? We're covering the labeling but when calls are blocked, is an entity going to get notified that its calls are blocked, or is it left to them to figure it out or it's a mystery?
Anis Jaffer: Right now, it is still a little bit of a mystery because when the call reaches the destination, the service provider has to decide if the call is authenticated or not, and if it has A Attestation then they would probably send it through. However, the analytics engines could look at it and see if it's got any patterns where they would look for call volume, time of day, and user preferences if the number is being blocked by their users in the apps, they'd look at originating IP, etc., there are several factors that they'll look at and that could still be determined as fraudulent so you could still get blocked.
For the most part, when consumers originate calls, let's say you are a T-Mobile subscriber calling another T Mobile subscriber, you wouldn't have an issue. Or when you have a mobile carrier call between two different carriers, you could be on AT&T calling T-Mobile, for the most part, you would not have an issue.
The issue happens when you have enterprises or businesses originating calls and then you don't know where it is originating from or it could go through those different nodes and because of that, the calls could get blocked. Now for the notification part of it, at this time, there is no response back all the way to the originator saying the call got blocked. Typically, you would get a 'No Answer', the call wouldn't get terminated, that's typically what you'd see.
The SIP stack itself will throw an error, but that doesn't go all the way back to the originating caller, especially if you are behind a contact center, you would have to really look at the SIP stack to understand what happened with the call. Now, there is a standard that has been proposed and it is an active discussion. The question is if they can add error codes, that would define what it would be, but we are not there yet. It's not a complete standard, discussions are ongoing and it's not finalized.
Even if you do all this, all the issues we talked about earlier with the infrastructure would still be applicable, so how do you the code all the way back to the originator? What happens if some of these codes are sent and then it goes to a bad actor? Now they could figure out they're getting blocked so then they would figure out alternate ways. Those are all the considerations for the standard, and it's still ongoing.
Molly Weis: We've got a live question on this topic so I'm going to throw this one in at this time. Some service provider code token holders say that you can see right away if your outbound calls are being signed because if they're sent to a T-Mobile or Verizon smartphone, it will show up as having a checkmark. So how come I'm only seeing checkmarks on non-enterprise or residential/personal calls on iPhones only?
Anis Jaffer: fI I understood this question correctly, if the originating caller is also on the cell phone network and the destination is a cell phone, then most likely the call is signed and you would get the verified checkmark. Because let's say you're originating a call as a subscriber in the T-Mobile network, T-Mobile knows who you are, knows that the number has been issued to you as a subscriber and that you're calling another subscriber that could be on T-Mobile or it could be on another network like AT&T, they would be able to pass the certificate.
When they receive the call, or another subscriber receives the call, they would authenticate it and say it's an authenticated call. However, for enterprises, you can go through cell phone networks, you're probably originating calls through other VoIP or even TDM networks, and that's the challenge. You need to have a service provider who's going to originate the call, and sign this call appropriately before it can go all the way, and not only that, it also has to be routed appropriately so that the certificate passes along every single load and then reaches destination. That's the challenge.
Molly Weis: That makes sense. Since we've gone down the STIR/SHAKEN path, let's stay here and take a couple of STIR/SHAKEN questions now. So, who is signing my calls? Who can give me a STIR/SHAKEN token or certificate?
Anis Jaffer: That would be the originating service provider. In this case, it would be who is actually placing the call into the network. In most cases where the call originator has a direct relationship, for example, if you are an enterprise who has a direct relationship with AT&T or Verizon and they're originating calls, they would sign that particular call.
But we know that enterprises also have relationships with their reseller, and then the reseller has an upstream OSP, or originating provider, that they work with. In that case, the OSP is the one who actually signs the call, even though you are originating the call through another provider downstream. It depends on where you get the SIP service and how you're set up to make these calls. But eventually, the carrier or the service provider who is enabling the SIP invite into the network is the one who has to sign the call.
Molly Weis: With call signing, let's talk about Attestation. If my provider tells me that they're attesting my calls with A-level but my calls are still being labeled as 'Spam' are those things related? Do they have anything to do with one another? What's going on there?
Anis Jaffer: As we discussed earlier, the labels are assigned at termination so even if the originating provider signs the call, it is possible that the terminating provider is labeling the call as 'Spam.' This could happen if the number itself is deemed as a number that's spamming and it's designated as a spammer. That could happen if a lot of calls are generated, especially short-duration calls.
It could also be that the call got routed to a node that dropped the certificate, and by the time it reached the destination, the flag was lost so at termination the analytics engine is going to do its best to figure out what kind of number it is but if they don't have that in their system as a registered caller, or if that has been flagged as a spammer, then you would still get those labels.
Molly Weis: There are a lot of different factors at play here. This next question asks: Is it possible to get guaranteed A-level Attestation calls on your numbers no matter what? Is it possible to guarantee the level of Attestation you're going to be able to get?
Anis Jaffer: It depends. If the originating service provider knows the customer and all calls are generated on the network, then yes, they could sign the call as A all day long. But for that to happen, the originating carrier or the OSP has to have a direct relationship with the client, and they would have to issue the numbers to the clients. Typically you'd see this in the case of, say, Verizon Business working with Verizon enterprise clients. In that scenario, it would happen.
But if you have a situation where the service provider is working with a reseller that issued the number to a BPO or call center outsourcer who is making calls on behalf of a brand, then attesting level A would be very difficult. This is because whoever is originating the call wouldn't know who the actual party responsible for that content of the call is. In that case, you would get a B, at best.
Molly Weis: That's probably a pretty common scenario, right?
Anis Jaffer: That's a pretty common scenario, especially in contact centers, when enterprises are using other vendors for originating calls with certain CPaaS providers. It's quite common. You also have this other scenario where you could get numbers from one provider and be originating calls using another provider. In that case, the originating provider would not know exactly who issued the number so they would sign the call as B. If a service provider is guaranteeing it, then as an enterprise, I would ask them how it is done, especially if you don't have a direct relationship with them and get into the details a little bit to understand how it's done.
Molly Weis: That's good advice. Let's say I'm a contact center, I've got my brand, I've got my phone numbers, I don't have any spam labels, and am feeling pretty good about that with STIR/SHAKEN and everything is great. Now I want to talk about branding, this is what everybody's talking about now.
When it comes to the presentation layers that consumers can see on their mobile devices, the question is: Is RCD, which stands for rich called data, is this the same thing as CNAM? Is this different or is this the same technology that's going to label calls as 'Scam' or 'Spam'? Is all this related? Is it all different? How does this work?
Anis Jaffer: Good question, let's take it one by one. RCD allows you to add what is called rich call data, essentially metadata that you can associate with a brand name, brand logo, and call reason. Those are all different elements that you can add as part of RCD.
Now, the standard allows this information to be packaged as part of the SIP header and the STIR/SHAKEN standard also allows you to add that as what is known as an RCD PASSporT. This is if the data is added as part of the call meaning it's added along with the SIP header when the call originated. As we talked about before, the STIR/SHAKEN certificate could be discarded or lost along the way so this data may not go all the way to the end. To be fair, this is fairly new, STIR/SHAKEN just got rolled out as well as delegate certificates and RCD PASSporTs are still early and not widely adopted.
In the meanwhile, we have what are called out-of-band solutions. So here, as you would guess, is data that is sent out-of-band, or outside the call. It doesn't go along with the call or along with the SIP header, it goes over the data network and in some cases, the data is sent in real-time.
For example, Google has what is called Verified Calls by Google, which uses an API to register the call. Let's say you are the enterprise and you're trying to reach me as your customer. Right before you make the call to me you would register to say you're going to call this number in the next 30 seconds/minute, and that gets registered into the Google cloud. Then when you actually place the call and I receive it on my handset, now that handset has to be a Google handset with the app-enabled for Verified calls, then Google will pull the data because they already know that you're going to call and they were expecting you to call in the next 30 seconds/minute, they would pull the data and they would render it.
This is out of band, real-time integration where you can actually pass the data. There are other solutions being offered where it is not in real-time where you register your name and logo with the provider and whenever you make the call, that renders. That's the branding that's available today.
Molly Weis: Let's stay on that topic and talk a little bit more about the branding that is able to be displayed on the handset level. How flexible is this? Is it possible to just show a name if somebody doesn't want to show a name and logo, can they choose?
Anis Jaffer: Yeah, there are different options at this point. For the most part, the provider for Verizon is supporting name only, the provider for T-Mobile is supporting name, and then with AT&T you can have name and logo but with the name field for Apple and Android devices, the logo is applicable for Samsung and wherever the Hiya app is installed. There's a little bit of variation on how the branding solution is currently being offered, but to answer your question, yes, you can have just the calling name without the logo. In some cases, you could have the logo, and then in some cases, you have real-time, where you can push the logo and call reason.
Molly Weis: How does that cross over again with the analytics we talked about earlier? Will adding these branded features like name and or logo stop or override calls from being labeled as 'Spam' or 'Scam Likely,' or again, not related?
Anis Jaffer: In most cases, we've seen that it does because the entity is identified ahead of time so they are vetted and the data is updated. When the solution provider or the analytics engine receives the call, they feel confident that the labels can be removed. Again, they monitor other items as well, it's not just this. They also look at other things like the IP or the originating call path so that if it doesn't follow the pattern that they expect, then it could still get labeled. But for most cases, we have seen that once you register with brand information the labels don't show up.
Molly Weis: I think that was a very important element there, the upfront identification of that identity. They need to have that and carriers and the branding providers need to have that confidence in who is trying to push this branding through, because the last thing we want is people being able to use this new technology to spoof a brand that they aren't actually representing and that's a huge concern there, too.
Let's talk timelines and logistics for branding. How long does it take to implement this? There are a lot of different solutions out there, why are there so many? How do I know which one is right for me?
Anis Jaffer: We have different solutions because each wireless carrier has its own vendor that's doing this for them, in addition to device manufacturers/end-device OS makers like Apple and Google, predominantly, which have their own requirements. Apple, for the most part, is right now pretty closed in the sense that you can't push data directly to Apple but Google does allow it through Google Verified.
Each solution requires that the enterprise has to be identified and verified before they can enable branded information and that could take, I would say up to two weeks to get everything set up and running. It's typically four to five days and sometimes as quickly as two days, depending on the service provider. Again, Google seems a little bit faster. The other services take a little bit more setup time.
Now, which one is right for you is very subjective. I would look at other things like who they are trying to call. As an enterprise, who are you trying to call? Look at the target demographics of who's receiving the call. Let's say you're reaching primarily to mobile users, then it makes sense because mobile devices have the ability to show brand information but if you are trying to reach predominantly to landlines, then branded calls may not be that critical.
Also, look at the use case for branded calling. For instance, let's say you're calling for a use case where somebody's expecting the call, like a pharmacy making a call for prescription pickup or a doctor's office for an appointment reminder. For those kinds of things, branded calling helps. But if you're trying to do telemarketing, a sales call, or a debt collection call, I don't think it makes that big of a difference. So in cases where the receiving party is expecting a call, it makes a lot of sense and in cases where the call is for sales or telemarketing, it could help. I haven't seen data that convinces me that once you enable branded calls for these scenarios, it could help.
But what we have seen is the answer or callback rates have gone up. In the case of somebody who's trying to telemarket or upsell a service, whoever you're calling may not pick up the call at that time, but if they see the brand name and logo, they could call you back. What we've seen is those callbacks are typically higher quality because they are initiating the call with a reason to engage and because of that, I would say it helps with brand recognition for sure.
Molly Weis: That probably leads to agent productivity being improved too because if you're getting more of these callbacks, agents don't have to waste as much time trying to continuously try to outreach and get you.
Anis Jaffer: Yeah, we've for sure seen that as well. We always tell clients that enabling branded calls is not going to increase your contact rates right away but there could be other elements that could influence the rate at which they are closing an account or whatever they're trying to sell. So the ROI could be different, you have to look at other metrics in addition to just answer rates.
Molly Weis: Yeah, that's a complicated one to try to decide which solution is right for you, there are a lot of things that go into it. So with the display, we've talked about caller name and we've talked about the logo. How about this last piece of adding a call reason? What is this all about? What can it say? Can it be amended at any time? How does that call reason work?
Anis Jaffer: The call reason is text information that can be used to notify the intent of the call. For example, if it's a doctor's office it can say this is Doctor XYZ's office calling for an appointment remainder. This is part of the RCD information that we talked about earlier, it's part of the standard that's being built. However, the standard is not there yet.
Today, Google allows you to pick from a list of preloaded information, so you could preload five different call reasons, and then you can pick one as you're making the call. But the other providers are still restricting it, it's pre-loaded and there is not much flexibility to amend it. Ideally, in the future, you should be able to attach a call reason for every single call in a customized way using an API, which would be pretty powerful, but we are not there yet.
Molly Weis: Let's take one more logistics-related question. You've shared with us that there are a number of different solution providers and the display is going to be different based on whether you're calling somebody who's on an iPhone or an Android, and there are a lot of different little nuances.
If I'm thinking about implementing this, how do the logo requirements work? Is there a maximum or minimum on image pixel size? Am I slicing and dicing those logos? How is it going to appear on Android versus iPhone? How do I know it's going to look right? How does all that work?
Anis Jaffer: There are some differences. Each solution provider has a slight variance in what they're looking for. Typically we've seen that a 500x500 image works for mobile devices. On tablets, it may not render properly, but I don't know how many people actually take calls on tablets. Typically we recommend 500x500 for the most part, and that seems to fit in.
Apple, as far as I know, what's being supported is if you are calling directly into an app. Let's say you have an app running on a T-Mobile device, then you can push that data to the app. That's what I've seen and the coverage seems pretty limited. For the logo size, you can manage the 500x500 pixels.
Related to this is the caller name and we've seen some difference in that as well. Typically you would have a 32-character limit that is supported for branded calls but Verizon still is limiting this to 15 characters. Because of that, we recommend enterprises use 15 and that's a legacy CNAM character limit as well so they're still supporting that but at some point, I think it would change.
Molly Weis: Have we thoroughly tapped your brain today on all subjects of number reputation, STIR/SHAKEN, and branded calling?
Anis Jaffer: I'm sure there are several questions that will still come up so I think we should do this more often and take these questions and then have a session. These 30 minutes have flown by already.
Molly Weis: I know, it always flies! I want to thank everybody who joined us live today on another great episode of Tuesday Talks. Anis, thank you for all of the information in your brain. We appreciate everybody's support, keep the questions coming, and we hope to see everybody again in our next session which will be on Tuesday, May 24th. Have a great day, everybody!
.png)
