SIP revolution, massively delayed — but there's hope

The SIP Center asked for an article which I finally wrote the weekend before last.  My article was actually rather negative, but they published it anyway.  Now I'm feeling a little guilty as there is an optimistic note I could have used as my conclusion.  So let me try again...

First let me summarize my problem.  When SIP emerged in 1996, it's support for direct connections from one user to another was extremely compelling.  This was the VoIP protocol which would lead to a complete revolution in communications.  Yes, you might refer to a directory service, but you wouldn't need an operator to make a phone call.  You could do it yourself, directly.  Unfortunately, that revolution never happened.

So far, no revolution

The biggest change in telecommunications in the past 12 years has been the global deployment of three billion mobile phones, all based on conventional circuit-switching and Intelligent Network technology — nothing to do with SIP. And arguably, the most interesting telephony service enhancement, after mobility, came from Skype with its seamless integration of presence, instant messaging, wideband audio and video. But Skype is based on proprietary protocols, not SIP. Finally, VoIP technology has helped drive down the cost of international calling, but using MGCP, H.248 &/or H.323 protocols much more than SIP, at least so far.

SIP has been adopted by PBX manufacturers in recent years, but this doesn’t seem to have changed business practices at all. The IT department still buys the PBX and the telephone sets from a single vendor and then contracts with a service provider to handle calls outside the enterprise.

And then there's IMS

SIP has been adopted for use in the IP Multimedia Subsystem (IMS), but this completely warps the original SIP vision.  IMS is a centralized system — a next generation network for mobile and fixed operators.  It's the complete opposite of the original vision for SIP.

Why have things gone so far astray?

SIP assumed an end-to-end Internet

SIP assumes it's possible to make end-to-end connections over the Internet and therefore a SIP session can know about and use globally valid IP addresses.  That was a naive assumption, even in 1996-1999 when SIP was being defined.  The real Internet contains firewalls, network address translators (NATs) and other "middle boxes."  They are not going away, it's only getting worse over time.  Today, applications must be aware of and able to work around middle boxes and other network problems. 

Many middlebox issues can be overcome with the help of client software and central servers implementing Interactive Connectivity Establishment (ICE), a recently completed IETF proposed standard that in turn relies on STUN, TURN and/or RSIP.  A continuing obstacle for direct user-to-user connections is the need for central servers for STUN, etc..

So it there no chance for the original SIP vision of direct user-to-user communication?

P2PSIP — a reason for optimism

Actually, there is some reason for optimism.  The advent and widespread adoption of Skype showed what was possible and suggested how one might distribute central services among peers, potentially avoiding the need for an explicit service provider.  The past few years have seen rising interest in peer-to-peer SIP which has resulted in an IETF working group under the name p2psip.  Their goal is "to leverage the distributed nature of P2P to allow for distributed resource discovery in a SIP network, eliminating (or at least reducing) the need for centralized servers."

Assuming this is completed (during 2008 & 2009), we'll have the elements with which one could make a SIP-based open peer-to-peer communications system.  It will be interesting to see actual software implementing the ideas of the p2psip group.  We may yet see a revolution!

Comments

[Aswath Rao]

In the SIP Center article you state: "...with IMS there are no direct peer-to-peer connections. Instead everything is mediated by a service provider." SIP was coopted not by IMS; I contend that the originators of SIP contrary to their stated claim focused only on a service provider model. If you do not believe me, just look at the call model. As far back as 1999, I have done P2P calls using NetMeeting. So H.323 is not fatally flawed. SIP and H.323 have the same problems - directory service and NAT traversal. At the same time P2PSIP is a false promise. In my opinion it is better to focus on developing micro directories and micro ICE servers.

[Brough Turner]

Aswath, I agree that H.323 was peer-to-peer long before SIP existed, but it also suffers from NAT. I also recall that H.323 was adopted by the ETSA TISPAN group, at least initially, although I didn't follow that effort closely. I assume they did to H.323 roughly the same as happened to SIP.

