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,
Connection is easy, "me" contacts provider A with "firstname.lastname@example.org.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 "email@example.com.A.com" for real-time communications.
If instead we have
and I try to connect to you, nothing happens. Because "firstname.lastname@example.org.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.
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
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 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
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.
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.