Telephony Call Server | Client/Server IP-PBX System Design

IP-PBX telephony call servers typically support the following system functions and operations:

• Gatekeeper for IP peripheral endpoints

• Call processing and feature provisioning

• Systems management, maintenance, and diagnostics

The telephony call server in a client/server IP-PBX system design may be one of two types:

• Proprietary, closed server cabinet

• Third-party, off-the-shelf server

A proprietary, closed server cabinet bundled with the IP-PBX’s generic software program often supports one or more integrated advanced application software solutions and/or includes an integrated CTI Applications Programming Interface (API) for third-party software solutions. It may also include a variety of integrated telephony gateway interfaces for PSTN trunk circuit and proprietary port cabinet/carrier connections. The server cabinet also may include an SMDI for third-party voice VMSs.

There are several IP-PBX systems that do not include a telephony call server as standard hardware equipment. For these systems an IPPBX manufacturer recommends one or more third-party, off-the-shelf servers that conform to a series of technical specifications (processor type, operating system, clock rate, main memory, disk drive capacity) to satisfy call processing and reliability requirements. External gateways and application servers are required to work behind a distributor- or customer-provided server to support non-IP interface requirements.

Looking at several of the leading client/server IP-PBX manufacturers reveals little commonality among the competitors. When Cisco Systems acquired the Selsius Systems IP-PBX solution, the product offering was based on a third-party server platform. Shortly after Cisco’s acquisition, the product was redesigned and available only with a proprietary server cabinet, known as the MCS 7835. Cisco’s AVVID IP Telephony System is currently available with the MCS 7835, a lower priced, reduced port capacity MCS 7825, or a third-party server from Compaq or IBM. The third-party servers are certified by Cisco and offer customers a more flexible hardware design choice. The 3Com NBX system originally was designed as a proprietary, closed server platform, and remains such. 3Com, after acquiring NBX Corporation, modified its SuperStack 3 Ethernet switch chassis to support call processing boards and the same telephony gateways available on the original NBX system, and currently offers it as the server platform for its large system SS3 NBX model.

The circuit switched PBX manufacturers who have entered the client/server IP-PBX market have taken different design paths. For example, Siemens offers two server platforms for its HiPath 5000 client/server IP-PBX system: the HiPath 5500 runs on a third-party server based on a Windows NT or Windows 2000 O/S platform, and the smaller HiPath 5300 is based on proprietary closed server cabinet design with an embedded Windows NT O/S. The Siemens-provided HiPath 5300 hardware includes an integrated H.323 gatekeeper that supports client authentication and registration and bandwidth management. It also provides address resolution for calls based on user name, email, or phone number and proxy functions for unavailable endpoints. A Web-based systems management tool with an intuitive GUI is bundled into the generic software program.

The 5300 call processor is based on an Intel Celeron 433-MHz microprocessor with 256 MB of SDRAM memory. There is a 20-GB (IDE) hard drive and a CD-ROM drive. It has a 99.99 percent reliability level, with an MTBF of 60,000 hours. It is very compact at 88 × 440 × 380 mm. The module is installable in a standard 19-inch rack mount carrier.

Nortel’s Succession CSE 1000 is currently based on a proprietary server cabinet, although there are plans to offer a third-party server option. The heart of the Succession call server is a Succession Controller Card (SSC). The SSC has two dual-port IP daughterboards that support the system’s MGs. The call server links to the MGs by a 100BaseTx LAN connection or direct point-to-point connections. Also residing on the SSC are two Flash drives that perform system software operations and store customer data. The first drive is the primary Flash drive that contains Succession CSE 1000 system data and the first copy of the customer data required to load the system. The primary Flash drive is programmed with system software before shipment. The second drive is the backup Flash drive that stores files the user can change, such as configuration data and the second copy of the customer database.

The Mitel Networks MN 3300 ICP is based on a proprietary server carrier. The 3300 ICP Controller carrier is based on a Motorola 8260 microprocessor and runs on a VxWorks O/S with a 11-GB hard drive. The main control processor is responsible for Ethernet to TDM gateway functions, real-time operations for the generic system software, integrated voice mail, Web browser systems management, and MITAI applica- tions gateway (a TAPI CTI interface). There are three port interfaces for the printer, alarm, and low-level maintenance devices. The carrier has an integrated tone card and Conference board that supports up to 64 channels (eight per conference group).

Some of the proprietary, closed server cabinet platforms integrate several client/server design layers into a single hardware cabinet. Although there are many manufacturers that market a wide range of telephony gateway servers, including a few that also manufacture PBX systems, several of the proprietary, closed server cabinets are designed with integrated T1/E1 digital trunk telephony gateways for PSTN trunk circuit access, such as Mitel Networks’ MN3300 ICP, Siemen’s HiPath 5300, and 3Com’s NBX/-SS-3.

Server Operating System

IP-PBX call telephony servers currently run on a variety of operating systems. For example, the Cisco Systems and Siemens client/server IP-PBXs models use Windows NT or Windows 2000 platforms. Windowsbased operating systems were a natural choice for many IP-PBX designers because of their ubiquity in the marketplace. Windows NT was the operating system of choice for most of the converged IP-PBX ICS solutions listed above. Nortel Networks, 3Com, and Mitel Networks servers use VxWorks. There are several advantages to using VxWorks as an operating system for a telephony communications system. VxWorks was originally designed as a real-time operating system (RTOS) for industrial grade applications. It is a modified version of the UNIX operating system and can easily be adapted to support the many multitasking requirements of an IP-PBX system. As of this writing, several IP-PBX suppliers are planning to use or are evaluating Linux as an operating system. Alcatel’s OmniPCX Office, designed for the small systems market, was the first converged IP-PBX to use Linux. Alcatel plans to make available a Linux-based call telephony server option in their large OmniPCX 4000 system. Avaya’s evolving Definity ECS platform is being upgraded to support a Linux call server platform. There are several reasons to use Linux as an operating system for a server-based IP-PBX design, as Alcatel and Avaya were the first to discover.

The server of a client/server IP-PBX must handle not only basic telephony call processing functions but also additional systems management (configuration, maintenance/diagnostics, call costing), advanced applications (voice and unified messaging, contact center), gateway interface, and firewall functions. The features and functions supported by the server influence the hardware and software design. The cited server services are available on standard Windows NT/2000 and UNIX/Linux server platforms. If each platform is equally capable of supporting the required services, the cost of the solution becomes a deciding factor between the operating systems. Linux is not currently subject to license fees and does not require vast processing resources to run the typical IP-PBX services. Linux supports telephony applications running on a typical IP-PBX system, and is available at an attractive cost to the system designer and developer. The free availability of Linux allows source files to be accessed easily.

An IP-PBX must perform most processing operations in real-time. Linux responds to events in what is known as soft real-time because some of its kernel operations cannot be pre-empted. This means that a highpriority process cannot interrupt a low-priority process, although the high-priority process must take precedence. Although Linux does not handle task in real-time, software extensions are available to achieve an acceptable response time, such as Real-Time Linux (RTLinux) and Real-Time Application Interface (RTAI). Alcatel uses the RTLinux extension in its OmniPCX Office system and will use it in its larger OmniPCX 4400 converged IP-PBX model when its optional server call control design is available. Real-time applications for RTLinux and RTAI can be developed using the portable operating system (POSIX).

Although the Linux operating system has not been used by the first generation of client/server IP-PBXs, the potential cost savings of using freeware is too attractive for most system designers to ignore as an alternative operating system to Windows when developing the next generation of systems. Any modifications to Linux that improve its use as an operating system for telephony systems will be made available to the entire telecommunications community as part of the no-fee licensing agreement and provide a further incentive for others to use it.

Server Redundancy

There are three major functional elements at the call processing layer that can be addressed in terms of redundancy: main CPU, memory, and power. It is simpler to address redundant memory and power issues first. Call telephony server memory systems may be based on a redundant array of independent disks (RAID) design or disk mirroring. Instead of using a single memory disk, a set of memory disks are used to store copies of the same piece of data in different physical locations. Information is written simultaneously to two different disks for two purposes: protection against component failure and possible improvement in system performance. Another redundant server option duplicates internal power supply modules to protect against power failures or errors. RAID/disk mirroring and duplicated power supplies may slightly increase the cost of a server but are usually available with most client/server IP-PBX models to increase system survivability and reliability levels.

There are two methods to provide call processing redundancy:

• Duplicate processor/memory board(s) in the server cabinet

• Multiple server configuration

At the time of this writing, the only client/server IP-PBX system available in a single server cabinet design with a fully duplicated call processor board is the Cisco Systems 7750 ICS. The system contains a system processing engine (SPE) 310 card that executes system software, including the Cisco ICS System Manager, and embedded fault-management services. The Cisco CallManager generic software program running on the SPE 310 delivers intelligent call processing to support IP telephony services and applications in the ICS 7750. A redundancy option is available by provisioning additional Cisco CallManager cards.

