×

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




 
Next_Wave.gif (4849 bytes)

December 1998


IP-Based PBXs: Facts and Fictions (Part II)

This column is the conclusion to the Next Wave that appeared in the November 1998 issue of INTERNET TELEPHONY™. Read Part I here.

BY MIKE KATZ

Why stop and look at the standards for something as simple as setting up and tearing down walls between IP PBXs, VoIP phones, and IP telephony gateways? Because without standards and interoperability, each vendor's IP PBX is an island - incompatible with other vendors' VoIP phones and IP telephony gateways. If an IP PBX stands any chance of being successful in the market, it will be through its ability to create a homogenous environment for telephony systems. Just as Internet telephony gateways enabled proprietary PBXs to run voice calls on the corporate Intranet, IP PBXs have the potential to bring new telephony applications to corporate desktops. Interoperable standards at both the vendor and industry levels will allow the new facet of this relationship to emerge.

So, why do we care if these systems interoperate? Suppose you're the MIS manager of a medium-sized corporation and want to try out IP telephony/IP PBXs on a mixture of sites with both existing PBXs and older key systems. The key systems can be replaced with an IP PBX of some type, but you will need compatible IP telephony gateways on the corporate side of the network. You will probably purchase most of your equipment from one vendor, and in order to avoid being captive to that single source, you will need a promise of interoperability. But standards alone will not solve the interoperability puzzle, and in fact they may make the performance of a product unacceptable, as illustrated in the H.323 discussion below.

IP PBX PROTOCOLS: THE WINNING COMBINATION
H.323 - The Standard

H.323 terminals are the client endpoints on a local-area network (LAN) that provide real-time, two-way communications, while gateways are the means for an H.323 client terminal to speak with a PSTN caller. The two are the major components of an IP PBX, and how the International Telecommunication Union's (ITU) H.323 standard provides interoperability between gateways has been a popular discussion topic. Details of the H.323 standard are available at www.itu.org, or through the International Multimedia Teleconferencing Consortium Web site at www.imtc.org/i/standard/itu/i_h323.htm. The standard describes terminals, equipment, and services for multimedia communication over LANs, which do not provide a guaranteed Quality of Service (QoS), since they can lose transmitted data. Support for voice is mandatory under H.323, while data and video support are optional. All terminals must be able to use a specified common mode of operation - to understand how to initiate, receive, and render the audio, data, or video parts of a call. How the application layer of one vendor's product will use H.323 to speak with another vendor's implementation does not have to be defined under the standards.

The real issue here is how vendors use H.323 to make a call from their gateway to another vendor's gateway or, in the case of an IP PBX, from the phone or terminal device to the PSTN gateway. If that gateway's call control application is proprietary, then it's unlikely that other vendors' products will interoperate. So, H.323 compliance does not necessarily equal interoperability. The most well known H.323 client terminal software is Microsoft's NetMeeting (www.microsoft.com/netmeeting). It has been used as the market's benchmark measurement of the interoperability of a given vendor's H.323 Internet telephony gateway. There have been many public H.323 interoperability events where NetMeeting was tested with a given vendor's gateway, yet interworking with other vendors' products was not attempted.

Another issue that will affect the acceptance of standards-based IP PBXs is call setup time, a chief user interface characteristic referring to the period of time before the user hears a ring after dialing. Using the existing H.323 protocol without any workarounds requires up to 20 requests and replies to set up a call. On a LAN-based IP PBX this means low overhead, however it may take too much time over a WAN link, and a caller would probably hang up rather than wait for a ring.

SIP - Reducing Transactions
Another Internet Engineering Task Force (IETF) standard vying for market dominance is the Session Initiation Protocol (SIP), taken from original work done by Henning Schulzrinne. SIP reduces the number of protocol transactions required to set up an Internet telephony session from 20 for H.323 to two for SIP. It provides the same call setup features as H.323, and is also capable of being grafted on top of the key lower layers of H.323 including codecs and the real-time protocols. The number of high visibility players considering or implementing SIP is growing, and includes Cisco, Lucent, and NetSpeak.

IPDC - A Broad New Alternative
A group of influential vendors working for Level 3 have submitted a new specification for Internet Protocol Device Control (IPDC) to the IETF. The vendors include 3Com, Ascend, Alcatel, Cisco, Ericsson, and Selsius, now a part of Cisco.

The IPDC protocol specifications cover four major component areas including:

  • Signaling transport within an IP network.
  • Device management - management of the IP telephony gateways.
  • Media control - functionality, which allows for detection and generation of specific inband events.
  • Connection control - within the media gateways.

IPDC does not supersede H.323 or SIP but instead works with them, covering the open call control application area needed to enable interoperability between multiple vendors' IP Telephony gateways and IP PBXs. Stay tuned, as many of the vendors will probably introduce products that are IPDC-compliant.

INTEROPERABILITY: THE KEY TO THE FUTURE SET
Without open standards, our phone systems would not stand a chance of interworking with the millions of other phones in the world. And the 2500 set, the analog phone of the future, will depend on interoperability. Its design should be open, programmable, based on LAN standards, and publicly available * to copy and mass market without an onerous patent cost, otherwise we will have a Tower of Babel that offers no gain to anyone.

CONCLUSION
So, what will the communications appliance of the future be like? It's likely to be intelligent, application-driven, and open to just about all of the competing protocols discussed. Third-party developers of all sizes will be able to drive and control the device. Perhaps our next generation 2500 set will be WinCE-based, Java-based, or a mixture of the two, but with open APIs based on standards-driven appliances. This will stimulate the start of a new market - the sale of applications for millions of end-user communications appliances. I believe this market opportunity will happen like Internet telephony did, practically overnight, and well within the next two years. The types of applications might enable the future 2500 set with the same capabilities of a Palm PC and make it your communications appliance as well as your PIM.

Proprietary closed phones and PBXs that do nothing more than the "status quo" are a thing of the past. The arrival of the IP PBX and intelligent, open communications appliances of the future will certainly see to that.

Mike Katz is vice president of marketing and business development at NetPhone, Inc. Headquartered in Marlborough, Massachusetts, NetPhone is a provider of computer telephony solutions for small business environments. For more information, contact the author at mkatz@netphone.com.







Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2021 Technology Marketing Corporation. All rights reserved | Privacy Policy