Back in the days of circuit-switched networks, when the only type of electronic communication you would undertake was a telephone call, it was much easier for one device to connect to another.
Dialling a phone number from a dumb endpoint (your handset) would cause the number to be routed through the phone network to the right destination. All the intelligence was in the SS7 network at the centre of the conversation.
These days, thanks to the simpler world of converged communications, everything is much more complicated. Now, networks and devices are supposed to cope not only with telephony, but also with instant messaging, videoconferencing, application sharing and whiteboarding.
Consequently, PCs and specialist videoconferencing equipment have joined the traditional phone handset, alongside smartphones, which are as intelligent as PCs were 10 years ago. They are all expected to work together, often behind a firewall or network address translation box, and all using IP.
This is why the Internet Engineering Task Force (IETF) developed Session Initiation Protocol (SIP). Initially developed as a standard in 1999, SIP handles the initial conversation between devices, enabling them to carry out operations such as discovering a device, inviting someone to participate in a session, communicating a device's availability, and defining what type of session it is.
SIP does not communicate the session's content. Other types of protocol are used for that, such as Real Time Protocol (RTP), which handles issues such as quality of service monitoring. SIP is all about control.
One of the nice things about SIP is that it uses an easily understandable address (normally an e-mail address) to identify an individual. For example, this writer's SIP address might be sip:email@example.com. This being the case, you would think everyone would be using it by now, but most business cards are still depressingly SIP-free.
The problem is that historically, interoperability has been an issue as different equipment suppliers have implemented their own flavours of SIP. However, thanks to co-operation and programmes such as Sipit, the interoperability testing initiative for SIP equipment, such problems are rapidly disappearing. However, other more difficult barriers remain.
"It is on the network operators' side. While e-mail and instant messaging became prevalent quite quickly it was because they were easy for people to integrate into daily life," said Robin Russell, director of product support at business phone system supplier Inter-Tel. "SIP is a different matter. It relies on the network having a good infrastructure, and they are slow to respond."
Although instant messaging caught on quickly, in reality e-mail took years to become popular. It first appeared as the internet did in the 1960s and did not become a popular way of sending communications between companies until some years after the X.400 and SMTP standards were developed in the 1980s.
Until that point, e-mail (where it existed at all) had been isolated inside companies. To a certain extent SIP has a similar problem: companies that use the technology often restrict it to use within their own networks. That makes it useful, for example, where you have a company with many different branch offices or retail outlets, but it is useless for dialling out to other SIP users.
Part of the problem, according to Andrew Storms, director of IT at risk profiling service company nCircle, is that SIP and network address translation (NAT) do not sit well together. A SIP client uses its own IP address, but a NAT box or firewall will present a single corporate IP address to the outside world, making it difficult to get SIP handshaking working across corporate boundaries.
The solution is to use some sort of proxy server. SIP-aware firewalls (also known as application layer gateways) and session border controllers are available from various suppliers to solve the problem, but they have their own drawbacks (see box).
But once you have solved the problem of getting your SIP traffic in and out of the network, where is it going to go? For SIP to be truly useful across company borders, it must be more pervasive. But as yet, it is difficult - sometimes impossible - for SIP users to easily "dial" a SIP address outside their own companies.
Ideally, you should be able to dial someone's SIP address and have it ring their phone, even if that phone is a dumb handset connected to a traditional PSTN network.
Paul Mockapetris, chief scientist at Nominum, which sells IP address management systems, hopes this will happen. "It is getting to the time when we have a critical mass of these systems and what we expect is that the people buying them are going to start insisting to the suppliers that they want interoperability," he said.
The solution could lie with electronic numbering (Enum) - a set of IETF-defined protocols designed to map traditional phone numbers to SIP addresses. Enum uses DNS, the same system that finds the IP address underpinning a web URL. Ideally, telecoms firms would use Enum in their networks to map a phone number to a SIP address, meaning that you could make a SIP call across a conventional phone network.
"What it lets you do is essentially get SIP connectivity in a situation where the only thing you have available is a phone number," said Francois Audet, an architect in Nortel's enterprise multimedia solutions group.
"It allows what people refer to as a toll bypass, where a SIP PBX could reach a phone number without going through a traditional phone network."
Austria is the first country to use Enum for commercial services. But outside Austria, Enum is still in the trial stage. A UK trial ran from 2002 to 2003 and experienced problems. These included difficulties with validation and authentication of registered SIP addresses, such as how to easily verify a consumer's SIP credentials for the registry, or what happens when more than one person in a house shares the phone.
But then, identity verification issues permeate the SIP world not just at the level of Enum registration, but also when originating calls. Spammers spoof e-mail addresses by inserting false "from:" addresses.
"We really want to ensure that we do not end up with the same problems with SIP," said Audet. There were some provisions for this in the original SIP specification but they suffered from the same problems as S-Mime did in the e-mail world, he said; they simply were not intuitive to implement and use.
The IETF is working on a SIP identity specification that will help to prove the validity of an originating SIP caller.
"It works by trying to provide a strong defined identity. If I want to phone someone, I prove to my company that I am me in the same way that I log in to get my e-mail," said Cullen Jennings, a Cisco engineer who helped to write the SIP identity draft.
You would do that using a company password. "Then Cisco asserts to the rest of the world that it is me, and certifies that they are Cisco using the same certificate that they would to run their Cisco.com website," he said.
Cisco is no stranger to VoIP. It has worked closely with the standards bodies, said Jennings, but SIP is only just emerging as a standard with enough functionality to replace a standard PBX for many Cisco customers.
For this reason, the company has been using its own Skinny Client Control Protocol (SCCP), which it acquired along with Celsius in 1998. Call Manager, its Windows-based VoIP server, communicates with Cisco's own SIP phones via SCCP, but can then talk to the rest of the world via SIP.
As the interoperability problems are resolved, so SIP's ubiquity will increase. A driving force behind it may be the ability to make presence information available across different communications media, said Steve Blood, an analyst at Gartner. "We are making it easy for people to contact us but not making it easy to manage that," he said.
When you are on a conventional phone call, unless you manually change your instant messaging status you may be interrupted by colleagues. "SIP enables you to manage communications more effectively. If you are on a phone call then that could be displayed in your instant messaging client," said Blood.
Similarly, a unified SIP system could enable you to more easily set rules about your incoming communications. Perhaps if you are on a SIP call to the boss you could set your system to block all incoming communications, unless it was from a child or spouse.
The presence information contained within SIP is one element differentiating it from H.323, which is still the industry standard for much VoIP call control and traffic forwarding. Whereas H.323 handles call control, it provides no presence information. If presence-based communications and applications take off as much as Blood would like, H.323's limitations will rapidly become clear.
There is still a long way to go before SIP becomes ubiquitous in the corporate environment or becomes the primary way of communicating via the phone, if it happens at all.
If it ever transpires it would be a true "killer app" and would turn the world of telephony on its head. Alexander Graham Bell would surely have approved.
How to get disparate systems to communicate
Cullen Jennings, an engineer at Cisco, outlines some of the problems that arise when using a proxy server to address conflicts between SIP and network address translation (NAT).
A SIP firewall generally looks at the SIP traffic and modifies the ports and addresses used by the SIP session to work with the network address translator. Session border controllers (SBCs) work by terminating the SIP session on one side, and reoriginating it on the other so that the SBC serves as a proxy for the call.
"The problem with SBCs is that they have transparency issues," said Jennings. Because SIP covers different kinds of communications media (which could expand in the future) it can confuse SBCs, which are not programmed to deal with them.
There are alternatives to these systems. The IETF has been developing a standard called Interactive Connectivity Establishment (ICE) to help bridge SIP sessions across NATs. This in turn relies on two other IETF drafts. The simple traversal of UDP over NATs (Stun) tells a host the public IP address and UDP port that it is assigned to so that it can communicate that to another SIP and point when initiating a call.
The alternative, traversal using relay NAT (Turn), lets a host contact a central relay, which then sets up a SIP session between itself and another SIP endpoint. Because its use of a central relay can create more router hops for a SIP session, Turn can suffer from quality issues and is generally only for use with network address translators that cannot support Stun.