The second method, using multiple servers, can be based on two different design concepts

• Dedicated back-up server

• Multiple active servers

The Cisco IP Telephony System was the first to offer a redundant call telephony server option for a client/server IP-PBX design. The Cisco system can be configured with one or both redundant design options. Cisco can configure a system with a dedicated back-up server for a single active server for systems with port requirements of up 2,500 IP stations. The active CallManager Server replicates its database to the back-up server. IP client endpoints are programmed to signal the primary active server for registration and all call processing activities, but can also be programmed to signal the secondary back-up server if the primary server fails to acknowledge signal requests. In a client/server IP-PBX system, station equipment monitors the state of the main call processor to determine which call telephony server is available for any and all call processing activities. This situation is the reverse of a traditional circuit switched PBX, where the common control complex monitors the state of its peripheral endpoints. If the primary active control processor in a circuit switched PBX system fails, the internal system diagnostics program automatically activates a seamless switchover to the secondary back-up call processor (if available). The station port has no role in this process.

TABLE 1: Cisco CallManager 3.2 Cluster Guidelines

Required Number of IP Phones within a Cluster	Recommended Number of Cisco CallManagers	Maximum Number of IP Phones per Cisco CallManager
2,500	Three servers total: ■ Combined publisher/TFTP ■ One primary CiscoCallManager ■ One backup CiscoCallManager	2,500
5,000	Four servers total: ■ Combined publisher/TFTP ■ Two primary CiscoCallManagers ■ One backup CiscoCallManager	2,500
10,000	Eight servers total: ■ Database publisher ■ TFTP server ■ Four primary CiscoCallManagers ■ Two backup CiscoCallManagers	2,500
2,500	Three servers total: ■ Combined publisher/TFTP ■ One primary CiscoCallManager ■ One backup CiscoCallManager	2,500
5,000	Four servers total: ■ Combined publisher/TFTP ■ Two primary CiscoCallManagers ■ One backup CiscoCallManager	2,500
10,000	Eight servers total: ■ Database publisher ■ TFTP server ■ Four primary CiscoCallManagers ■ Two backup CiscoCallManagers	2,500

Very large customer port requirements require multiple CallManager servers networked in a cluster configuration because of individual server port capacity limits. Since Cisco CallManager Release 3.0(5), a cluster can contain as many as eight servers, six of which are capable of call processing. The other two servers can be configured as a dedicated database publisher and a dedicated Trivial File Transfer Protocol (TFTP) server, respectively. The publisher server makes all configuration changes and produces CDRs. The TFTP server facilitates the downloading of configuration files, device loads (operating code), and ring types. A dedicated publisher server and a dedicated TFTP server are recommended for large systems. For smaller systems, the function of database publisher and the TFTP server can be combined. Table 1 lists guidelines for scaling devices with Cisco CallManager clusters. The Cisco recommendations provide an optimum solution. It is possible to reduce the amount of redundancy and, hence, use fewer servers. For small systems, the database publisher, TFTP server, and Cisco CallManager back-up functions can be combined.

The maximum number of registered devices per Cisco CallManager is 5,000 in the case of the MCS7835, including a maximum of 2,500 IP telephones, gateways, and DSP devices, such as transcoding and conferencing resources. In the event of failure of one Cisco CallManager within the cluster, the maximum number of registered devices remains 5,000 per Cisco CallManager in the case of the MCS7835.

The servers are configured in a mesh network topology to better respond dynamically to changes in the network. Although customer database information (station user profiles, group assignments, call routing tables) does not significantly change over short periods, IP telephones may be constantly changing locations and reregistering with different servers in the network cluster. It is important that new registration data is stored quickly. In case of server failure or network problems, a fully meshed topology allows peripheral endpoint devices to locate and register with back-up servers.

In a multiple server cluster configuration, a publisher server protects against the possibility of server failure and loss of database information. The function of the publisher server is to provide read and write access for database administrators and for the CallManager Server nodes themselves. It is recommended that a dedicated server be used as the publisher server instead of using an existing CallManager server for the function. Use of a separate server prevents database updates from affecting the real-time processing performed by the CallManager server as part of call processing. The publisher server maintains a TCP connection to each CallManager server in the network cluster. When there are administrative changes to a CallManager server database, the publisher server replicates the changes on each CallManager server. The publisher server also serves as the central storage database for all CDRs written by all CallManager servers in the cluster. If the publisher server is not available due to system failure or network problems, the CallManager servers store the CDRs locally and replicate them to the publisher server when it becomes available. In the Cisco system an IP telephone can be programmed to signal up to three servers for gatekeeper, call processing, and feature support. One server is always designated as the primary server, and two others can be assigned as the secondary and tertiary servers. If the primary server fails or there are signaling path problems between the primary server and IP endpoint, the secondary server can be used for telephony services. The IP phone maintains active TCP sessions with its primary and secondary Cisco CallManagers. This configuration facilitates switchover in the event of failure of the primary Cisco CallManager. Upon restoration of the primary server, the device reverts to its primary Cisco CallManager. When the primary server is not available, the secondary server assumes primary status and the tertiary one assumes secondary status. The original tertiary server will assume primary server status only when the original primary and secondary servers are not available. The back-up secondary and tertiary servers may be active or dedicated standby servers.

One problem with using active servers as secondary/tertiary servers for redundancy is that station port capacity rules apply to all active servers regardless of their multifunctional mode. Another limitation to this redundancy option is a requirement for all clustered servers to be configured within a contiguous customer premises LAN configuration. CallManager servers cannot be networked over WAN facilities with IP network routers; they must be part of a localized cluster. The redundant multiple active server design is sometimes referred to as N+M because there are multiple active servers and multiple back-up servers. This provides the very high level of call processing redundancy typically provided by circuit switched PBX common control complexes.

The distributed architecture of a Cisco CallManager cluster provides the following primary benefits for call processing:

• Spatial redundancy

• Resiliency

• Availability

• Survivability

If multiple location communications is required, CallManager Server clusters or a single server must be configured at each location and networked as discrete systems. Intercluster communication is provided according to H.323 protocol standards and permits a subset of the features to be extended between clusters. The set of features transparent across clusters are:

• Basic call setup

• G.711 and G.729 calls

• Multiparty conference

• Call hold

• Call transfer

• Calling line ID

A Cisco alternative solution to a multiple cluster network configuration to support remote communications requirements with local call pro- cessing support is Survivable Remote Telephony (SRS) Telephony technology for all Cisco IOS software platforms that support voice. SRS Telephony comprises network intelligence integrated into Cisco IOS Software. This service can act as the call processing engine for IP phones in the branch office during a WAN outage. SRS Telephony is a capability embedded in Cisco IOS software that runs on the local branch office access router. SRS Telephony automatically detects a failure in the network and, using the Cisco Simple Network Automated Provisioning (SNAP) capability, initiates a process to intelligently autoconfigure the router to provide call processing back-up redundancy for the IP phones in that office. The router provides call processing for the duration of the failure, thus ensuring that the phone capabilities stay up and operational. Upon restoration of the WAN and connectivity to the network, the system automatically shifts call processing functions to the primary Cisco CallManager cluster. Configuration for this capability is done once in the Cisco CallManager at the central site, simplifying deployment, administration, and maintenance.

The Nortel Networks Succession CSE 1000 is based on an optional distributed processing design, although the standard design is based on a centralized call server. The call server is a centralized resource for database management and call processor functions, but each configured MG can be equipped with a local call processing controller card, the same card installed in the call server. If connectivity is interrupted between the call server and a survivable MG, there will be automatic switchover to survival mode. Once in survival mode, the succession MG itself, via the call processor on its MGC card, will serve the call processing function for all port interface cards. Although the primary functions of the MG are to provide control signaling interface connections to system peripherals and support a gateway function for communications between IP and non-IP peripherals, the module cabinet can also function as a call processing server for directly linked peripherals.

Any survivable IP succession MG can run in stand-alone mode in the event of a link failure or a catastrophic outage of the call server. If a system has multiple-succession MG links, a customer may choose any or all of the remotes to be survivable, depending on business requirements. If the call server or the IP link fails, the survivable succession MGs will automatically restart. During this time, the succession MGs will attempt to register with the call server. If no connection can be established, each survivable succession MG will go into survival mode, act as a stand-alone PBX, and service all users in each survivable succession MG. If the IP link fails to a particular survivable succession MG, then the succession MG and the (optional) succession MG expansion associated with that succession MG would go into survivable mode, thereby restoring service to all the users in both chassis. When an MG is in survivable mode, the IP telephone station users will hear a different dial tone and see a notice on their display field that the telephone is operating under local mode service.

