Various standards organizations have considered
signaling for voice and video over IP from different
approaches. Two of the primary standards in use today
are H.323 and SIP. The International Telecommunications
Union (ITU) established H.323 as the first
communications protocol for real time multimedia
communication over IP. SIP is the Internet Engineering
Task Force (IETF) approach to voice and video over IP.
H.323 is an umbrella standard that provides a
well-defined system architecture and implementation
guidelines that cover the entire call set-up, call
control, and the media used in the call. Whereas H.323
takes the more telecommunications-oriented approach to
voice/video over IP, SIP takes an Internet-oriented
approach. SIP is not as strictly defined as a complete
system as H.323. Many aspects of the SIP architecture
are left open to interpretation. SIP is a text-based
protocol that was designed to work hand in hand with
other core Internet protocols such as HTTP. Many
functions in a SIP-based network rely upon complementary
protocols, including IP.
The different entities that make up an H.323 network
include gateways, terminals, and conferencing bridges,
along with a gatekeeper. The H.323 architecture is
peer-to-peer, supporting user-to-user communications
without a centralized controlling entity. SIP entities
include user agents that may operate as a client or
server, depending on the role in any particular call. A
SIP architecture requires a proxy server to route calls
to other entities and a registrar. All other servers and
parts of the network are undefined and not mandatory for
every call.
H.323 call information is written in binary code,
with a defined set of translations for each code. This
was done to reduce the size of the transmission and save
bandwidth. New codes have to have an agreed-upon
definition between parties prior to a call. The standard
can be updated, but any additions to the standard
require backward compatibility with the existing
standard. Features can only be added, not subtracted.
SIP itself only defines the initiation of a session.
All other parts of the session are covered by other
protocols, which may come from other applications or
functions not necessarily designed for real time
multimedia over IP. SIP commands are coded in text
rather than binary. It's easier to add and understand
these codes, but it does increase the size of messages
that are sent. This text-coding scheme comes from the
Web-browsing scheme, where it has been successful.
Numbers don't have to be allocated to commands for each
message in advance. If text commands are added, the
other side automatically understands them.
SIP is less defined and more open than ITU standards
like H.323, but that can result in interworking
difficulties because of different implementations of the
standard. Every developer may implement their own
version of SIP with unique extensions that aren't
included in the basic standard. Two variations used
today are SIP-T, which addresses SIP telephony, and DCS,
a variation for packet cable voice over IP transmission.
In addition to this, there are numerous proposals for
using SIP for other applications, such as appliances and
instant messaging, each of which have their own
extensions that aren't in the basic standard.
While SIP's openness allows more interoperability
with other protocols, this same openness can lead to
interworking problems because the lack of definition in
the protocol itself means there are a number of
different interpretations, each of which may have
difficulty interoperating with others. In addition, to
date there are more than 80 contributions to SIP, all of
which add to the complexity of interoperability issues. "SIP
Bake-offs" provide vendors an opportunity to test their
products for interoperability. However, as the number of
flavors of SIP implementations increase, together with
increasing extensions, the completeness and
effectiveness of such testing will decrease.
Another protocol often used in conjunction with
either SIP or H.323 is MEGACO, or H.248. MEGACO/H.248 is
the official international standard for decomposed
gateway architectures. The ITU and IETF worked jointly
to define this standard (derived from MGCP). MEGACO
governs communication between a media gateway controller
and a media gateway. This is an internal protocol
frequently used for communication between components
when a gateway is divided into different entities such
as a media gateway controller, a media gateway, and a
signaling gateway. Either SIP or H.323 are used to
communicate with other entities in the network.
Real-Time Protocol (RTP), is used internally for sending
media streams between media gateways. Both H.323 and SIP
use RTP.
Both protocols provide comparable functionality using
different mechanisms and provide similar quality of
service. While SIP is more flexible and scalable, H.323
offers better network management and interoperability.
The differences between the two protocols are
diminishing with each new version. Although there are
numerous industry debates about the merits of the two
protocols, the truth is that both of them, along with
other complementary protocols, are necessary to provide
universal access and to support IP-based enhanced
services.
Interworking Scenarios
Both protocols have been widely deployed, so
interworking between SIP and H.323 is essential to
ensure full end-to-end connectivity. Because of the
inherent differences between H.323 and SIP,
accommodation must be made to allow interworking between
the two protocols. In the simplest scenario where both
protocols are used within the same administrative
domain, call set-up messages must be translated, then
RTP can be used for communication directly between a SIP
phone and an H.323 phone. In this scenario, the H.323
gatekeeper and the SIP registrar perform analogous
functions and share the same database, so it's easy to
find addresses.
The scenario becomes more complex when SIP and H.323
are operating in separate administrative domains.
A gateway is required to translate messages, as well as
information on how to find addresses of destination
endpoints and convert those addresses so they can be
interpreted by the other protocol. For basic calls, this
can be done today; but for more complex calls and
services, problems remain unsolved.
Another issue is capabilities exchange. In H.323,
after the call is set up, the two endpoints "announce"
what capabilities they have for variables such as
compression and video. Because these capabilities are
known up front, if a variable -- such as available
bandwidth -- changes during the call, the call set-up
can be changed in mid-call. This can't be done today in
SIP without initiating a
new call. This is less likely to be a factor in
voice-only calls. For interactive multimedia
communication, the inability of SIP to allow mid-call
capabilities negotiation could be significant.
Security in H.323 and SIP interworking remains an
issue. Because a gateway is required to mediate between
the two protocols, there is no longer a secure
phone-to-phone connection. A new entity has been
introduced between phones and between domains that has
to be considered "trusted" on both sides. Each standard
resolves the security issue in a different way, and
interoperability between security protocols is not
sufficient.
H.323 defines conferencing as part of the standard,
including both centralized and decentralized
conferencing. SIP has no definition for conferencing,
but there is a process within SIP for conferencing that
is similar to H.323, but which has not been formally
defined as part of the standard. Conferencing remains
open to interpretation, with different approaches in
use.
Each protocol handles call set up, call control, and
media in different ways. H.323 defines all of these,
while SIP defines call set up and uses other protocols
for call control and media. Call control and set up are
handled separately from media. This becomes a factor in
interworking with the PSTN, which uses SS7 for
signaling. SS7 can be translated to SIP through a
gateway or softswitch. Otherwise, intelligent networking
services such as Caller ID and call forwarding will not
work with SIP. Because media and signaling are handled
separately in SIP, interworking with the PSTN is often
handled through a separate media gateway and signaling
gateway. That creates a complication in the case of
common PSTN services like DTMF, or touch tones, in which
signaling is carried in the media. There is also no SIP
equivalent of ISUP message transport from SS7.
Here To Stay
Both SIP and H.323 are here to stay. There will very
likely not be a "winner" or a "loser" in the SIP versus
H.323 debate. Both protocols offer strengths and
weaknesses. SIP is extremely flexible and can be adapted
to a number of implementations. SIP allows for the use
of established protocols from other applications, such
as HTTP and HTML. Because these tools are already
defined, it's easier to add applications like instant
messaging or Web conferencing to SIP. For developers,
SIP allows use of a variety of existing building blocks
for applications that will interoperate with other
Internet applications. Meanwhile, H.323 allows better
interoperability, network management, and call control.
Instead of concentrating on one standard versus
another, the voice/video over IP community needs to work
on better ways of ensuring interoperability between
standards to provide end-to-end connectivity throughout
the network and to offer the value-added IP-centric
services that will demonstrate the power of IP-based
communications.
Eli Doron is CTO of RADvision.
RADvision products and enabling technology provide the "building
blocks" needed to enable the Internet infrastructure to
support real time voice and video communications.
Converged services -- we've all heard that phrase. It
refers to value-added services often based on Session
Initiation Protocol (SIP) that combine voice, e-mail,
presence, Web, chat, and other elements. Interesting
stuff -- no doubt -- but what does it mean to the
average man on the street? How does it affect the "regular
Joe" and can it really turn a regular Joe into a shiny,
enhanced, "SIP-enabled Joe?" Let's have a look...
8:40 AM Regular Joe: Regular Joe's day starts in his car,
stuck in bumper-to-bumper traffic. As the seconds tick
into minutes, Joe feels himself tensing. He checks his
schedule on his personal digital assistant, but he doesn't
need to. He knows he has a 9 AM conference call. Joe
picks up his mobile phone and calls the office
receptionist to report his dilemma. The phone rings
several times before the answering machine kicks in. Joe
tries two more times before giving up. At the same
moment, one of Joe's clients calls him at his office
number before leaving on a week-long trip. Because Joe
is not in the office, the client is also forced to leave
a voice mail message.
SIP-enabled Joe: SIP-enabled Joe starts his
day stuck in traffic as well. But when he isn't at his
office phone to take the call, the SIP-enabled service
that Joe subscribes to automatically forwards the call
to his mobile phone so he is able to join in the
conference call from his car. If Joe hadn't answered his
mobile phone, the service would have tried to reach him
via e-mail, his beeper, and an instant message to his
PDA -- maximizing the chances of locating him. This is
possible because SIP-enabled Joe is running a
presence-management application that keeps track of
where he is and how best to reach him. When Joe's client
calls, the service checks Joe's profile and sends an
instant message to his mobile phone. The message
includes an option to immediately connect to the client.
Joe selects this option and he and his client speak in
real time. Now if SIP could only do something about this
traffic!
9:15 AM Regular Joe: Finally in his office, Joe checks
his voice mail and gets the message from his client. In
the message, the client explains that he will be
available for only another half hour then he will be out
of the office for a week. Joe tears through his
business-card collection and dials his clients' direct
line. But he's too late. Joe winces as the receptionist
explains that the client left five minutes ago for
Hawaii and will not be answering his cell phone. Aloha!
SIP-enabled Joe: Instead of wasting time
rifling through business cards to find his client's
number, SIP-enabled Joe quickly selects his client's
name from his Web-based, online directory service. He is
able to phone his client, reaching him minutes before he
leaves on vacation. "Just calling to say bon-voyage!"
Joe tells his client. After all, he has already sorted
out his business issues on the way to work.
9:30 AM Regular Joe: Regular Joe is disappointed by his
missed opportunity, but pushes his frustrations aside
and starts working on a presentation for his afternoon
meeting. However, for the next two hours, his phone
rings off the hook, distracting him continuously and
making it impossible for him to complete the task. He
has call display and he lets some
of the calls go to his voice mail but there are a few
key calls he just doesn't want to miss. Regular Joe is
quickly becoming Angry Joe!
SIP-enabled Joe: When SIP-enabled Joe's phone
is ringing off the hook as he is trying to work, he
simply logs into his desktop-based call filtering
service and configures it to route all calls, except
those from certain clients, to his voice mail. The
service recognizes the profile of those key callers and
routes each one to a personalized message from Joe.
Regular callers hear Joe's usual voice message. In the
meantime, SIP-enabled Joe completes the presentation.
Now it's time to think about lunch.
12:00 Noon Regular Joe: The bombardment of calls has pushed
Regular Joe's work into the lunch hour, forcing him to
cancel plans to meet his wife for lunch at the local
diner. Joe decides to apologize by surprising his wife
with flowers delivered to her office.
SIP-enabled Joe: SIP-enabled Joe also decides
to send his wife flowers but he chooses to take
advantage of the flower shop's "Share the Moment"
service. When the flower delivery person uses his
SIP-enabled tablet to confirm the delivery, Joe's phone
automatically rings. After a short message, he is
connected to his wife and can apologize. "Hi honey. Hope
you liked the flowers. Sorry about lunch." Of course, if
either Joe or his wife had failed to answer their phone,
their respective SIP-based presence management
applications would have located them.
2:00 PM Regular Joe: Joe returns from his presentation
and logs in to his e-mail account. At the top of his
inbox is a conference event notice. Joe makes
a mental note to register but of course he forgets. A
few days later, he learns that the conference is fully
booked. Oh well, probably nothing important anyway, just
a conference about something called SIP.
SIP-enabled Joe: SIP-enabled Joe selects the
link in the e-mail from the conference organizers and is
automatically connected by phone to the conference
office so he can register. The link also launches the
conference Web page in his browser so he can select the
sessions he wants to attend. Done in no time flat!
6:30 PM Regular Joe: Anxious to end his challenging day,
Regular Joe heads home.
SIP-enabled Joe: SIP-enabled Joe is already
having dinner. He left at 5:30 -- it was a productive
day!
When can we all become SIP-enabled Joes? As service
providers begin to deploy SIP-based services, the answer
is "soon." For so many of today's service providers,
competition is cutthroat. The value of dial tone is
decreasing and arbitrage-based opportunities are drying
up. Amongst this growing need for differentiation,
customers like Joe are screaming for more. It leaves
service providers looking at all of the IP-based
infrastructure they have deployed and asking themselves --
where is the money?
The solution begins with the right attitude. An
attitude of value added as opposed to cost reduction, an
attitude of providing something to the end user that is
better and more useful as opposed to simply cheaper. The
solution lies in new business models and new technology --
specifically in new, value-added, converged services
that customers like Joe will pay for.
This means that softswitches, and the application
services platforms that sit architecturally above them,
need to be flexible and robust enough to enable service
providers to develop revenue streams by quickly and
cost-effectively creating and deploying next-generation,
converged services. Service providers need to
differentiate and have the flexibility to build specific
custom services for niche target markets. Take heart
Regular Joes -- your lives as shiny, enhanced,
SIP-enabled Joes are just around the corner!
Martin Sendyk is vice president of product
marketing and general manager at Ubiquity.
Ubiquity's vision is to create the next-generation IP
communication services infrastructure, from the network
core all the way to the customer's desktop. This is
achieved through the development of advanced software
servers and intelligent agents based upon the Session
Initiation Protocol (SIP).
Could A New Directory System Unite
The Many Realms Of Communications In A Single VoIP World?
By GLENN MARSCHEL
The coming of VoIP has been heralded for years, and
lately, there has been real progress in moving voice on the
Internet. Carriers are routing traffic over high-speed IP
backbones, enterprises are upgrading to IP-enabled PBXs, and
some service providers are offering long-distance calling
from the desktop. However, the big cost savings, especially
for enterprises, will only begin when everyday phone calls
immediately pass end-to-end over IP. Standing in the way of
this is a significant hurdle; managing the complexities of
directory systems.
Yet an answer is on the horizon, a means for merging all
communication sources into a single stream. To remember
this, just draw upon the Latin phrase "e pluribus unum"
which translates into "one from many." For IP
communications, think electronic numbering, ENUM, a
development that can bring the many pieces together and
allow VoIP to finally become mainstream.
Most agree that IP is the standard communications
protocol of the future, a foundation for dramatically more
cost-effective business communications. But while packet
technology has matured and lingering quality-of-service
issues are being aggressively addressed, the limiting factor
is the discovery of unknown end points and the complexity of
managing the directory systems needed for point-to-point IP
communications across multiple domains. Unveiled late last
year by the Internet Engineering Task Force (IETF) after
intensive review, ENUM is the technical standard established
to translate telephone numbers into multiple IP addresses. A
key enabling technology for the anticipated convergence of
the public switched telephone network and the Internet, it
paves the way for handling VoIP the same way voice traverses
the PSTN -- reaching someone's telephone, fax, Web site,
pager, or e-mail using the same familiar 10-digit phone
number.
For service providers and VARs, ENUM means having
value-added services to offer. For vendors, designers, and
integrators, it's a ground-floor opportunity to sell
soon-in-demand new ENUM-enabled products and services. For
end-users, it opens the "practicality door" of getting a
single standard address to access all of their
communications services -- whether delivered via PCs, fax
machines, handheld computers, cell phones, or pagers. Even
more importantly, ENUM allows for seamless VoIP. So, beyond
the convenience of only needing to use familiar phone
numbers for access, ENUM will allow enterprises to leverage
lower communications costs and simplify administration of
Internet-application endpoints.
The concept of an ENUM directory is relatively simple. It
functions like a large database. First, regular phone
numbers are made part of an Internet address. For example,
the White House's main number, 1-202-456-1414, gets reversed
with ".e164." added (E.164 is what carriers use to refer to
their numbering system), to become
4.1.4.1.6.5.4.2.0.2.1.e164. Typing the telephone number into
an ENUM-enabled application pulls up a Naming Authority
Pointer (NAP) record listing all the resources associated
with that number, including the domain name.
An ENUM directory system can automatically "discover"
destination endpoints, without the user having to worry
about whether their phone, fax, or IP-PBX realizes the
device on the other end is IP-enabled and compatible. The
automatic lookup function can be performed in less than 15
milliseconds and would determine whether the call can be
routed over IP or must be dropped off to the PSTN.
Without changing the international telephone numbering
plan (using globally unique E.164 numbers), ENUM allows a
PSTN phone using a standard E.164 number to transparently
access unknown IP endpoints. It also can terminate an
IP-based call -- e.g., SIP -- directly over an IP network to
an unknown SIP phone using the same E.164 number. And a
global DNS registry can translate the world's billions of
E.164 numbers into Internet addresses transparently and
facilitate call completions to IP endpoints from both PSTN
and IP originations.
While other potential ENUM applications include remote
printing, unified messaging, and spoken e-mail, ENUM's
biggest promise is simplifying the process of placing voice
calls over the Internet. At last, it solves the biggest
problem for VoIP services: How to let VoIP proxies and
gatekeepers find each other with only the phone number
itself to work with. By helping leverage the investments
made in data infrastructure, ENUM portends huge savings for
corporations, which typically rack up nearly half their
long-distance bills on internal communications. And there's
no barrier to end-user adoption because the contact method
is the traditional phone number.
But while the technology is straightforward, the business
(and political) debate over creating, populating, and
managing universal ENUM directories has just begun. One
school is promoting an "e164.arpa" public ENUM registry
deriving its authority from the existing PSTN regulatory
model. In this scenario, each of the 200-plus Internet
Telephony Union (ITU) member states around the globe would
define a structure for running ENUM registry services for
the subset of numbers under their control at the
country-code level. The other model promotes the development
of commercial registries. This model allows enterprises that
find value in deploying ENUM-based products and services to
deploy them today.
The development of these registry options is under way.
The advantage of the commercial method is that it can be
deployed now. It is unclear when the "public" .arpa system
will be available. It dovetails, for example, with the
regulatory questions about what category this matter is
filed under -- is it a telecommunications service
(historically subject to heavy government regulation) or an
Internet service (regulatory laissez-faire)? Eventually, the
overall solution will probably be a global ENUM directory
service. But while government and technical bodies wrangle
over regulatory questions, significant steps are now
underway to make ENUM deployment a reality. A number of ENUM
registry simulations are being tested. Hundreds of
enterprises, including a number of early-mover Fortune 1000
companies and service providers are participating in trials
in one commercial ENUM directory. Many equipment makers have
also been ENUM-enabling their products for live use in the
coming quarter. The bottom line is enterprises can begin
using commercial ENUM services to enable VoIP and
drastically cut voice communications.
So in the coming quarters, as equipment manufacturers
install the necessary software in their IP devices, and as
service providers register users in commercial directories,
ENUM will be the unifying factor to help VoIP realize its
projected cost-savings. Many will surely benefit from
commercial ENUM directories and VoIP, so it's in everyone's
best interest to support this effort. And if a single catch
phrase can support our collective VoIP interests, just
remember and repeat the following: "E pluribus, ENUM!"
Glenn Marschel is CEO of NetNumber,
Inc. NetNumber provides secure, reliable, ENUM-compliant
directory services to the Internet telephony industry.
NetNumber's ENUM program is the outgrowth of a three-year
intellectual property, technology development, and standards
body effort launched by the team in 1997.