VoIP and some agonies of E.164 or, Forward Into The Past!

Does anyone else remember CompuServe accounts, which were all numbers? Mine was 72125,1424. Or ICQ, which was fun to guess just when the other person signed up by the numeric value of their ICQ account. I'm glad to see ICQ is still operating, which maybe I should have noticed before. I wonder if my old number still works?

Now people use names for their email, in a standard and well understood form that works seamlessly between different service providers. Me@example.com is far more understandable than 72125,1424 ever was.

In exactly the same way, it is time to abandon the numbers-only E.164 that still permeates VoIP services when trying to contact someone on another VoIP provider, even if everyone is using standard SIP and no proprietary protocols the way Skype and Google Voice do. But I understand why Skype and Google Voice are doing this, the legal and regulatory requirements (yes, those two are not equivalent) of E911 would make me avoid any possibility of falling under the regulatory scope as well.

Here's how it works now. We register with the same VoIP service provider,

me@sip.provider.A.com

you@sip.provider.A.com

Connection is easy, "me" contacts provider A with "you@sip.provider.A.com" as the connection string, provider A contacts you, SIP (or a proprietary variation) is used to establish the session between the endpoints. We talk, transfer files, use video, whatever we choose to do SIP can facilitate. This is no different than two users of the same email provider sending messages to each other. Unfortunately, this is the limit of being able to use  the address of "you@sip.provider.A.com" for real-time communications.

If instead we have

me@sip.provider.A.com

you@sip.provider.B.com

and I try to connect to you, nothing happens. Because "you@sip.provider.B.com" is not local to my provider, I can't use that format. I or my service provider has to use your E.164 telephone number, if you bought one from sip.provider.B.com, so that sip.provider.A.com can “place a call” across the Public Switched Telephone Network.

This is remarkably wasteful in every way.

There is an effort to use connection strings between people who run SIP servers, that look like *12345, exactly as you would type on your POTS phone to get a special service like conference calling, and then your E.164 number too. All this just to tell sip.provider.A.com that I want my call routed to sip.provider.B.com directly, rather than over the PSTN.

I consider this to be exactly the wrong way to move forward.

Instead, let's have sip.provider.A.com contact sip.provider.B.com in the same way as is done now for email.

Right now, if I want to send email to "you@provider.B.com", provider.A.com takes my message, looks up the mail server for provider.B.com, and if such a record exists forwards the mail on. If no mail record exists in DNS for "provider.B.com" there is an error and my mail bounces back to me.

SIP is just as valid a record in DNS as the MX record is for "mail exchange". Like this:

_sip._udp SRV 0 1 5060 sip_gateway.provider.b.com.

Placing a call then means me contacting provider A, provider A contacting provider B, provider B confirming that you are currently registered and taking calls, and then the SIP session is established between the endpoints.

I found a wonderful graphic here, but you must suffice with just the link until I can find or draw myself something better. Most drawings of SIP signalling look like this graphic from the Wikipedia SIP entry/ Unless you're an engineer all you really need to know is that once established, the media path can be MUCH shorter than the signalling path.

As IPv6 becomes better established and end points, such as your PC or your SIP phone, can be reached from any other PC or SIP phone, this efficiency of data path will make for much greater quality of voice calls.

That's what it's all about, Quality. That's why SIP seems so complex, and people are still using the PSTN to route voice sessions. Your ear can detect problems that email and other file transfers can avoid just by buffering. But anything longer than the ping time from New York to California makes interactive voice range from annoying to infuriating.

Once sip.provider.A.com can routinely and easily establish a SIP session to sip.provider.B.com, the call will not have to cross the constrained, expensive, tightly regulated world of the Public Switched Telephone Network. Once people realize this can work, there is no more reason what so ever to restrain ourselves to the limitation of numbers-only identifiers. And good riddance!


There is no reason why Me@A.com doesn't work for both SIP and email seamlessly since each service is already defined in A.com's DNS file. Established providers that are already doing both email and voice, like Google, could turn this on in no time.

Firewall and NAT Traversal

Unfortunately, the constraints of IPv4 have created a world where human-use endpoints, the very systems upon which we run the user applications, are unable to directly connect to each other. Network Address Translation, Proxies and Firewalls prevent connections reaching systems behind them. Security is dreadfully important, but it is also inconvenient.

STUN nodes, designed to allow easy Firewall and NAT traversal, can use an awful lot of bandwidth.

Skype solved this problem by making “super nodes”, where calls were sent through Skype users who were so lucky, or unlucky, as to have global IPv4 addresses. In effect, Skyped turned your PC into a STUN node. If you search for “Skype is using all my bandwidth”, you can see the kind of reactions this inspired.

This is not a problem that security professionals are ignoring. There is a great deal of work being done to make firewalls “SIP aware” so that the SIP data streams can reliably be connected directly between end systems, but this is not functionality typically found on a $50 home router. At least not yet.

While IPv6 solves this by giving globally reachable addresses to everything, the issue of Firewall traversal still looms. But at that point it's only one problem rather than trying to solve two or three at the same time.

Forward, into the perfectly well known

As SIP is used more and more, the problems that are merely a matter of engineering will be solved. In fact they have been solved if you're in a position to use high-end network equipment.

What is far harder to overcome is institutional inertia. By that I mean the seemingly impossible task of breaking people away from using only the numbers 0-9, * and # in their thinking when they want to talk to someone through a phone.

The objection “But I don't want to have to type a person's whole name in every time!” is valid, but I must ask, just how often do you have to type in a telephone number? Does it matter if the name you select from the contact list on your cell phone or SIP application points to "me@sip.provider.A.com" or 001-83-90-1234-5678? Not at all.

It does matter to those of us who are tasked with setting up SIP VoIP systems, and I will tell you that it is a B*TCH to configure all the crap in the switches to try to figure out just where to send this bunch of numbers THIS time.

And don't even get me started on Number Portability!

So make my life easier, please, and abandon E.164.

Thank you.

Curt-