Database synchronization between the call server and succession MGs is performed during a system data dump and system start-up. The database used by the survivable succession MGs during survival mode is an identical copy of the database configured at the call server. Customers, whose service is being provided by a succession MG in surviv-able mode, are notified by special dial tone and telephone display information. In addition, during survival mode, service changes at the succession MGs are possible but cannot be data dumped and must be reentered once the system returns to normal mode.

The succession call telephony server performs functions comparable to those of the Cisco CallManager, publisher, and TFTP servers. Although all three functions can run on a single server, Cisco recommends that the CallManager generic software run on a dedicated server. The Nortel dispersed design eliminates the need for dedicated back-up servers. Succession MGs can be local or remote from the centralized call telephony server. A remotely located survivable MG protects against WAN failures to ensure continued local call processing service. It effectively functions like the Cisco Systems SRS Telephony service.

Multifunction Server Design

Although the main function of the IP-PBX call telephony server is to support gatekeeper and basic telephony services (dial tone and call routing), several system suppliers have bundled it with one or more advanced functions and applications. The following are some examples of client/server IP-PBXs that use a single server cabinet design to support features and functions beyond basic telephony.

The 3Com NBX family has a variety of call processing features and applications supported by its centralized main server cabinet, including voice mail, automated attendant, hunt/call groups, CDR, CTI, and PC-based visual voice mail/email clients (IMAP4). For example, the highend SS3 NBX V5000 Chassis call processor can support up to 72 autoattendant ports, 1,000 voice mailboxes, and 400 hours of message storage. The SS3 NBX chassis is backward compatible with 3Com NBX 25 and 100 systems. The call processors support up to 750 devices, including telephones, voice mail ports, and PSTN lines. The call processors use the VxWorks operating system to maximize reliability in mission-critical applications. Dual 10/100-Mbps uplink ports deliver resilient failover protection, and dual-load–sharing redundant AC inputs boost reliability. The SS3 NBX V5000 chassis features four chassis slots, two resilient 10/100 switched uplink ports, universal AC power connection, and a built-in 3Com RPS uplink port. The call processors range from 250-device capacity single-power supply (3C10201) and dual-redundant power supply (3C10202) versions to a dual-redundant power supply, 750-device unit (3C10203); all three offer resilient 10/100 uplink ports, universal AC power connections, and simple Web browser-based administration.

The Mitel Networks 3300 ICP supports a range of fully integrated, advanced Mitel Networks enterprise applications, including voice mail; speech-enabled auto attendant and unified messaging; PDA and PC-based application integration; and optional and emerging VoiceXML, contact center, and customer relationship management (CRM) applications. These applications are run from the same server processor.

Mitel Networks’ MN 3100 also supports a variety of services, including messaging. The MN 3100 ICP is a client/server IP-PBX that also can be classified as an integrated communications system (ICS) platform solution because its single carrier cabinet design supports voice communications (IP-PBX), data communications (IP router, Ethernet switch), and messaging application services. An ICS platform is defined as a communications system design that not only supports basic voice call processing requirements but also satisfies enhanced applications such as messaging, computer telephony, call center, and/or data communications networking without external system hardware. All of the system features and functions are supported “in skin,” leading to an all-in-one shorthand description.

The Cisco 7750 ICS also falls into the ICS platform category. The system’s SPE 310 board is an application server card that runs call processing, system management, and voice applications including voice mail, automated attendant, unified messaging, interactive voice response, automatic call distribution, and Web-based contact-center applications. The Cisco SPE 310 card offers customers the flexibility to add support for a broad range of Web-based communications applications as their business and communications needs grow.

Each of these IP-PBXs is based on a client/server design and can be classified as an ICS platform system. In addition to some advanced voice options, the Mitel Networks MN 3100 and Cisco 7750 ICS offerings also integrate voice and data communications capabilities. Both products are targeted at customers who are looking for a truly converged single system solution for their voice and data networking needs.

If advanced telephony features and applications are not integrated into the telephony call server, they can be supported with a dedicated application server configured on the LAN/WAN, but under the management and control of the telephony call server. This is a design concept used by most circuit switched PBXs using proprietary solutions or third-party CTI application server options. In many cases, the same application server and software solution used behind a manufacturer’s circuit switched PBX system is also used with the client/server IP-PBX design. For advanced call center requirements, the Nortel Networks Symposium Call Center Server, originally designed for the Meridian 1 PBX platform, is compatible with the Succession CSE 1000 IP-PBX. The Siemens HiPath ProCenter Suites server works behind the Hicom 300H and HiPath 4000 PBX models and can be configured to work behind the HiPath 5000 IP-PBX models. The Mitel Networks 6100 Contact Center Solution, designed for the SX-2000 Light PBX, can interwork with the MN 3300 ICP system. The Nortel, Siemens, and Mitel contact center servers are not stand-alone systems but are functionally dependent on the IP-PBX call telephony server for control signaling support.

Application servers are also used for messaging applications. The Siemens Xpressions server that supports VMS and UMS behind the manufacturer’s Hicom 300H and HiPath 4000 PBXs is also available as an option with the Siemens HiPath 5000 IP-PBX models. HiPath Xpressions unifies voice, fax, and e-mail into a single mailbox that can be accessed from any PC or touch-tone phone. Station users can listen to voice messages, listen to e-mails, and listen to fax messages from any analog DTMF, digital, or IP telephone on or off site. It’s available in a VMS configuration and upgradeable to full unified voice, fax, and/or e-mail messaging. The solution’s Windows NT server design is based on open standards and integrates with other IP-ready mobility and collaboration solutions in the Siemens HiPath MobileOffice portfolio. Nortel’s CallPilot server provides similar capabilities working behind the Succession CSE 1000.

3Com’s NBX Call Center is a server application that supports up to 25 agents, two supervisors, one administrator, and one database manager. The software manages call flows in real time, makes changes dynamically to optimize customer responsiveness, and handles up to 100 customer queues with the Intelligent Call Routing feature. The supervisor GUI supports sophisticated real-time monitoring of alarms, ports, queues, and call status, allowing supervisors to drag and drop queue assignments to prevent abandoned calls. Alarms can be used to signal critical thresholds. Components include IBM servers, Sybase database software, and Apropos application software. The application server works behind the main system’s call telephony server, the NBX or SS3 chassis equipment.

Client/Server IP-PBX System Design

Overview

The first IP-PBX systems were based on a client/server design. When most telecommunications managers hear the term IP-PBX, they usually envision a client/server design, although the converged system design is gaining in popularity and likely will dominate the market for the next few years. An IP-PBX system based on client/server design fully uses and depends on a LAN/WAN switching network infrastructure for call control and communications signaling. Like converged IP-PBX systems, client/server designs are not standard or uniform across manufacturers, although the competing models share some common design elements.

The term client/server is borrowed from the world of data communications. It describes an IP-PBX system that does not use a traditional PBX common control complex and integrated circuit switched network or traditional common equipment hardware (port cabinets and port interface circuit cards). A client/server data communications design specifies a data processing topology in which a personal computer (client) depends on a centralized computer (server) for applications software and database management functions. For many years the traditional PBX system design was compared with a mainframe computer because all call control and switching functions were centralized and desktop terminals (teleprinters, CRTs) lacked processing functions of their own. As enterprise voice communications systems evolved toward distributed and dispersed modular design topologies, similar to the concurrent evolution of minicomputer and personal computer networks, the term client/server was used more and more to describe the improved PBX system design. The first IP-PBX systems more closely conformed to data communications and processing client/server design topology; hence, the adoption of the term.

The common control complex of a client and server IP-PBX is based on a telephony call processing server that transmits and receives control and status signals to/from LAN-connected peripheral endpoints, known as clients. The telephony server’s primary role is as a gatekeeper to clients for call setup and teardown functions and to manage and control communications bandwidth requirements for each call. In IP-PBX terminology, a telephone terminal is also referred to as a client. The IP telephone client depends on the telephony server for dial tone, call routing, and desktop feature/function implementation, similar to the relation between an analog/digital telephone and a traditional PBX common control complex. The major distinction between a traditional circuit switched PBX system and a client/server IP-PBX is that the LAN/WAN infrastructure, not an internal network of TDM buses, is the primary switching network.

Some current and planned client/server IP-PBX models may be equipped with optional port cabinet/carrier equipment with integrated TDM bus backplanes for circuit switched connections, but only calls between ports connected to the same port cabinet/carrier are circuit switched; all other calls depend on the LAN/WAN infrastructure for transport and switching operations. This type of system also may be classified as a converged IP-PBX, because TDM/PCM circuit and IP packet switching is supported. Arguments can be made for categorizing it in either classification, but if the design primarily depends on IP packet communications, and circuit switching is secondary or optional, the system is best defined as a client/server design. Design differences between individual IP-PBX models, as illustrated by client/server designs with optional circuit switched port carrier equipment, make it difficult to definitely classify any PBX system into one category or another.

