July 2000

Clients Thick, Clients Thin 

BY TONY RYBCZYNSKI

IP telephony protocols constitute a framework, and the framework should accommodate the essential functional components of IP telephony systems. These components include:

1. IP telephones (and appliances) and PC software telephony clients.
2. Gateways to the circuit-switched world and to legacy analog and digital phones.
3. Application servers.
4. Communications servers (also known as call server and connection managers).

Ideally, these components should be tied together by IP telephony protocols. But exactly how should these components be tied together? In other words, what will the architecture look like? This question has occasioned divergent (or seemingly divergent) responses.

The main differences arise over how best to distribute intelligence to implement scalable IP telephony systems. Some approaches emphasize thin IP telephony clients, which rely primarily on network intelligence to initiate and manage communications. Other approaches emphasize thick IP telephony clients, which rely primarily on end point intelligence. Ultimately, both architectural approaches will co-exist in real-world systems.

RECONCILABLE DIFFERENCES?
The discussion over thin and thick IP telephony clients revisits the discussion over smart and dumb networks. It goes something like this: Do you make the end points relatively dumb (the telephony model), and put the intelligence in the network? Or do you put all the intelligence in the end points (the PC model), and use the network as a dumb conduit? The debate is around the question of what's the right architecture to deliver feature functionality in the form of IP telephones to end-users with the right price points.

Thin clients use what is called "stimulus signaling," working into communications servers that provide most of the feature functionality. In this case, if a feature key such as three-way conferencing is pressed, then this action is signaled to the communications server, which then makes it all happen. Thick clients, on the other hand, use "functional signaling," minimizing reliance on the communications server, which provides address translation or routing functions.

Thin client proponents argue that their approach allows overall system cost optimization, as well as ease of horizontal services development and deployment. Thick client proponents argue that memory and processing are cheap, and that their way is the right way to build IP telephony systems. In either case, the ability to negotiate coding schemes (including wideband coding for high-quality audio) is provided to ensure audio compatibility between the communicating devices.

Interesting debates! In reality, both client types will be available, and the user will decide which offers superior feature functionality, operational ease, and cost. The good news is that the thin client approach is entirely compatible at the system level with the thick client approach, with interworking provided by the communications server. In fact, think of the communications servers as providing thick client functionality for a set of thin clients. In addition, everyone agrees that thick clients will exist, for example, in PCs and application servers, and that the protocols being developed for thick clients will also apply to communications between communications servers.

PROTOCOLS THICK: H.323 VIES WITH SIP
If you were to start with a clean slate, you might find it daunting to define protocols that would operate in function-rich environments. You would confront many difficult protocol questions. For example, should signaling be defined for each feature to be supported (for example, setting up a conference call) or should more primitive signals be defined (for example, adding a user to a call)? And which might you then combine in various ways to define new modes of operation? What coding scheme should be used to define the protocol syntax? What are the precise meanings of each signaling element that define the protocol semantics? Should protocols be developed that are optimized for IP telephony with many short real-time interactions and a human at the end of the line? Or should IP telephony leverage existing protocols and emphasize re-use rather than optimization?

As has often happened in the complex world of telecommunications protocols, two camps have evolved. The H.323 camp sees IP telephony as an element of the more general multimedia conferencing space and argues that there is no need to re-invent the wheel. The SIP camp says that H.323 is too complex and that a new IP telephony protocol is warranted that fully exploits the dynamic nature of IP networking.

H.323 is part of a broader family of standards developed by the International Telecommunication Union (ITU), the body that is responsible for most telecommunications protocols -- with the conspicuous exception of IP. This family includes the widely deployed H.320 standard, which is used in virtually every room video conferencing system and runs over the public ISDN network. H.323, however, defines an IP-based video conferencing architecture. In addition, it relies on PC intelligence and on a communications server (called a gatekeeper in the standard) for conferencing coordination. It is widely available in PC software (for example, Microsoft NetMeeting). However, H.323 hasn't been widely used for a several reasons, including limited business value, lack of end-user familiarity, and impacts on the network. In short, it hasn't been an IT priority to date.

