Pierce Gorman: Welcome to Tuesday Talks, a live discussion series where we bring truth and shed light across the brand identity, and communications industry. I'm Pierce Gorman, Distinguished Member of the Technical Staff at Numeracle, and today I'm joined by a fan favorite, Brett Nemeroff, Vice President of Engineering for Voice. Brett has a rich track record of architecting and implementing cost-effective telecommunications networks. With extensive experience spanning TCP IP networking, fiber optic networks, integrated billing and provisioning systems, and high-volume custom VoIP software development, Brett brings a wealth of knowledge to the discussion today. You may also remember Brett from our two-parter on third party call signing. Today, he's back to dive into the world of CNAM and Caller ID. Welcome back, Brett.
Brett Nemeroff: Thanks Pierce, good to be here.
Pierce Gorman: Well, it's good to get together on such an exciting set of topics. Caller Name and Caller ID. Now, the way we originally wrote this was "CNAM" and I thought, well, people will be questioning what CNAM is. They may not have heard of that. They might have heard of Calling Name and they've probably heard of Caller ID and maybe not understand the difference. Is there a difference? Are these the same thing? We'll jump into that. I will say that CNAM is an abbreviation for Calling Name. It's a service that's been around for quite a long time. I think it started back in the nineties, and I know that historically, it was created by the incumbent local exchange carriers, so the R Box. They had subscriber-- or do still have subscriber-- databases, and they had the names associated with those lines. So, they were able to create what they called line information databases that would give them the resources they needed to be able to present a name. Now, they could do it for calls that originated and terminated on their own switches, but when it happened across the network, then there needed to be another system put in place. Bellcore, which is now known as Ericsson, used to be Telcordia, was the resource for doing that. I'll mention that there are two ways that Calling Name is typically done. There's a database that gets dipped, or the Calling Name can be put into signaling. We'll see that same kind of architecture over and over again by looking at the past architectures, the current architectures, and the future ones. I'll mention that Calling Name is not something that is universal to the global world of telecommunications. It's primarily something, as far as I know, in the United States and Canada and not so much internationally. In preparing for this, I was thinking about why it's only in Canada and the United States. It was interesting, and even just between those two, they did it differently. Because, of course, if there are only two, there are two ways to do it. It's going to get done differently in both. So, the United States uses the dip into the database, and Canada actually puts the Calling Name into a parameter within the SIP invite or within the generic name parameter if it's signal in SS7. In the international situation, it occurred to me that it's more complicated. Can you put together a big database that has all the names that you need? What do you do for international character sets, and how would you pay for them? Those have inhibited a more general use of Calling Name or CNAM as we know it here in the United States. Then, looking forward, we can see the way that the information is made available and the way that it's transmitted. And when I say made available, either stored or sent in signaling, those are evolving too, as our signaling systems, specifically STIR/SHAKEN call authentication, are evolving as well. Brett, I'm going to take a pause there, and I'm going to ask you what comes to mind when you think about Calling Name. What is it you think that our customers are interested in knowing about Calling Name?
Brett Nemerof: Well, Pierce, you bring up some interesting points. And the things that we really need to highlight is how the information gets there and who has the authority to provision that information and to display that information. When you talk about how things are done differently internationally, we think about places like Canada where they kind of expect Caller Name information to be transmitted with the call from the originator. But in the United States, when we use the Line Information Database (LIDB) and CNAM dips, that information is placed there by the terminating service. So, there are a couple of different ways that it's done. Overall, I like to think about how all of this happened, how it actually works, and who actually has the right to do this. When you think about it, we've got this database of phone numbers and names. Should a central authority be responsible for keeping track of that database? And if so, who should that authority be? And should anyone be allowed to say anything in that database? Should I be able to call myself whatever I want, or should I have to prove who I am? There's a lot of these "should haves" and all this, but it's interesting to talk about how it actually works. I think for us to really understand how it works, we have to understand where we came from, right? So, I just want to touch a little bit on the past of Caller ID. Now, you mentioned that Caller ID as we know it didn't really come out until around the nineties or so. Keep in mind that prior to 1996, when competition was introduced into telecommunications, it was pretty much just the phone company that was managing CNAM. Because of that, you had one company with one method and procedure for putting names and phone numbers into this database. After 1996, when competition was opened up, there were a lot more companies that were participating in this database, and there wasn't a single set of standards and procedures. For example, if I want to call myself something else, what information do I need to prove who I am? In addition to that, before the advent of Voice Over IP and communications over IP networks and all this, it really was the Line Information Database (LIDB). Really, what we're talking about when we talk about a line is those copper cables that come into our houses that used to actually be attached to the telephone. Because of that, it was hard to spoof somebody else's phone number because you would have to be physically attached to their copper as well because phone numbers used to be associated with the line itself. In fact, Caller ID was actually referred to as Caller Line Identification at some point. With the advent of IP communications and all of that, it's not really associated with the line anymore. Additionally, people really got used to trusting names because the names were provisioned by the phone company. Put yourself in the shoes of folks 20 years ago when you were actually taking a look at the Caller ID box the very first time you got Caller ID. You looked at that, you saw someone's name when they called, and how amazing that must have been when you first got it. People learned to trust it because it was this brand-new information that the phone company gave them. But very quickly, telemarketers learned to abuse that approach and it did not take us long for consumers to stop trusting that information.
Pierce Gorman: I'm going to interrupt right there because I remember a story talking to my younger brother who had met this fellow working on this technology back in the eighties that we now call Auto Dialers. I thought, well, that's really going to be annoying because we'll just be getting these calls like crazy. Then, when Calling Name came out, I was so excited because I thought, Aha! I'm going to see the name I'll be able to recognize that it's a telemarketer, I'm not going to answer that call anymore. Well, that worked for a bit.
Brett Nemeroff: Yeah, it worked for a bit, but the telemarketers are a clever group and they have to be clever, right? Because their whole business is about getting people to answer the phone.
Pierce Gorman: And obviously, there's a lot more than telemarketers that are making calls. We want the calls from CVS, we want the calls from Home Depot. It's important to be able to get that information, right?
Brett Nemeroff: But one of the things that is not easy to transmit or easy to analyze on the call is the intent of the call, right? And that's something that Caller ID never really transmitted. In addition to the intent not being transmitted, there has never been, in Caller ID, any sort of standards for ensuring that bad information doesn't get put in there. In addition to that, as you were saying, there's a number of databases out there that store Caller ID information. So, there's not just one database, there're multiple. And they have to be synchronized. And those synchronizations don't always happen reliably they don't always happen at the same time. You might set your Caller ID name to a particular name, but the old name that used to be on your number, for example, if you just got a number provisioned for you, it might still be sending the old number. And these are common pitfalls and problems. I kind of go back to the original question that I asked, who should be responsible for collecting this information, storing this information, and transmitting it? Now, what we have today with the AEs, the Analytics Engines, right now is these are companies that are working very closely with the terminating service providers. And what they do is they take a look at the phone number that's arriving at the terminating service provider, and they match it up in a database. Then, right before the last mile, they'll change the name to something that they feel is reliable, and they'll send it on to the customer, and they'll present that name to the customer. The question is, though, should they be allowed to do that?
Pierce Gorman: Well, let's be specific here. I want to make sure, because you just said that the Analytics Engine providers, and no secret, the main three for the main three mobile providers are Transaction Network Services (TNS), Hiya, and then First Orion. What you said is that they look at the calling number information that's coming in on the signaling, and then they make a decision about the name that would go on there. And I would say, yes, you're right, but maybe you're not entirely correct. There are independent processes going on, for sure. The Analytics Engine providers are looking at those calling numbers and making a decision about whether something is going to show up in the name display of a mobile device. But they were providing a calling name service as well as the Analytics Service to protect people with the scam shield. The "Scam Likely" labeling, in which case, what I think you were saying is the name can be changed by the Analytics Engine provider, not from the name that was provisioned and that somebody paid to have provisioned or that somebody was paying to have displayed, but changing it to something like "Scam Likely."
Brett Nemeroff: Yeah. And the reason why I asked is because they're assuming that the phone number that came in is the actual phone number of the person who's calling, right? So, in today's world, I could make a phone call and spoof my originating number and actually trick the AE into replacing that name at the last mile. There's nothing that does that. Now, you might be saying, well, hold on a second, STIR/SHAKEN prevents spoofing, right? Now, if you've been watching our Tuesday Talks podcast, you'll see we've had this discussion a number of times. STIR/SHAKEN does not prevent spoofing. While a lot of people say that the intention is to prevent spoofing, it really isn't. The reality is that there's plenty of spoofing that happens in the network that is completely legitimate spoofing. We don't want to get rid of it. It's totally legal. And a quick example of that is when my kids school calls me to tell me that after school activities are canceled because of weather, it's not the school calling me, it's some third party service that's calling me that's pretending to be the school so that I'll know that the school has a message for me. And that's totally legitimate.
Pierce Gorman: Right.
Brett Nemeroff: And this goes back to what I was saying about intent. There's no way to transmit the intent, and there's no way today to know, necessarily, if the phone number that's being transmitted is the number of the actual originator. So, the question that I like to go back to is who should be responsible for transmitting the identity of the caller? Should it be the terminator who's using this potentially wrong phone number information to put that name on? Or should it be the originator who has no technical mechanism to prevent them from lying about who they are? Now, one of the things that, if you've followed some of my other talks about CNAM, you may have seen is that I had this incident where I actually received a call from somebody who changed their Caller ID Name to Darth Vader. This is just an example of something that can really be done. That really did happen to me and when I spoke to this guy, he just explained to me that all he did was log into his carrier's website and change his name. He didn't have to upload a photo of his driver's license or anything like that. I think that that's a fundamental challenge that we have in the network right now is, where should this information come from?
Pierce Gorman: Yes and you point out that STIR/SHAKEN doesn't really prevent spoofing. Certainly it's been sold that way and it was an intent, I'll say that. I'll even make a little pitch for STIR/SHAKEN, even though it's somewhat of a side because it is important to talk about this technology in relation to calling name as it's evolving. And as far as the Spoofing was concerned, the idea was that if you provided good enough information, that if the number was spoofed and it was spoofed enough by a person who was trying to cause problem or company trying to cause problem, you're going to have that identity information available as a one-off. It's sort of a penultimate idea of identity in that the originating service provider, who's probably not the one who's making the illegal robocalls is going to be the identity on that call. So, there would be accountability even if you didn't prevent spoofing. The idea was that if you had enough accountability, enough enforcement, then illegal spoofing would stop. Obviously, there is a mixed result so far in our journey here on STIR/SHAKEN, but that was the idea. In the future, the idea of being able to have a usable identity, authenticated and verifiable, cryptographically verifiable, that's important. You use the term "identity," and I think we should talk about that a little bit because you mentioned the Darth Vader example and being able to log in and do that. Now, I remember reading years ago the guidelines that were written for calling name as it was originally proposed within the Bellcore system. And one of the things you weren't supposed to be able to do was use fictitious characters or cartoon characters and Darth Vader would be an example. So there's an example where one of the databases that was being used to control the information did not have an edit mask in it to be able to look for that kind of a misuse of the information. Maybe nobody ever thought to put Darth Vader in there to look for Vader or variations of it. So, it's not exactly like it would be easy and it's not exactly like you're going to have people using personal labor to look at all of that information as well. But you mentioned identity and you had an example that we talked about in preparation for this show that I really liked. I'd like you to kind of walk through your thought about, okay, now you've got a name, but is a name enough? Is it trustworthy? What are we really doing here?
Brett Nemeroff: When I think about STIR/SHAKEN and the presentation of identity, I like to compare receiving phone calls to people showing up at your house. If you think about it, it's kind of in the same way, right? Is if you have a stranger that shows up at your house and you don't know who they are, and you have to decide whether or not to answer the door, it's very similar to receiving a phone call and choosing whether or not to answer the phone.
Pierce Gorman: Right.
Brett Nemeroff: When somebody shows up at your house and you open the door, you're not going to ask them what their address is, where they came from, right? And this is what a phone number is. What is a phone number? It is an address. It's how to get back to somebody. That's really the only thing that it is. I know a lot of people like to call it an "identity"-- Caller ID and all of this-- but it's a mistake to consider it an identity. Just think about how many businesses out there, especially call centers, legitimate and illegitimate, they'll buy a phone number and within five minutes, they'll start using that phone number. Phone numbers are ephemeral resources. Identity is not ephemeral.
Pierce Gorman: Right.
Brett Nemeroff: I think it's really important that when we think about proper solutions to this particular problem, we think about proper identity. What is a proper identity? Somebody showed up at the house and they showed me a crayon drawing of themselves with their name written under it and say, "Really, this is me." I probably wouldn't believe because it's ridiculous. There's nothing about that that's believable. Even if it was a particularly good drawing of themselves, I still probably wouldn't trust it. Now, if they showed me a government ID that was from the same state that I'm a resident of, and I recognized it as being a proper government ID, there's more of a reason to trust it than the crayon drawing. There's a psychological process here to us applying trust to something that we see. The same thing applies to Caller ID. At some point, we said, Caller ID is something given to us by the phone company, and it had some weight to it because of that. Now it's been abused, and Caller ID is effectively identity written in crayon, and that's what's showing up on our phone. We don't trust it. Nobody trusts it. Whoever you see on your phone, even if it says that it's the school down the street, it's not necessarily accurate anymore. What we can do to change that is finding some way of linking actual identity that can be verified, cryptographically, like you were saying, Pierce, into the phone call and transmitted across the line. Personally, I believe that the only way that we can do this with any amount of reliability and to be able to restore trust to the PSTN is to have an identity that can be cryptographically identified, transmitted from the originator, because, after all, only the originator knows who they are, and then transmitted to the termination. Then, the termination needs some way of verifying that that identity is, in fact, real-- that there's a reason to trust it, right? Just because I have information doesn't mean that I trust that information. There needs to be a reason given to trust and then there needs to be the verified way of trusting 100%.
Pierce Gorman: I wanted you to share your example again because I like using real world examples for people to think about identity and trust. Your example of somebody coming to the door and having a crayon drawing of themselves is perfect. The example of having a government issued identity card is also perfect because we mostly trust our government. We and companies will trust the credentials that are issued by the government. That's not just an identity, it's an attribute associated with that identity. It's something that they have that tells you more about them than them just asserting that their name is Darth Vader or whatever their name happens to be. It's those real world examples of trust attributes that are issued by real world. Organizations could be... My favorites that I always roll out are the government issued licensing and then also for corporations, people that are making calls is insurance and specifically security bonds because it's a source of trust that somebody else did the Know Your Customer (KYC) upfront work to make sure that that company was trustworthy enough to be insured. If they can't get insurance, then that's a pretty good sign that maybe you don't want to take that communication. We've talked about Calling Name (CNAM), what it was historically, why it had some trust, why the trust was eroded, and we've talked about STIR/SHAKEN and cryptographic verification of the identity. Not so much trust attributes, those don't really exist in a way that would be useful for knowing the caller. It's useful for knowing the caller's service provider, or at least the service provider that put the cryptographic credentials in the call/signed the call, but I think you and I believe that there is another layer of identity, the actual caller themselves, which is what's supposed to be represented in Calling Name (CNAM), that we're going to plumb and make work better with call authentication technology. That's sort of the future of things. We've talked about that future before and the signature type that would be carrying that name information, and additional information such as the company logo and maybe their reason for calling as Rich Call Data (RCD). There's a standard that's just about ready to issue from the Internet Engineering Task Force on Rich Call Data that says there's more than one standard, but there's one main standard that talks about the information that would be encoded and transmitted on the wire. Do you want to describe a little bit of what you see there for the future, Brett?
Brett Nemeroff: Yes, so in my best estimation, it's a new vehicle for transmitting identity information or identity metadata. When we take a look at Caller ID, the way that we think about it from back in the 90s, we think of a pairing of phone number and name. As we moved into the world of VoIP, very easily we had a display name that was attached to the from field. Then ,we realized that sometimes who's making the call and what we want presented would be different. So, we moved on to add Remote Party ID or RPID fields, which gave us the ability to not only have a from, but also have a presentation name attached to it as well. And then, we migrated that from RPID to PAID or P Asserted ID, where now we also have the mechanism of saying, "I'm going to tell you who I am, but I don't want it to be presented, I want it to be private." Now, we have RCD. RCD is a huge step forward when you think about all those previous incantations of identity, it's always number and name, just those two pieces of metadata. RCD allows us to be a lot more rich with that data. We can put URLs in there, we can put J cards in there, we can put icons in there. There's a lot more interesting information in there. However, for RCD to be useful outside of a campus environment within your own network, it's going to have to be supported by terminating service providers. They're going to have to know what to do with that. But not only that, there has to be a way of saying, this is trustworthy. I didn't just make this stuff up. There needs to be vetting and onboarding and cryptographic signatures to make sure that that data isn't changed from the time that it was verified. So there's a whole ecosystem. Just having RCD is great to have that vehicle, but we need a way of verifying that it hasn't been changed and that it is, in fact, accurate.
Pierce Gorman: It's an excellent point because without all of that additional guide rails, it might just be a more modern version of a crayon drawing, right? So it goes back to it may be good that I can feel confident about your identity in terms of who you are, but as you mentioned before, we can't tell intent and with additional trust attribute information that could be possible. So, those guide rails, that Know Your Customer work, if you have knowledge and confidence in that, that's one of those things that improves that from being a crayon drawing into the government issued identity card. All right, well, we're almost out of time. I do want to respond to the one question we got from David Frankel. And thank you, David, for watching; always appreciate it. You asked about the Calling Name and the myriad of different databases. Then, if you really wanted to be accurate, you'd have to look at at least 20 sources of information. I don't think you meant specifically 20, but as an example. I think your answer's right. And I have a feeling that's why First Orion called their product AccuName, because they were looking at as many sources as they could to find out whether or not what was the true and accurate name to be able to supply to a conventional, nowadays Calling Name Dip. That's a good point. I think it's also to the credit of First Orion that they thought the same thing that you did and went to the extra effort to try and provide that level of accuracy.
Brett Nemeroff: Well, Pierce, I did want to add something on to that, though, in terms of AccuName, and I don't know what's going on under the hood there. Where is the information coming from? And what permitting customers are they fixing the problem for?
Pierce Gorman: Right.
Brett Nemeroff: Because to David's question here, part of the problem that you have is that your originating provider is pushing it into a database, and the terminating provider is pulling it from a potentially different database, likely a different database. So, are those two databases synchronized, and would you ever be able to fix it if you fixed it for one terminating provider? Say you fix it with T-Mobile, would it also be fixed on Verizon? Probably not. You would have to fix it in multiple places. So, part of the problem that we have right now in having multiple centralized databases is that exact problem, right? And I would ask the question, should we allow multiple centralized databases? It has organically turned into that. But the question is, is any of that information good? Could we ever trust it? And should we ever trust it? And I don't think that we should, because I can still transmit a different caller ID number information and actually push that name to show up on the other side. The originator should be forced to identify themselves in a cryptographically verifiable method that can be decoded on the far end and reliably transmitted and presented. Otherwise, you're getting one of 20 potential answers here. I do think it's a big problem.
Pierce Gorman: I agree with you. You're 100% correct, as usual. I think we're pretty much out of time. Thank you very much for providing such an insightful review of things to know about Caller ID and Calling name, Brett. Appreciate it. So, I'll be back in two weeks. I'd like to thank all of you for joining us for another episode of Tuesday Talks. I'll be back in two weeks on Tuesday, September 19th, with our General Counsel and Head of Global Public Policy, Keith Buell, for a SIPNOC 2023 recap. This year's conference focuses on the call and text authentication ecosystem, and our very own Rebekah Johnson will be moderating a panel on the future of end-to-end branded calling using authentication. So we're very excited to report back with key takeaways and tot Takes. Thanks again for joining us, and we'll see you next time!
Brett Nemeroff: Thank you.
.png)
.png)