There are several hardware layer elements common to all client/server IP-PBX models:

• Call processing layer—Gatekeeper/telephony call server

• Client layer—Voice terminals and other communications devices

• Applications layer—Messaging, contact center

• LAN/WAN infrastructure—Ethernet switches, IP routers, telephony gateways

Differences between client/server IP-PBX models are based on how each design element is configured within each layer and between layers. There are also differences in how some features and functions are provisioned, and whether optional application services are integrated into the overall system design or provided through nonproprietary third-party equipment. Ethernet switches and IP routers are designed to industry standards, and products from different manufacturers are usually interchangeable at the infrastructure layer, except for a few select IP-PBX models that may require proprietary LAN/WAN solutions as part of their overall system design or integrate LAN/WAN interfaces into their hardware design.

Distributed Modular Design

A category of converged IP-PBXs was originally designed to leverage a customer’s existing data communications LAN/WAN infrastructure. These are systems based on distributed, modular design architecture for call processing, switching, and port interfaces. Traditional analog telephones were used as the primary voice terminals (at least in the early system releases, until IP telephones were supported), and advanced system features and functions were available through CTI-based PC telephony. IP-PBX systems that best illustrate this IP-PBX system category are from Sphere Communications and Shoreline.

Sphere’s Sphericall Enterprise Softswitch solution consists of several major system components:

• Sphericall Manager—Host platform for Sphericall Softswitch call control software; includes remote management and monitoring

• PhoneHub—MG carrier for up to 24 analog or CLASS stations from IP or ATM networks

• COHub—MG carrier for T1/E1 connections to PSTN or PBXs from IP or ATM networks; Q.sig, ISDN, CAS, and international protocols are supported

• BranchHub—Remote or small office (6 × 12) analog trunk and station MG carrier to IP or ATM networks; six lines of power failure transfer

• VIM—Remote office or campus extension carrier, ATM IAD for T1/E1 or fiber connections to the MAN/WAN; downlinks for voice/video/data

A Sphericall system requires a single centralized Sphericall Manager to support customer premises PhoneHub and COHub carriers and remotely located BranchHub and VIM carriers. IP telephones are supported by the manager through direct control signaling over the LAN or across a WAN. Redundant managers can be configured for purposes of survivability. Individual manager, PhoneHub, and COHub carriers are interfaced to each other using an Ethernet LAN. The manager uses TCP/IP transmission to support call processing signaling to dispersed port interface carrier equipment. The BranchHub is remotely linked over a customer WAN. The PhoneHub and BranchHub carriers have TDM switching backplanes to handle local intercom calls; calls between dispersed station hubs (local, remote), IP telephones, and trunk hubs are handled over the LAN/WAN via integrated MGs in each port carrier. A Web browser systems management interface tool allows system administration support from a centralized management workstation or from multiple dispersed workstations.

The Shoreline system is based on a similar design concept, with one distinct difference. The Shoreline3 system is a completely distributed, modular voice communication solution, with no single point of failure, which is layered on top of the IP network. At the heart of the system is the standards-based Distributed Internet Voice Architecture (DIVA) software, which uniquely distributes call control intelligence to voice switches connected anywhere on the IP network. In addition, DIVA distributes voice applications, including voice mail and automated attendant, to servers across locations rather than centralizing applications at the network core. There are four types of ShoreGear voice switch:

• ShoreGear–24—A 24-port (16 telephone ports and 8 universal analog telephone or trunk ports) stackable or rack-mountable nonblocking voice switch with an integrated IP media gateway

• ShoreGear–12—Twelve universal port stackable or rack-mountable nonblocking voice switch with integrated IP media gateway

• ShoreGear–T1/E1—Digital trunk interfaces to the central office; it can also be used as a VoIP gateway to other PBXs; alternatively, the ShoreGear-E1 can be used as a VoIP gateway to an existing PBX, thereby bridging legacy systems to the Shoreline system

• ShoreGear–Teleworker—Supports remote station users while maintaining full communications functionality

As the names imply, each port carrier has specific interface capabilities. Each ShoreGear voice switch has a local switching TDM backplane and a call processor that runs ShoreWare software to support fully distributed call control, voice applications, desktop applications (via CTI-based PC telephony), and management tools. ShoreGear voice switch carriers, equipped with Ethernet connectors, can be dispersed across a customer LAN/WAN infrastructure to support single- or multiple-location requirements. Voice QoS is monitored and maintained with dynamic jitter buffering and packet loss replacement. Voice codecs can be administered to support linear, G.711, ADPCM, and G.729/A compression formats, echo cancellation, and silence suppression. The distributed call control design provides a high level of local survivability in case of LAN/WAN link failure.

The primary design difference between the Sphere and Shoreline systems is that the Sphere is based on dedicated telephony call server (with optional redundant servers) and the Shoreline embeds call processing functionality and software in each port carrier. Both systems use circuit switched connections for intercom calls between stations interfaced to the same port carrier/hub unit. IP signaling format is used only for intercabinet communications, although the limited port capacity of each carrier/hub increases the likelihood that a significant percentage of calls will be handled across the LAN. Each system is based on an incremental modular expansion design and is ideally suited for a network of numer- ous small locations. A single-location customer configuration with significant port requirements will require a large number of port carrier/hubs. The interface capacity of each port carrier/hub is comparable to a single port interface circuit card in a traditional PBX system. In a large customer configuration, the limited port capacity of each carrier/hub increases the complexity of the network design necessary to support basic port-to-port communications because the QoS level of the customer LAN/WAN is a factor for most premises calls.

There are several important benefits to a dispersed LAN/WAN infrastructure design, including ease of expansion; single-system image across multiple customer locations, including unified dialing plan and feature-transparent operation; toll bypass using private WAN facilities; dynamic bandwidth use of network transmission resources; and centralized administration.

There is often confusion regarding the classification of IP-PBXs into different system design categories. The Sphere and Shoreline systems are sometimes categorized as client/server IP-PBXs because they lack a traditional common control and switching network complex and are heavily dependent on a LAN/WAN infrastructure communications signaling. Both designs are based on circuit switched networking within each port carrier and retain many of the characteristics of a traditional PBX. The Shoreline system can be viewed as a network of mini-PBX systems that uses an IP-based infrastructure to link the multiple systems. The Sphere system is based on a LAN-connected common control complex that supports a cluster of circuit switched port cabinets interconnected over an IP network. Instead of a multicarrier port cabinet capable of supporting dozens of port circuit cards, these systems have substituted a network configuration of port interface carriers/hubs, each one the equivalent of a single port interface card. There are two disadvantages to this approach: more complex hardware equipment is required to support large single-location port requirements and there are limited shared equipment resources. For example, an integrated center stage switching complex is sometimes more advantageous than a complex network of LAN switches. A centralized power supply to support a large system configuration can also be advantageous. As usual, there are advantages and disadvantages associated with every PBX system design

Upgraded Circuit Switched PBX

Circuit switched PBXs that are upgraded to support IP telephony can be designed to support dispersed common equipment for single or multiple customer premises configurations. It may be necessary to disperse common equipment across a single customer premises if it is a large campus environment with multiple buildings or even a very large single building complex. Multiple customer premises requirements can be satisfied by a variety of design options, but a single system solution is often the preferred choice. If an existing customer WAN is installed and can handle voice calls, there is a potential to save significant transmission service expenses that would normally be allocated to dedicated circuit switched trunk facilities.

Nortel Networks implemented the first use of IP telephony by a traditional circuit switched PBX system. It supported remote communications requirements with the use of WAN links instead of more traditional T1/E1 trunk carrier circuits. In the early 1980s, Nortel Networks also was the first PBX supplier to offer a remote port cabinet option, remote peripheral equipment (RPE). In 1999, the supplier announced a remote port carrier using IP connectivity, the 9150 Remote Office Unit. A centrally located Nortel Networks Meridian 1 equipped with an ITG port interface board (Reach Line Card) can support a remote 9150 by using available WAN trunk facilities between the two locations. The remote unit has a port capacity of 32 digital Meridian 1 telephones, a TDM backplane to support local switching between stations (reducing dependency on the Meridian 1’s center stage switch network), and an integrated IP gateway. Voice codecs supported include G.711, G.726, and G.729/A. The 19-inch carrier unit also has a 10Base-T Ethernet port connector for LAN connectivity and ISDN BRI trunk circuit interfaces for local trunk calls. Key QoS parameters on call sessions between the Meridian 1 and 9150 are monitored, included packet loss, jitter, and end-to-end packet delay (latency). If threshold parameters are exceeded during a call in progress, the call can be dynamically and transparently rerouted over ISDN BRI trunk circuits to the Meridian 1. With G.729 (8 Kbps) encoding, a single ISDN BRI B channel supports up to eight simultaneous calls back to the Meridian. Calls can be transitioned back to the IP WAN when the network can support acceptable QoS levels. If the WAN link to the Meridian 1 is lost, the remote 9150 supports limited call processing functions, including local switch connections, access to ISDB BRI trunk circuits, and basic station features (transfer, paging access).

