Do "smart" parking meters really need phone numbers? Does every "smart meter" installed by electric utilities need a telephone number? Does every new car with a built-in navigation system need a phone number? Does every Amazon Kindle (and similar e-readers) really need its own phone number?
In the absence of an alternative identifier, the answer seems to be a resounding "yes” to all of the above.
SIPNOC 2013 event, U.S. Federal Communications Commission CTO Henning Schulzrinne gave a presentation (slides available) about "Transitioning the PSTN to IP” where he made a point about the changes around telephone numbers and their uses (starting on slide 14) and specifically spoke about this use of phone numbers for devices (slide 20). While his perspective is obviously oriented to North America and country code +1, the trends he identifies point to a common problem:At the recent
What do we use as an application-layer identifier for Internet-connected devices?
In a subsequent conversation, Henning indicated that one of the area codes seeing the largest amount of requests for new phone numbers is one in Detroit — because of the automakers need to provision new cars with navigation systems such as OnStar that need an identifier.
Why Not IPv6 Addresses?
Naturally, doing the work I do promoting IPv6 deployment, my first reaction was of course:
"Can't we just give all those devices IPv6 addresses and be done with it?"
The answer turns out to be a bit more complex. Yes, we can give all those devices IPv6 addresses (and almost certainly will as we are simply running out of IPv4 addresses), but:
1. Vendors Don't Want To Be Locked In To Infrastructure – Say you are a utility and you deploy 1,000 smart meters in homes in a city that all connect back to a central server to provide their information. They can connect over the Internet using mobile 3G/4G networks and in this case they could use an IPv6 address or any other identifier. They don't need to use a telephone number when they squirt their data back to the server. However, the use of IP addresses as identifiers then ties the devices to a specific Internet Service Provider. Should the utility wish to change to a different provider of mobile Internet connectivity, they would now have to reconfigure all their systems with the new IPv6 addresses of the devices. Yes, they could obtain their own block of "Provider Independent (PI)" IPv6 addresses, but now they add the issue of having to have their ISP route their PI address block across that provider's network.
2. Some Areas Don't Have Internet Connectivity – In some places where smart meters are being deployed, or where cars travel, there simply isn't any 3G/4G Internet connectivity and so the devices have to connect back to their servers using traditional "2G" telephone connections. They need a phone number because they literally have to "phone home".
While we might argue that #2 is a transitory condition while Internet access continues to expand, the first issue of separating the device/application identifier from the underlying infrastructure is admittedly a solid concern.
Telephone Numbers Work Well
The challenge for any new identifier is that telephone numbers work rather well. They are:
For all these reasons, it is understandable that device vendors have chosen phone numbers as identifiers.
The Billing / Provisioning Conundrum
The last bullet above points to a larger issue that will be a challenge for any new identifier. Utilities, telcos and other industries have billing and provisioning systems that in some cases are decades old. They may have been initially written 20 or 30 (or more) years ago and then simply added on to in the subsequent years. These systems work with telephone numbers because that's what they know.
Changing them to use new identifiers may be difficult or in some cases near impossible.
So Why Change?
So if telephone numbers work so well and legacy systems are so tied to those numbers, why consider changing?
Several reasons come to mind:
1. Security – There really is none with telephone numbers. As Henning noted in his presentation and I've written about on the VOIPSA blog in the past, "Caller ID" is easily spoofable. In fact, there are many services you can find through a simple search that will let you easily do this for a small fee. If you operate your own IP-PBX you can easily configure your "Caller ID" to be whatever you want and some VoIP service providers may let you send that Caller ID on through to the recipient.
2. OTT mobile apps moving to desktop (and vice versa) – Many of the "over the top (OTT)" apps that have sprung up in the iOS and Android devices for voice, video or chat communication started out using the mobile devices phone number as an identifier. It's a simple and easy solution as the device has the number already. We're seeing some of those apps, though, such as Viber, now move from the mobile space to the desktop. Does the phone number really make sense there? Similarly, Skype made the jump from desktop to mobile several years ago and used its own "Skype ID" identifier — no need for a phone number there.
3. WebRTC – As I've written before, I see WebRTC as a fundamental disruption to telecommunications on so many different levels. It is incredibly powerful to have browser-based communication via voice, video or chat… in any web browser… on any platform including ultimately mobile devices. But for WebRTC to work, you do need to have some way to identify the person you are calling. "Identity" is a key component here — and right now many of the WebRTC systems being developed are all individual silos of communication (which in many cases may in fact be fine for their specific use case). WebRTC doesn't need phone numbers — but some kind of widely-accepted application-layer identifier could be helpful.
4. Global applications – Similarly, this rise of WebRTC and OTT apps has no connection to geography. I can use any of these apps in any country where I can get Internet connectivity (and yes, am not being blocked by the local government). I can also physically move from country to country either temporarily or permanently. Yet if I do so I can't necessarily take my phone number with me. If I move to the US from the UK, I'll probably want to get a new mobile device — or at least a new SIM card — and will wind up with a new phone number. Now I have to go back into the apps to change the identifier used by the app to be that of my new phone number.
5. Internet of Things / M2M – As noted in the intro to this post, we're connecting more and more devices to the Internet. We've got "connected homes" where every light switch and electrical circuit is getting a sensor and all appliances are wired into centralized systems. Devices are communicating with other devices and applications. We talk about this as the "Internet of Things (IoT)" or "machine-to-machine (M2M)" communication. And yes, these devices all need IP addresses — and realistically will need to have IPv6 addresses. In some cases that may be all that is needed for provisioning and operation. In other cases a higher-level identifier may be needed.
6. Challenges in obtaining phone numbers – We can't, yet, just go obtain telephone numbers from a service like we can for domain names. Obtaining phone numbers is a more involved process that, for instance, may be beyond many WebRTC startups (although they can use services that will get them phone numbers). One of the points Henning made in this SIPNOC presentation was the FCC is actually asking for feedback on this topic. Should they open up phone numbers within the US to be more easily obtainable? But even if this were done within the US, how would it work globally?
7. Changes in user behavior – Add to all of this the fact that most of us have stopped remembering phone numbers and instead simply pull them up from contact / address books. We don't need a phone number any more… we just want to call someone, the underlying identifier is no longer critical.
All of these are reasons why a change to a new application-layer identifier would be helpful.
So What Do We Do?
What about SIP addresses that look like email addresses? What about other OpenID or other URL-based schemes? What about service-specific identifiers? What about using domain names and DNS?
Henning had a chart in his slides that compared these different options ("URL owned" is where you own the domain):
The truth is there is no easy solution.
Telephone numbers are ubiquitous, understood and easy-to-use.
A replacement identifier needs to be all of that… plus secure and portable and able to adapt to new innovations and uses.
Oh… and it has to actually be deployable within our lifetime.
Will there be only one identifier as we have with telephone numbers?
Probably not… but in the absence of one common identifier we'll see what we are already seeing — many different islands of identity for initiating real-time communications calls:
And in the meantime, Amazon is still assigning phone numbers to each of its Kindles, the utilities are assigning phone numbers to smart meters and automakers are embedding phone numbers in cars.
How can we move beyond telephone numbers as identifiers? Or are we already doing so but into proprietary walled gardens? Or are we stuck with telephone numbers until they just gradually fade away?
Some additional pointers are worth mentioning:
• The Internet Society (my employer) has a team focused on the broader subject of online privacy and identity (beyond simply the telephone numbers I mention here) and the links and documents there may be of interest.
• There's a new Internet Draft out, draft-peterson-secure-origin-ps, that does an excellent job on the problem statement around "secure origin identification" as it relates to VoIP based on the SIP protocol and why there are security issues with what we think of as "Caller ID".
• Chris Kranky recently argued that telcos are missing the opportunity of leveraging telephone numbers as identifiers in the data world.
By Dan York, Author and Speaker on Internet technologies - and on staff of Internet Society. Dan is employed as a Senior Content Strategist with the Internet Society but opinions posted on CircleID are entirely his own. Visit the blog maintained by Dan York here.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services