You may well be correct that SIP was cooped from its start. My limited exposure was a half-day meeting with Henning Schulzrinne sometime in the 90s (after 1996 and before SIP's adoption in 1999). My impression from that meeting was that Henning was concerned that SIP be able to support various existing telephony services, but he was still committed to SIP being a peer-to-peer protocol where directories were a convenience, but a central service provider was not required. Obviously between 1996 and 1999 there were many people involved in ietf meetings, including many from the PSTN camp. I only attended 1 (or 2?) SIP meetings during that interval, so I'm not a good source on what really went on.

I'm curious about micro ICE servers? Run by whom? As I understand ICE, it still requires STUN and TURN servers in the cloud and may require relay servers (also in the cloud) if both parties are behind particularly egregious NATs. As a side issue, the P2PSIP group appears to be addressing this but I'm afraid my information here is also second hand as I'm not active in P2PSIP either. :(

I dont think the problem has anything to do with NAT or STUN or ICE or anything technical. Other than Skype, all commercial VOIP is built on SIP today, so these vendors are already dealing with the NAT/firewall issues. I think, on this point, Aswath and I agree. However, I dont believe there was a conspiracy at the IETF level (if thats what is being said). But in the end, the IETF, nor any standards body, decides what happens in the real world - those who spend money to push their products into the market define the landscape, in practice.

In this case, they decided to keep SIP behind the scenes. While it is used to enable the service, it is hidden from the customers, and therefore SIP to SIP has made no ground.

We saw community leaders and even open-source leaders embracing these closed solutions like Skype and Vonage when they came out. I dont know why there was no backlask from the community and almost no grassroots effort to push open interoperable SIP or to force providers like Vonage, that already used SIP, to expose it to end-users. But frankly, those community leaders should be ashamed and the VOIP userland is the worse for it.

[Dan Wing]

RSIP (RFC3103) is an experimental specification and not part of the ICE/STUN/TURN NAT traversal story.

It is true that STUN requires a server be available on the Internet. But the same is true of DNS, SMTP, HTTP, and SIP itself. Because a STUN server maintains no state whatsoever it is easier to run than a server running one of those other more commonly-known protocols. Some SIP servers run a STUN server on the same hardware or on the same port as SIP; see draft-ietf-sip-outbound.

[Brough Turner]

Dan, thanks. You are absolutely correct that RSIP is completely independent of ICE. I last looked at RSIP many years ago (2001 or 2002?), so I'm not sure what I was thinking of when I wrote that. The other perhaps remotely relevant item (again, not required for ICE) is the COMedia drafts which eventually generated RFC 4145. I haven't followed this in detail, but I have seen Comedia (draft 04) implementations included in commercial gateways.

Whether STUN servers become widely available because of P2PSIP or a SIP hardware vendor sponsors open STUN servers or something else happens, I'd love to see STUN servers as widely available as those for DNS or SMTP. As long as the STUN servers as associated with specific SIP telephony service providers (the most common case today), SIP looks like a telephony service not a web service. Oh well, I can hope...

[anon]

i really do not see skype's success related to presence, IM or any of the other things mentioned. they have simply had absolute rock bottom pricing when compared to the other competitors anywhere close to there scale.

the vast bulk of user want as close a duplication as they can get to there POTS line; at the cheapest possible price. SIP based services like vonage and packet8 may be closer duplicates; but skype has lower pricing. therefore the draw of customers.

[David A. Bryan]

Glad to see the interest in P2PSIP (I wrote the first IETF draft and academic paper proposing the idea, chair the P2PSIP working group over at IETF, and run the community site P2PSIP.org, so I have to admit I am biased toward P2PSIP up front -- thanks, and I love seeing coverage of the work!)

A few quick comments to share:

* Answath mentions "micro-ice" clients, and thinks that P2P won't solve the problem, but I think that the perfect location for these kind of devices is in the peer -- the peers help form a network of devices that can assist with NAT traversal. ICE is quite good reducing the need for relays, but in a P2P environment, some peers will be able to serve that role when needed. This is of course a statistical solution -- you can't have an cluster where ALL the peers are behind "bad" NATs.

* The P2PSIP WG is planning to use the ICE methodology. The idea is to embed ICE capabilities in some devices, however a provider could also provision stand-alone servers as well. One key thing to remember is that P2PSIP isn't just about having every peer in a big global cluster (although that is one application many of us have interest in). We also envision using P2PSIP in small clusters, such as an enterprise, among a group of friends or family, or even in the developing world in an isolated network. There will be many (interconnected, hopefully!) small clusters. Therefore, a carrier using this as infrastructure might provide the servers. A global, open "SIP-to-SIP" network would likely use the peers themselves. You can see some of the (many) ideas for how to use this that have proposed in the WG documented here: (very skeletally! This is document is more of a list of brainstorming ideas from the group collected by the editors than it is a real draft.)

http://www.p2psip.org/drafts/draft-bryan-p2psip-app-scenarios-00.txt

* There are actually a number of implementations out there today. Technically speaking, all are pre-standard, since we don't have an RFC yet. Some are open source, some commercial (in full disclosure one of the commercial companies listed is my company). We keep a list of all of them at P2PSIP.org, and there are more everyday:

http://www.p2psip.org/implementations.php

[Brough Turner]

David, Thanks for those pointers. I am personally very interested in several aspects of P2P infrastructure and P2PSIP, and especially in efforts that would facilitate ISPs making connectivity information available so P2P systems can optimize latency and minimize their impact on cooperating ISPs. From a quite look at the P2PSIP mail archives, it looks like there is a ton of interesting work going on. On the other hand, I don't currently have the time to participate or even to follow the mail list. Hopefully that will change but, for now, thank you and keep up the good work!

[Brough Turner]

Anon, I'm sorry I wasn't thinking about the low cost of using SkypeOut and SkypeIn. I started using Skype before SkypeOut or SkypeIn existed. At that time the #1 reason people were adopting Skype was that it "just worked." Subsequently, a lot of people found value in using Skype as an IM system and in using Skype's IM to coordinate voice cconnections (Skype-to-Skype).

I still make more Skype-to-Skype connections than I do SkypeIn or SkypeOut, but that's just me -- one isolated case. It would be nice to see survey data on a cross section of Skype users -- what they use the service for and why. But, unfortunately, I can't recall seeing anything like that.