Ironically, the 9150 unit does not directly support IP stations. IP stations remote to the Meridian 1 can be supported via an ITG line card in a centrally located IPEM port cabinet over a LAN/WAN link. Communications between a remote IP telephone and a digital telephone supported by the 9150 unit must be handled across the Meridian 1 center stage switch network at the main location. The remote IP station is totally dependent on the LAN/WAN link for all telephony services, and not even dial tone is supported when the link fails.

Other PBX suppliers soon followed Nortel’s lead by offering IP remote cabinet/carrier options on their circuit switched PBXs. For example, the Avaya R300 Remote Office Communicator is designed for branch offices that support centralized Definity/IP 600 IP Communications Server features—essentially everything available at headquarters—over the WAN, to offices with fewer than 25 employees. The R300 Remote Office Communicator was designed to lower customer networking costs by converging voice and data onto a single WAN facility. An IP port interface card in the centrally located Definity/IP 600 system transmits call processor control signaling to the remote location and functions as a gateway for calls between the central and remote locations. The R300, an Avaya-customized Ascend Communications R3000 remote office concentrator, has built-in data networking and routing capabilities including firewall, VPN, and security features, with optional remote access concentration capabilities to improve network efficiency. The R300 has integrated port circuit interfaces that support up to 24 digital and two analog stations, WAN options such as full and fractional T1/E1 and BRI, a bidirectional 10/100 Ethernet port, local analog and digital T1-carrier trunking, E911, PPP data routing to the corporate LAN, and dial tone even during WAN failure or power failure. The unit supports local switching among TDM peripherals (stations, trunks). IP telephones may be supported at the remote location when using the R300 Ethernet port connection for signaling connections over the WAN back to the IP-PBX common control complex.

The Nortel Networks and Avaya remote IP carrier options are similar in concept (remote station/trunk support, IP control signaling over a WAN link, gateway interfaces at the main location) but somewhat unique in their sum capabilities (port capacities, types of stations supported, survivability features, data networking functions). Both IP options could, in theory, be used for dispersed communications services across a campus location, instead of remote locations, like the Siemens offering originally known as the Fiber Loop Exchange (FLEX) option. First available on the supplier’s Hicom 300H platform (currently upgraded to HiPath 4000), the option consisted of a port cabinet shelf that could be installed remotely from the main system complex and a dark fiber cabling link to support IP-based control signaling and voice communications channels. Available in a redundant mode, the optical fiber cable interfaces to the Hicom 300H common equipment through an optional integrated gateway board, the HiPath HG 3800. The gateway card provides connectivity for the Hicom 300H hub location to remote shelves by using Fast Ethernet fiber over dedicated single or multimode fiber to campus locations within a 20-mile radius of the host location. The remote port cabinet shelf, designated the HiPath AP 3300, is designed with an integrated gateway interface circuit.

The newer HiPath 4000 platform can also support remote ports over a traditional LAN/WAN infrastructure. This option requires a HiPath HG 3570 gateway interface card, housed in a HiPath 4000 host system, with IP tunneling to a HiPath AP3300 remote port cabinet or an AP 3500 remote 19-inch rack mount carrier at a remote location. A HiPath HG 3575 is housed in the remote AP 3300 cabinet or AP 3500 carrier. The gateway cards are equipped with 10/100 Base-T Ethernet connectors and are used to transmit call processor control signaling from the centralized HiPath 4000 common control complex to the remote cabinet/carrier. Gateway resources convert PCM signals to IP packet format for LAN/WAN transport and provide TDM bus connectivity at the host and remote locations. The AP 3300 cabinet and AP 3300 carrier are equipped with TDM switch network backplanes to support local switching for station and trunk ports. In case of LAN/WAN failure, a dial-up modem connection over PSTN trunk circuits can provide gatekeeper control signaling support to the remote cabinet/carrier.

The Alcatel OmniPCX 4400 distributed processing, switching, and cabinet design easily lends itself to an IP LAN/WAN infrastructure for control and communications signaling. A fully configured system can support a cluster of 10 control cabinets and associated expansion port cabinets by using a variety of networking options, including TDM/PCM, IP, ATM, and frame relay. Each control cabinet/port cabinet group can be remote from the others. A control cabinet also can support a remote expansion cabinet or a single remote IP station. The IP networking option requires an INT-IP card to support gatekeeper control signaling between a centralized control cabinet (with call processor) and remote port cabinets, between control cabinets configured across a LAN/WAN, or to a remote IP station. The INT-IP card also supports gateway functions between dispersed circuit switched port cabinets configured across a LAN/WAN or between dispersed IP stations and a centralized port cabinet. The INT-IP interface card, designed with a 10/100 Base-T Ethernet connector, supports peer-to-peer LAN switching between IP endpoints, provides tone generation and signaling channel processing, and supports several voice codecs (G.711, G.723.1, and G.729/A).

Dispersed Common Equipment over LAN/WAN Infrastructure

Support of IP endpoints, stations, and/or trunks may not be the only trademark of a converged IP-PBX system design. A PBX system that supports neither IP stations nor trunks can be considered an IP-PBX if the system design includes geographically dispersed port cabinets/carriers using an IP LAN/WAN infrastructure for control signaling from the common control complex and voice communications between dispersed port interface equipment. Using a LAN/WAN infrastructure to support customer communications requirements across one or more customer premises locations based on a single IP-PBX system offers several potential key benefits:

• Single system image (numbering plan, features, systems management)

• Reduced networking costs between customer locations

• Scalable system expansion

There are several types of converged IP-PBX system designs in this category. They include upgrades of traditional circuit switched PBXs and IP-PBX systems whose original design was based on a LAN/WAN infrastructure to support desktop and networking communications requirements. The latter system designs were introduced by nontraditional PBX suppliers that entered the market during the late 1990s.

IP Trunk Ports

The first generation of converged IP-PBXs could support only private network IP trunk calls. VoIP calls are not currently used for local trunk connections to and from the central office. Off-premises network calls are routed across IP routers over the customer WAN and are typically under the control of a policy management server. A policy management server uses a customer-defined program of IP telephony policies to support VoIP QoS levels across the customer WAN. The server can extend QoS differentiation for content networking through network-based application recognition support. The customer-based policies are managed through interaction with a directory server to provide different network classes of service to different station users. Through the server, end-to-end service can be provisioned, and service level agreements are maintained. Access control policies can be applied to maintain network and application security levels.

Converged IP-PBX systems support two types of outgoing IP trunk calls:

• IP station generated calls

• Non-IP station generated calls

For IP station calls, if the ARS program selects an IP WAN trunk circuit to route a private network call, the IP line port circuit card providing control signaling to the desktop station will direct the IP telephone to transmit voice packets to an assigned IP WAN router. The IP WAN router will then handle the networking operations as programmed. Incoming IP trunk calls from the WAN can be routed directly to an IP station based on the control signaling directions from the terminating IP-PBX system gatekeeper.

An outgoing IP trunk call placed by an IP station is commonly handled without local TDM connectivity, except in cases requiring a circuit switched connection. A direct IP trunk call not requiring TDM connectivity must satisfy a set of conditions similar to that listed for IP station calls. If any of these conditions are not satisfied, a TDM switched connection may be required to place or receive a trunk call.

In a converged IP-PBX system, a non-IP station can also place an IP trunk call if the ARS program selects a route using customer IP WAN facilities instead of traditional PSTN trunk circuits. An integrated IP trunk port interface card provides a gateway between the circuit switched TDM bus network and the LAN/WAN facilities. An external VoIP gateway server is not required, as do circuit switched PBXs that do not support integrated IP trunk interface capabilities.

The IP trunk card functions similarly to a DS1 trunk circuit interface card in support of private line tie trunk control signaling and bearer communications channels. It connects to a local TDM bus and packets/compresses PCM voice communications signals for transmission over the Ethernet LAN to an IP router for access to the customer WAN. The card can also modulate and demodulate incoming and outgoing fax calls. IP trunk cards typically support ISDN protocols, such as ISDN D channel, for private network signaling, H.323 signaling, and a standard VoIP protocol stack.

