August 2001

 
SIP And H.323 For Voice/Video Over IP -- Complement, Don't Compete!

BY ELI DORON

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.

[ Return To The August 2001 Table Of Contents ]

BY MARTIN SENDYK

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).

[ Return To The August 2001 Table Of Contents ]

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.

[ Return To The August 2001 Table Of Contents ]