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:danny@itjournalist.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.