IP trunk cards also monitor QoS parameters, such as latency, jitter, and packet loss to ensure that acceptable voice communications quality is maintained throughout the call. A customer can define a delay threshold, such as 150 ms, for monitoring purposes; if transmission delay exceeds this level, the call is automatically rerouted over circuit switched PSTN trunk carrier facilities. Packet loss measurements also can be thresholded and monitored for call rerouting purposes. In all cases call rerouting is performed transparently and seamlessly to the call parties. There are several methods used by IP-PBX system designers to monitor QoS transmission delay parameters, including analysis of packet time stamps embedded in the RTP signaling stream or calculating delay based on a self-generated signaling ping across the network.

IP trunk circuit card gatekeeper and gateway functions are similar to those of the IP station card. IP trunk cards typically support 24 (T1 carrier interface) or 30 (E1 carrier interface) gateway channels. There is always a 1:1 ratio between the number of trunk channel equivalents and gateway channel connections. Some cards can be configured to support increments of eight channels to support the maximum T1/E1 carrier channel capacity. Like IP station cards, the most common voice codecs supported by IP trunk cards are G.711, G.723.1, and G.729/A. Although IP-PBX control signaling may be proprietary across a private network of like IP-PBX systems, to support feature transparency functions, almost all systems attempt to comply with the latest version of ITU-T H.323 standards. H.323 compliance supports network connectivity within a multivendor network of different IP-PBX systems.

An IP trunk circuit card can be used for private networking configurations as an alternative to other PBX circuit cards: analog E&M tie trunk, T1/E1 interface, and ISDN PRI interface. It handles outgoing IP trunk calls and is used for incoming IP trunk calls to non-IP stations. Incoming IP trunk calls directed by the terminating IP-PBX gatekeeper to non-IP stations, such as analog telephones, require TDM connectivity. The IP trunk circuit card supporting outgoing IP calls by non-IP stations performs a reverse gateway function for incoming IP calls to non-IP stations. Incoming IP call voice packets are decompressed, reformatted into PCM signals by the IP port interface card, and transmitted across available gateway channels onto a local TDM bus for circuit switched connections to the called non-IP station.

The first release of each supplier’s converged IP-PBX system was designed with dedicated IP station and IP trunk interface cards, the same approach used for traditional TDM/PCM ports. Avaya was the first converged IP-PBX system designer to develop a universal IP port interface for IP stations and IP trunk circuit connections. The Avaya IP Media Processor Interface’s gateway resources are available for station and trunk calls. Pooling the gateway resources for all types of IP endpoints provides greater flexibility in traffic engineering design and can reduce customer hardware costs. Alcatel’s OmniPCX 4400 originally required different IP interface cards for station, trunk, and remote cabinet support, but the latest system release supports a universal INT-IP card that replaces the three dedicated INT-IP cards. A universal IP port interface card likely will be a design trend followed by most converged IP-PBX system suppliers.

To summarize, there are four categories of IP trunk calls:

1. IP station to IP station (IP trunk circuit cards are not usually required)

2. IP station to non-IP station (IP trunk circuit card required at terminating IP-PBX to perform gateway functions)

3. Non-IP station to IP station (IP trunk circuit card required at originating IP-PBX to perform gateway functions)

4. Non-IP station to non-IP station (IP trunk circuit card required at originating and terminating IP-PBXs)

The major benefit of an IP trunk call is potential cost savings due to the reduced requirement for private line carrier facilities. If the IP call is implemented with a codec using compressed voice packets, such as G.729/A, less bandwidth is required for the IP trunk call than when placed over circuit switched PSTN carrier facilities. Although the LAN/WAN requires continual traffic engineering to maintain an acceptable QoS level and may experience less than optimal QoS levels due to higher than anticipated transmission delays, a customer balances lowerquality voice communications service with reduced telecommunications expense. If QoS levels exceed a defined benchmark, IP calls can be overflowed to PSTN carrier facilities.

Some customers first test IP trunk calls for only the last category of calls, when the only non-IP station equipment placing and receiving calls are facsimile terminals, before using IP networking for real-time voice calls. The ARS software can be programmed to select IP trunk routes for only certain types of calls between specific station users. For example, conference calls typically require a very high QoS level and may be set up only with PSTN trunk circuits. Call types classified as less important may use an IP trunk route as the first choice, accepting the possibility that a diminished QoS level occurs during the call.

Making IP Voice Calls

In a converged IP-PBX system, a call begins when the IP telephone goes off-hook and the PBX common control complex is alerted via a control signaling path between the IP telephone and the common control complex functioning as a gatekeeper. The signaling is transmitted to and from the LAN via an IP port interface card, dedicated Ethernet TCP/IP interface card, or integrated Ethernet connector. Dial tone packets or a control signal will alert the IP phone to activate a dial tone signal, an indication to the station user that the IP phone is ready for use. As the calling number digits are dialed, the common control complex will send multiple signals to the desktop, such as ring back or other call progress tones. If the call is being placed to a non-IP station port, such as an analog telephone, or a PSTN trunk circuit is required for an off-premises call, the following steps will occur:

1. A local TDM bus talk slot will be assigned

2. A gateway bearer communications channel will be assigned

3. Voice communication signals will be transmitted over the LAN to the IP port circuit card

4. The packeted voice signals will be reformatted, buffered, and transmitted across the gateway channels to the local TDM, and the call will continue until one party releases (disconnects) the connection.

For purposes of the call, the IP telephone appears to the common control complex and switching network as a PCM peripheral endpoint for voice transmission and feature activation operations. Converged IP-PBX systems typically use the same proprietary control signals for IP telephone support as those used for digital telephones.

If an IP station user is placing an intercom call to another IP telephone, the common control complex will direct the IP telephone to start sending voice packets directly to the IP address of the called IP telephone. The common control complex also will direct the called party’s IP telephone to send voice packets directly to the IP address of the calling party’s IP telephone. The direct audio communications path between the two IP telephones, using only LAN facilities, is often referred to as an IP-PBX peer-to-peer LAN switched connection or direct IP. No traditional PBX circuit switched connections are used for the call.

Direct IP connections will be established automatically between two IP endpoints if several conditions are satisfied:

• Both IP endpoints are administered to allow direct IP connection

• No TDM connections are required for either IP endpoint, and a point-to-point LAN connection is available

• The IP endpoints are in the same network region or in different network regions that are interconnected via LAN/WAN facilities

• The two IP endpoints share at least one common voice codec in their voice codec lists and the internetwork region connection management voice codec list

• The IP endpoints have at least one voice codec in common, as shown in their current codec negotiations between the endpoints of the IP-PBX

If any of these conditions are not satisfied, the call may require TDM connectivity.

A direct IP connection established for an existing call may be torn down if circuit switched TDM connectivity is required during the call. Conditions that may require TDM connectivity, based on the IP-PBX system, are:

• Additional parties are conferenced onto the call, including IP endpoints

• A PBX signaling tone or announcement needs to be inserted into the connection

• The connection is put on hold—music on hold

When the event requiring TDM connectivity is no longer in effect, a direct IP connection may again be established. The generic term for call connections that change from direct IP to TDM connectivity and back to direct IP is null capability.

The first generation of converged IP-PBXs required talk slots on the local TDM buses to support multiparty conference calls for calls among IP endpoints, even if all the parties were IP endpoints. Each conferenced party required a talk slot per TDM local bus to support the call. The manufacturers have future plans to support non-TDM conference calls among IP endpoints through enhanced versions of their current IP port circuit cards. Planned versions of IP port circuit cards will include conferencing circuits to support multiparty calls exclusively among IP endpoints, thereby eliminating the need for TDM switched connections. The IP endpoints may be internal IP telephones or IP trunk circuits connecting off-premises stations.

IP Station Ports | Converged IP-PBX System Design

The key word in the above design attributes is integrated. A circuit switched PBX that supports IP peripherals using external gateway equipment is not considered an IP-PBX. A PBX system must be configured with integrated signaling or port interface circuitry to support ToIP communications if it is classified as an IP-PBX; otherwise any older PBX system with a T1/E1 interface and a third-party VoIP gateway could be considered an IP-PBX.

Most first-generation converged IP-PBX systems were based on a traditional proprietary common control complex. The common control complex, specifically the main system processor, functions as the gatekeeper for IP clients. A gatekeeper was originally defined as a component in an H.323 communications system used for admission control and address resolution. Gatekeepers allow calls to be placed directly between two IP endpoints with the use of peer-to-peer LAN switched connections; two IP telephones can communicate over a LAN/WAN infrastructure without using the PBX’s internal circuit switching network. A converged IP-PBX system also supports calls between an IP endpoint and a non-IP endpoint using gateway resources. The primary functions of a traditional gatekeeper are address translation, admissions control, bandwidth management, and zone control. The IP-PBX main processing unit assumes this responsibility for all IP communications. Most converged IP-PBXs support H.323 standards for LAN-based real-time multipoint communications networks.