SIP, the Signaling Internetworking Protocol, is a new standard being developed by the Internet Engineering Task Force (IETF), which is the de facto center of IP standardization. It takes the classical IP networking approach of allowing two end points to establish communication directly, fully leveraging standard IP capabilities such as DNS (Data Name Server) and mobile IP services. Extensions are now being developed to provide IP telephony features in a similar manner.

In the short term, H.323 is the de facto interoperability standard. However, SIP continues to mature in terms of features/functionality. It is likely that SIP will eventually displace H.323 as the preferred IP telephony thick client and inter-communications server signaling protocol. The long-term success of H.323 will be tied to multimedia conferencing. Within enterprise networks, both types of clients will need to be supported with interworking provided via communications servers, particularly in the early days of IP telephony. SIP will be with us for a long time, while H.323's survival will be determined off the battlefield.

PROTOCOLS THIN: CONVERGENCE VIA MEGACO AND H.248
Defining a thin client IP telephony protocol is conceptually a simpler task. While several protocols have been proposed, even in the relatively few years since the emergence of IP telephony, standardization of a single protocol is at hand. The effort is being carried out jointly by the IETF Media Gateway Control Working Group (Megaco) and the ITU. The IETF group calls the result of the joint effort the Megaco protocol, and the ITU calls it H.248. However, the Megaco protocol and H.248 are synonymous. While the work originated in the IETF, the ITU will most likely control the actual documentation and will evolve the standard towards richer multimedia support.

The Megaco/H.248 protocol provides a flexible framework for master/slave control of a very broad range of IP telephones and similar devices. It lends itself well to definition of user interface elements such as function keys, indicators, displays, and so on. This capability, perhaps best expressed in the creation of protocol profiles, makes it possible to define very simple devices, greatly reducing complexity/cost and improving interoperability. The Megaco/H.248 protocol can apply to applications such as PSTN trunking gateways, ATM interfaces, analog line and telephone interfaces, and announcement servers.

The relationship between the H.248/Megaco protocol and MGCP (Media Gateway Control Protocol) has been an area of some confusion. Historically, MGCP was to have been the acronym used for the output of the Megaco working group. However, the term was also used by Telcordia and others as the title of their technical draft proposal targeted at basic "black" telephones and gateways to the PSTN. That proposal was not accepted by the Megaco working group, although many important aspects were incorporated along with inputs from several other proposals. Unfortunately, Telcordia published their MGCP proposal as an IETF informational RFC and continued to promote MGCP as a de facto standard.

SOME OTHER STANDARDS PIECES
Additional standards pieces merit attention. One such standards piece, developed by a working group within the Telecommunications Industry Association (TIA), concentrates on VoIP telephones. The group means to define a "whole device" standard covering all the considerations that would arise during the manufacture of a business-class IP telephone. These considerations include everything from Ethernet physical interfacing, to audio quality requirements, to safety, and everything in between. This specification is largely made up of references to other standards, and includes three options for a control protocol: Megaco IP Phone, SIP, and H.323.

Another TIA working group is concentrating on audio quality standards. In addition, an IEEE committee is working on Ethernet powering.

THICK OR THIN?
We can expect both thick and thin clients in the network. Thin clients leverage intelligence in the network, facilitating the introduction of new features (with no need to download software to potentially thousands of devices) and lowering the total cost of ownership. Thick clients will be used in more sophisticated PC-based environments, such as in customer interaction centers, and as the base of signaling between communications servers. In either cases, buyers should understand the fit of any particular IP telephony environment to their business needs, keep an eye on total cost of ownership, and ensure that stronger interworking is provided with their installed base.

Tony Rybczynski is director of strategic marketing and technologies for Nortel Networks' Enterprise Solutions unit. For more information, visit the company's Web site at nortelnetworks.com. E-mail questions or comments to [email protected].

[ return to the July 2000 table of contents ]