A traditional circuit switched Meridian 1 Option 81C model, with its traditional core module cabinet can be upgraded to a converged IP-PBX system platform through the simple addition of an optional ITG line card and a software upgrade capable of supporting IP telephony. The optional interface card supports IP telephones by providing physical connectivity to the LAN, which links IP-PBX common equipment to the desktop IP voice terminal for control and voice communications signaling. The ITG line interface card converts on-board gateway resources for conversion between PCM and IP packet signals connectivity to an Ethernet LAN through a 10BaseT or 10/100BaseT interface, and passes gatekeeper control signals between the PBX call processor and IP endpoints.

In some system designs the IP port card with gateway resources also functions as a proxy server for the system gatekeeper to transmit control signals to and from IP endpoints. Nortel’s ITG line card is used for TCP/IP control signaling connections between the PBX system and the LAN. IP line interface cards from Siemens and Alcatel also support the server as proxy gatekeeper servers. Gatekeeper signaling also may be transmitted with a dedicated Ethernet TCP/IP interface circuit card, such as Avaya’s Definity/IP 600 CLAN interface card, or through an Ethernet connector located within the common control complex, such as a daughterboard on the CPU board (NEC’s NEAX2000 IPS). The terms gatekeeper and gateway were originally defined for H.323 LAN-based telephony systems but are now also used to describe the role of the PBX common control complex and new IP port interface cards used by circuit switched PBXs to support IP endpoints and connections. Although IP port interface cards might not support gatekeeper signaling, they all support gateway functions.

A gateway is composed of two elements: an MGC and an MG. The MGC handles call signaling and other non–media-related functions. The MG handles the communications media transmission. H.323 gateway functions typically include protocol conversion, connectivity, compression, decompression, fax demodulation, and fax remodulation. The latter two gateway functions are not commonly used with converged IP-PBX IP port interface cards because fax terminals are supported with traditional analog line interface circuit cards. The PBX gateway function is extremely important because TDM/PCM ports are likely to remain a significant percentage of the total number of converged IP-PBX peripherals endpoints for several years to come. Communications between IP ports and non-IP ports require protocol conversion between the different voice coding formats and connectivity to the local TDM bus via the gateway bearer channels.

The IP port card gateway resources can also be used to establish voice communications links between IP endpoints using different voice codecs. For example, an IP endpoint using G.729/A format for voice packeting cannot communicate with an IP endpoint using only a G.711 format unless there is a conversion process between the endpoints. IP port card gateway resources can perform this conversion process, which is known as transcoding. Transcoded IP calls may require circuit switched connections on a local TDM bus, unless the IP port card can redirect the reformatted communications signals back across the LAN to the IP endpoints.

IP line card capabilities for a converged IP-PBX differ across manufacturers. There are several parameters that can differentiate IP port interface capabilities:

• Maximum number of IP stations supported (based on gatekeeper signaling)

• Gateway channel resources

• Voice codecs supported

The number of gateway channel connections per card is based on the number of on-board DSP resources, referred to by some system manufacturers as digital compressors. The term compressor signifies the compression algorithm function that converts the 64-Kbps PCM transmission format to the lower transmission rates supported by different IP voice codecs, such as those conforming to G.729 formatting standards (8 Kbps). PCM transmission may or may not be compressed to conserve LAN/WAN bandwidth resources. IP station transmission across the gateway to the local TDM bus needs to be decompressed (if not using the uncompressed, 64-Kbps G.711 format standard) to communicate with non-IP stations or access PSTN trunk circuits. The most common IP voice codecs supported by IP port interface cards are G.711, G.723.1, and G.729/A. The specific voice codec used for each IP call can be predefined by the system administrator, based on the call type (on-premises, off-premises) or specific number dialed.

There are different approaches used by converged IP-PBX system manufacturers in their IP station interface card designs. One approach is to limit the gateway channel capacity to support physical IP stations and provide nonblocking access to the local TDM bus in support of IP to non-IP calls. Siemens employs this strategy by limiting IP port capacity, based on gatekeeper signaling capacity, to 30 stations per interface card, the same as the maximum number of gateway channel links to the local TDM bus. The 1:1 ratio between IP station and gateway connections to the local TDM bus eliminates the possibility of blocked communications signaling to and from the TDM bus and LAN. Ericsson also implements this design strategy on its MD-110 for its IP station card.

Other leading converged IP-PBX system suppliers take a different approach. The Nortel Networks ITG line card supports 96 IP telephones, but only 24 gateway channels to the local TDM bus. The Alcatel OmniPCX 4400 INT-IP line interface card can support up to 500 IP clients, but the maximum number of gateway connections to the local TDM bus is limited to 60 gateway channels. The actual number of gateway channels per INT-IP card can be configured based on the number and type of daughterboards (8 or 30 compressors). An Alcatel system is unlikely to be configured with 500 IP Reflexes telephones supported by a single INT-IP board because of the extreme ratio of potential IP telephones to local TDM channel connections, unless there are minimal requirements for IP port to non-IP port connections. The reason Alcatel designed their interface card with a limited number of channels for a large number of physically connected telephones, and other manufacturers such as Nortel Networks designed IP station interface cards with potential contention for limited channels, is that gateway channels serve as pooled resources for any IP endpoint and can be configured based on traffic engineering requirements. For all the systems under discussion, IP interface cards are not dedicated to specific endpoints for gatekeeper or gateway operations. IP telephone communications services can be performed by any of the IP port interface cards in the system, a major difference from the support of traditional analog and digital telephones by dedicated port interface cards.

NEC and Avaya have designed IP port interface cards that handle only gateway functions because gatekeeper signaling is transmitted to IP endpoints through other means. The Avaya IP Media Processor Interface, sometimes referred to as a prowler board, supports between 32 and 64 channel connections, based on the IP voice codec implemented per call, G.711 or G.729/A. The Avaya port interface card has a total of 64 DSP resources. Each DSP resource can support a single G.711 communications interface, for a maximum total of 64 simultaneous conversations (1 DSP resource = 1 active gateway channel). The G.729/A protocol format uses compressed voice (8 Kbps) and requires two DSP resources per IP call requiring a circuit switched connection to a non-IP peripheral, for a maximum of 32 simultaneous conversations. The conversion process for G.729/A is more processing intensive than uncompressed G.711 (64 Kbps). The actual number of available channel connections to the Avaya Definity local TDM bus will change continually based on the type of voice codecs that are implemented for concurrent IP calls requiring TDM bus connectivity. The number of IP Media Processor Interface cards required in a system design will depend on IP call requirements for TDM bus connectivity, or transcoding. The NEC IP line interface card, known as the IP PAD, has 32 on-board compressors that perform the gateway function for IP stations requiring circuit switched connections to non-IP ports. NEC designed the card to have a maximum of 32 compressors because it occupies a single card slot that is limited to 32 TDM bus backplane connections.

Taking into account gatekeeper signaling and gateway resource capacities, the actual number of equipped and active IP endpoints that can be supported by an IP port interface card to maintain an acceptable QoS level is based on the number of IP endpoints, customer traffic patterns, and engineering requirements. The more likely a gateway channel will be used per IP station call, the lower the acceptable ratio between peripheral endpoints and channels. For example, if there are very few IP stations equipped in a converged IP-PBX and most ports are traditional TDM/PCM peripherals, a call generated by an IP telephone more likely will require a channel for connectivity to the local TDM bus to talk with a non-IP station/trunk. If a converged IP-PBX system is equipped with a very high percentage of IP telephones, as compared with traditional analog or digital telephones, and a significant percent- age of off-premises calls are handled over an IP WAN, the acceptable ratio between IP endpoints and gateway channels will be larger. A converged IP-PBX system design using separate interfaces for gatekeeper signaling transmission and gateway functions theoretically can be equipped with no gateway interface cards, assuming there is no requirement for any IP call to use TDM bus resources. This scenario is almost impossible to envision in a current customer environment, unless it is a small satellite location with all IP stations and no local central office trunking is IP networked to a main PBX system.

IP port interface circuit cards typically support functions beyond their gateway responsibilities. Some of these functions are administration and maintenance support, echo cancellation, silence suppression, DTMF detection, conferencing, and improved voice quality through dynamic jitter buffers. Basic administration/maintenance functions include support of station registration and initialization, downloading firmware changes to desktop terminals, and diagnostics of errors and alarm conditions at the port endpoint. Echo cancellation technology reduces the effects of echo heard by a caller when on an active voice call. If the echo transmission signal is delayed, the resulting echo will be noticeable to the caller. An echo canceller monitors caller speech; when an echo occurs, a signal is generated, transmitted, and sent back to the caller to cancel the echo. Silence suppression is the detection of the absence of audio on the bearer communications channels. Another term for silence suppression is voice activation detection. When no voice packets are detected, the gateway bearer communications channels are released from a call and made available for voice packets transmitted by another caller.

The jitter buffering function is very important for maintaining voice QoS levels. The time for voice packets to be transmitted and received between endpoints is known as delay. The “end-to-end” delay time consists of two network delay elements, fixed and variable. Jitter is the difference between the two delay values of two voice packets in the transmission across the network. Fixed network delay may include propagation delay of signals between the two endpoints, voice encoding delay, and the voice packeting time for the IP voice codec. Fixed network delay times can be calculated and corrected for, but variable delay times present a different problem. Variable packet delays can be caused by network traffic congestion and serialization delays on network interfaces. The quality of voice communications is degraded if there is a variation in the arrival of voice packets at the receiving endpoint. Network congestion can occur any time and cause variations in arrival times. To compensate for delay variations, the IP station card equipped with jitter buffers turn delay variations into a constant value so that voice can be transmitted and played out smoothly. Digital signal processing (DSP) algorithms can be programmed for different buffer times based on the expected voice packet network delay. The algorithm can review each packet’s timestamp included in the RTP header of the voice packet, calculate expected delays, and adjust the jitter buffer size accordingly. Extra buffer time can be programmed to account for variable packet delays and smooth out the packet flow. If packet delay exceeds the total jitter buffer time, the packet is dropped. Loss of one packet in a voice call does not significantly affect the quality of the call. If variable delay of voice packets is underestimated and many packets are dropped, the resulting voice call quality will suffer.

IP station equipment supported by an IP station interface card may include an IP telephone terminal instrument or a PC client softphone. Converged IP-PBX systems can support local IP stations that are physically located on the customer premises or remote at off-premises locations. Control signaling to and from the IP endpoint is over LAN/WAN facilities. A remote IP station can use private line WAN carrier facilities or PSTN services (ISDN, DSL, dial-up) for gatekeeper control signaling. A centrally housed IP port circuit card provides gateway function to non-IP ports.

MGCP and MEGACO (H.248)

The MGC Protocol, or MGCP, was designed to address the requirements of VoIP networks that are built using “decomposed” VoIP gateways. MGCP is used by external call control elements called MGCs for controlling MGs. Decomposed MGCP-compliant VoIP gateways appear to the outside as a single VoIP gateway. Examples of these gateways are trunking gateways that interface the PSTN and VoIP network, desktop gateways that provide traditional analog 2500-type interfaces to VoIP networks, and access gateways that provide traditional analog or digital PBX interfaces to VoIP networks. MGCP-based VoIP solutions separate call control (signaling) intelligence and media handling. MGCP functions as an internal protocol between the separate components of a decomposed MGCP-compliant VoIP gateway.

MEGACO (H.248) is a standard protocol for interfacing between external call agents (MGCs) and MGs. The standard is the result of a unique collaborative effort between the IETF and ITU standards organizations. H.248 was derived from MGCP, which in turn was derived from the combination of Skinny Gateway Control Protocol (SGCP) and IPDC. SGCP is sometimes known as Skinny Protocol and is currently used by Cisco systems to support their proprietary IP telephone instruments. H.248 is based heavily on MGCP but includes several enhancements. MEGACO offers the following key enhancements over MGCP:

• Supports multimedia and multipoint conferencing-enhanced services

• Improved syntax for more efficient semantic message processing

• TCP and UDP transport options

• Allows text or binary encoding, formalized extension process for enhanced functionality

• Formalized extension process for enhanced functionality

H.248 has the same architecture as MGCP. The commands are similar, but the main difference is that H.248 commands apply to terminations relative to a context rather than to individual connections, as is the case with MGCP. Connections are achieved by placing two or more terminations into a common context. It is the concept of a context that facilitates support of multimedia and conferencing calls. The context can be viewed as a mixing bridge that supports multiple media streams for enhanced multimedia services.

H.248 packages include more details than MGCP packages. H.248 packages define additional properties, statistics, and event and signal information that may occur on terminations. With H.248, the primary mechanism for extension is by means of packages. To accommodate expanded functionality, MEGACO specifies rules for defining new packages.

Even though MGCP was deployed first, H.248 is gaining momentum and is expected to achieve wider industry acceptance as the official standard for decomposed gateway architectures sanctioned by the IETF and ITU. MGCP is currently maintained under the auspices of the PacketCable and the Softswitch Consortium. There are no plans for the MGCP specification to be enhanced by any international standards body. MGCP is like an orphan without a parent, looking for approval from a standards body.

At the time of this writing, only one IP-PBX supplier (Sphere Communications) has announced support of MGCP for signaling to its proprietary IP telephones, and no IP-PBX supplier plans to use H.248 for proprietary voice terminal support. MGCP and H.248 are sometimes supported by external gateway equipment used as system options to support analog communications devices. MGCP and H.248 are supported for networking applications by a limited number of IP-PBX suppliers, although the more dominant interworking protocol for multiple system network configurations is, and is expected to remain, H.323.

H.323 or SIP?

Despite SIP’s limitations, there are several often-cited reasons demonstrating why SIP is superior to H.323 in supporting IP telephony processes and applications.

Emerging Dominance of IP

H.323 is designed to be interoperable with other ITU-T standards in support of ISDN and ATM networks and includes all of the necessary mechanisms to support interoperability across multiple networks. SIP is designed primarily for IP networks, and the continuing growth of the Internet and its associated protocol makes interoperability a less important issue. Although the Internet has become a ubiquitous presence, the dominance of PSTN services for voice communications will continue for some time, making interoperability an issue for years to come. PSTN signaling interoperability and the more mature nature of H.323 are advantages over SIP at present. H.323 products currently far outnumber SIP offerings, although this is expected to change over time.

Signaling Reliability Mechanism

SIP provides its own reliability mechanism, is independent of the packet layer, and only requires an unreliable datagram service. H.323 requires RTP/RTCP for reliability but provides a better QoS level (see below).

Client/Server Design

SIP messages are exchanged between a client and a server in the same way as HTTP messages. H.323 has a more complex call control protocol. It takes more time to establish an H.323 call than a SIP call. SIP’s client/server operation mode allows security and management features to be implemented easily in SIP, when compared to H.323 calls. SIP uses distributed multicasting signaling support, a more flexible method than the H.323 centralized, unicasting signal method.

Addresses

SIP addresses are like e-mail addresses. Each user is identified through a hierarchical URL that is built around the elements such as a station user’s telephone number or host names. A SIP URL can be easily associated with a user’s e-mail address, greatly simplifying dialing plans. SIP’s use of any URL address for station user identification is less cumbersome than H.323’s requirement for host addressing. Using a single identifier for voice and text communications has its benefits, but only if everyone is using SIP. Private network calls may use the SIP address, but dialing off-network stations will still require the use of the traditional multiple-digit dialing codes.

Complexity and Cost

SIP is a much smaller and less complicated standard that is based on the architecture of existing popular protocols such HTTP and FTP, whereas H.323 is large and complicated. As a result, H.323 products and services are more expensive to develop, and license fees will also be more expensive. Although SIP cost savings are not apparent in the first generation of products, particularly telephones, this appears to be a longer-term advantage for SIP versus H.323.

Command/Message Format

Compared with H.323, SIP uses a simple command format, and the text strings are easier to decode and debug. The entire set of messages is also much smaller than in H.323. This gives SIP an advantage for future SIP software development efforts, particularly development of new features and application services.

QoS Management

SIP supports loop detection, unlike H.323. SIP’s algorithm using “via header” is somewhat better than H.323’s PathValue approach. In other areas, H.323 has the upper hand. Regarding fault tolerance, H.323 supports redundant gatekeepers and endpoints, unlike SIP. H.323 support of Call Admission Control is better than SIP’s reliance on other protocols for bandwidth management, call management, and bandwidth control. H.323 also has limited support of Differentiated Services (Diffserv), but SIP does not. Overall, H.323 wins in this arena.

Firewall/Proxy Design and Configuration

SIP commands can easily be proxied and firewalls can be designed to allow/disallow SIP communications. Getting H.323 through firewalls and proxies is much more complicated.

Extendible and Scalable

SIP is more scalable than H.323 because it is based on a distributed client/server architecture. H.323 often requires peer-to-peer communication, making it more difficult to expand networks. Extending SIP is also easier because of its simpler message format and greater experience with similar protocols such as HTTP. SIP’s use of hierarchical feature names and error codes, which can be IANA registered, is more flexible than H.323’s vendor-specific single extension field.

H.323 offers the benefits of superior network interoperability, better QoS management, and redundancy. SIP is a less complex protocol that is more easily adapted to expansive and growing networks, supports a faster call set-up time, and uses an addressing scheme that leverages the existing DNS system instead of recreating a separate hierarchy of telephony name servers. The two protocols will likely exist side-by-side for many years, until they either merge or are supplanted by something newer and better.