Summarizing Client/Server IP-PBX Design Issues

It is apparent that client/server IP-PBX designs differ across models. There are even major design differences within one supplier’s product family. For example, the Cisco Systems 7750 ICS all-in-one design is radically different from the supplier’s larger MCS 7825/7835 multiple server cluster design; Siemens offers client/server models based on a closed, embedded Windows NT server or a customer-provided server option. Client/server IP-PBX designs may be far simpler than traditional circuit switched PBXs and converged IP-PBX platforms, but there is a sufficient number of design variables to create major differences between system models.

Figure 1 shows how three layers (call telephony server, gateways, and applications) of a client/server IP-PBX can be designed and integrated into the system architecture. The choices available to a designer include a proprietary or a nonproprietary call telephony server, integrated or external advanced applications support, integrated or external gateways. Gateways and application servers may be a mix of proprietary or third-party solutions. Designers may select proprietary components for quality control and development of feature/function options capabilities not supported by third-party solutions. Third-party components may reduce system costs and provide customers with more design flexibility in their purchase decisions.

Figure 1: Client/server IP-PBX design.

Several IP-PBXs originally designed using third-party call telephony servers were redesigned with customized servers because distributors and customers often failed to use a third-party server with the technical specifications as recommended by the supplier. Several manufacturers that currently offer a proprietary call telephony server model plan to migrate their systems to a less expensive third-party server solution, but not until all the system design bugs and problems are solved after one or two system generations.

If issues related to proprietary or third-party components are not part of the customer-buying equation, there are other important design and performance criteria to be evaluated before a purchase decision is made. System reliability and survivability are as important when evaluating a client/server IP-PBX as they are in a circuit switched PBX design—port capacity, traffic handling, and call processing power. The following is a summary checklist of design performance issues for evaluating a client/server IP-PBX (many unique to an IP telephony communications system):

• System redundancy—Fully duplicated or shared back-up components for call processing, memory, and power functions

• System port capacity—Stations (IP, non-IP) and trunk interfaces (analog, T1/E1, IP)

• System traffic handling capacity—Distribution of gateway channels and conference circuits

• System call processing—BHCC

• Supported call control protocols and interfaces—H.323, SIP, MGCP, SGCP, MEGACO, etc.

• Voice codec support—G.711, G.723.1, G.729(A,B), GSM, etc.

• QoS support—DiffServ, 802.1p/Q, COS, TOS, IP precedence, RSVP, dynamic jitter buffer, packet loss replacement

• Standard messaging system interfaces—AMIS-A, VPIM, LDAP, IMAP

The first client/server IP-PBX systems were shipped less than 5 years ago, and in that time the design and performance capabilities have changed significantly. It will take several more years until the product design stabilizes, and its reliability is comparable to current circuit switched PBXs, which have been shipping for more than 25 years. Although a new generation of data communications systems seems to appear every year or two, new voice communications system platforms take many years to evolve.

Telephony Gateways | IP PBX System Design

IP telephones, including PC client softphones, communicate directly with the call telephony server over a customer LAN/WAN infrastructure. Proprietary port circuit cards housed in proprietary port carriers are not required for signaling between the IP desktop and the common control controller, unlike converged IP-PBX designs. Non-IP stations and trunk circuits require telephony gateway interfaces to support server control signaling and voice communication transmissions. Telephony gateways for analog telephones and other 2500-type compatible communications devices, such as facsimile terminals, may be provided through a variety of design methods:

• Integrated call telephony server gateway interfaces

• Desktop gateway modules: proprietary, third party

• Gateway servers/interfaces: proprietary, third party

Several proprietary, closed call telephony servers have integrated gateway interfaces for PSTN digital T1/E1 trunk circuits. The gateway interfaces usually support ISDN BRI or PRI services over the T1/E1 trunk circuits. The Mitel MN 3100, 3Com NBX, and Siemens HiPath 5300 systems have integrated PSTN digital trunk gateway interfaces. For example, the 3Com NBX’s integrated analog line card connects up to four conventional (loop start) PSTN telephone lines, and the T1/PRI trunk card connects to a standard T1 circuit. The HiPath 5300 BRI gateway interface card supports four BRI ports (8 × 64-Kbps channels); the PRI gateway interface card includes a T1 carrier interface.

Mitel Networks uses a different approach to support non-IP peripherals on its MN3300 ICP. The 3300 ICP includes an analog services unit (ASU), and a network services unit (NSU), but also supports traditional Mitel SuperSet digital telephones by a link to a peripheral equipment (PE) cabi- net. An ASU supports four analog trunks and 16 stations (including MOH, paging, and PFT); an NSU supports four T1 digital trunk interfaces. Up to four ASU and four NSU carriers are supported per controller carrier. What is unique about the system is that the call server also provides control signaling to an SX-2000 Light PE cabinet. Supporting the traditional PE cabinet protects a customer’s substantial investment in the installed base of proprietary Mitel SuperSet voice terminals.

Mitel intends the MN 3300 system to be a migration vehicle for its large installed base of SX-2000 system customers and allows customers to link existing PE cabinets to the new call telephony server through one of two options: direct optical fiber cable connection or T1 trunk interface. Customers who want a centrally located call telephony server and PE cabinet can use the optical fiber link. The DTI can support remote PE cabinets. The 3300 ICP was the first client/server IP-PBX design to support common equipment originally designed for a circuit switched PBX system. All communications traffic between digital telephones is handled internally by the PE cabinet’s integrated circuit switched TDM backplane. Calls between PE endpoints and other endpoints (IP telephones and ASU and NSU ports) are handled across the integrated controller gateway channels.

Desktop gateway modules may be proprietary or industry-standard H.323 equipment. The most common desktop gateways support 2500-type communications devices, such as analog DTMF telephones and facsimile terminals. The desktop communications device links directly to the gateway module and converts analog signals to IP format for control and communications signaling. For example, 3Com NBX analog devices are available as single-port stand-alone units and four-port chassis-based cards. The single-port ATA unit also includes an additional Ethernet port that allows an analog device and an Ethernet device to share the same Ethernet LAN cabling. The multiple-port NBX analog terminal card features four analog (FXS) ports. The units connect to a wide variety of industry-standard analog devices and fax machines and provide support for door phones, paging systems, and other applications that may require analog connectivity.

The gateways may be proprietary to an IP-PBX system, like the Siemens HiPath AP 1100 (available in one- and four-port interface models), or third-party products available from a large list of suppliers. For example, Ericsson markets a downsized version of its Webswitch IP-PBX for use as an H.323 gateway module. 3Com, a major enterprise data communications equipment supplier, is another IP-PBX supplier marketing desktop gateway modules, including those that support H.323 and SIP standards.

Another type of desktop gateway module is an add-on adapter that converts a proprietary digital PBX telephone into an IP-compatible voice terminal. A few client/server IP-PBX manufacturers, including Siemens and Nortel Networks, offer this as an option to upgrade installed digital telephones originally designed for use behind their circuit switched PBXs. The same adapters can support IP desktops behind the manufacturer’s converged IP-PBX system solutions.

Gateway servers and interface modules/boards that are not fully integrated into the call telephony server or used as desktop devices are proprietary to a manufacturer’s IP-PBX or conform to industry standards, such as H.323 or MGCP, and used as OEM solutions. One example of a proprietary solution is the Mitel Networks MN 3300 ICP gateway carrier that supports traditional analog trunks (loop start) and digital trunks (DASSII, DPNSS, QSig, Euro ISDN, and BRI) for connection to the PSTN and for connecting multiple sites or systems together. This allows multiple 3300 ICPs to be clustered or networked between multiple sites over IP or traditional TDM infrastructures to support up to 40,000 users. The MN 3300’s call telephony server carrier supports the trunk gateway interface carrier.

The Cisco Systems IP Telephony system, when originally designed as the Selsius System, used desktop modules for support of non-IP communications devices and trunk circuits. The redesigned product supports analog station, analog trunk, and digital trunk interfaces with proprietary circuit boards that are housed in Cisco Catalyst 6000 Ethernet switch carriers. Three different modules are used for analog connections: 24-port analog station FXS (H.323 or MGCP), analog trunk circuit FXO (H.323 or MGCP), and analog E&M tie trunk (H.323 only). The FXS module supports fax relay, which enables compressed fax transmission over the IP WAN. An alternative to the FXS module is the standalone Cisco VG248 analog gateway module that supports 48 fully featured analog phone lines as extensions to the Cisco CallManager system. It is housed in a compact 19-inch rack-mount chassis, and its high-density gateway can be used for analog phones, fax machines, modems, and speaker phones. Digital PSTN trunk interfaces are supported by a limited-capacity stand-alone T1 adapter module or a Catalyst 6000 T1 and services module that provides eight T1 ports (192 channels) or DS0 voice trunks. The module supports voice trunk protocols such as ISDN Primary Rate Interface (PRI) and in H2 CY ‘00, channel-associated signaling (CAS). The module’s DSP resources can also be programmed for call conference bridge services and voice codec transcoding applications, instead of digital trunk gateway interfaces.

The Nortel Succession CSE 1000 MG module supports a variety of non-IP interfaces, such as analog station, analog trunk, and digital trunk. Each MG module has three IPE card slots and can support an expansion module for four additional slots. The first Succession CSE 1000 release is limited to a maximum of four MGs (28 card slots, maximum).

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.

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

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.

The Case for the Client/Server IP-PBX

A client/server IP-PBX is likely to be the standard design platform of the future for enterprise communications systems. Although there are several drawbacks to current client/server IP-PBXs, there may be several benefits to customers who select it as their enterprise communications solution. Recalling the pricing discussion in the preceding paragraphs, the upfront capital investment for a client/server design is favorable for customer solutions with the following characteristics:

• Green field location

• Large percentage of IP peripherals, such as telephone instruments

• Remote location requirements with small port capacities

• Small port capacity requirements with PBX performance requirements

Green field locations without existing PBX equipment and with the newest generation of LAN switches and IP routers that can be programmed to support voice-grade QoS levels are best suited to cost effectively support a client/server design. A client/server design that supports a significant number of IP stations and minimal analog communications equipment will be more optimally priced, and support of remote IP stations likely will be less expensive than circuit switched alternatives. Customers with KTS/Hybrid port capacity requirements, but who require the performance capabilities of a larger, more complex PBX system, are likely to discover that the price of a client/server design is a more attractive alternative to a full-featured circuit switched or converged system solution.

The most common reasons given by system suppliers to promote the performance value of a client/server IP-PBX are:

1. Using a converged network for a variety of communications media: voice, data, video, text, graphics

2. Universality of IP transport

Figure 1: Basic client/server IP/PBX design.

1. Lowered communications bandwidth requirements and more efficient use of existing bandwidth

2. Simplified centralized management and administration

3. Rapid deployment of new technology and applications

4. Fully distributed network design

5. Scalability

Converged Network

The concept of the integrated voice/data PBX system in the early 1980s was driven by the increasing amount of data traffic generated by geographically dispersed desktop CRT terminals linked to a centralized host processing system. It was thought that the circuit switched telephony network could be used to carry voice and data enterprise communications traffic. The advent of Ethernet LAN hubs and switches in the mid-1980s effectively ended the dream of the PBX system as an all-media office systems controller. Today the pendulum has swung the other way; packet switched LANs carry telephone-generated voice communications in addition to PC client data traffic. To data communications network designers and managers, the telephone is viewed as just another client, and voice features and functions are just other applications supported by a LAN-based server. If a customer is seriously thinking about migrating to an IP-PBX system, then a client/server design using the existing LAN/WAN infrastructure is the optimal solution. As LAN bandwidth capacity continues to increase, more video communications traffic will be carried between desktops with decreasing dependence on larger, more expensive, room-based videoconferencing systems.

Figure 2: IP-PBX pricing: converged versus client/server.

Universality of IP Transport

Ten years ago the Internet was used almost exclusively by government and higher education institutions. Today the Internet is everywhere, and IP control and transmission signaling have become the standard for data communications networks. There is universal access to LANs and WANS in all medium and large enterprises across all industry sectors. The client/server enterprise data communications network design has replaced the host mainframe design that was dominant in the 1970s and most of the 1980s, and IP networking has replaced IBM’s Systems Network Architecture (SNA) as the standard. If a customer is looking at an IP-PBX system solution, the current data networking infrastructure is favorable to a client/server design.

Network Bandwidth

Using the same communications network for voice and data traffic reduces overall bandwidth requirements because the two traffic streams can be interleaved and QoS levels can be engineered and programmed to satisfy real-time voice communications requirements. There will be cost savings and increased network efficiency due to economies of scale as a customer migrates an increasing percentage of traditional circuit switched PBX traffic to the packet switched LAN/WAN. The major bandwidth cost savings and optimization will be attributed to off-prem- ises communications because circuit switched PSTN trunk carrier facility requirements can be reduced.

Simplified Centralized Management and Administration

A single communications management system is less costly to operate and more easily administered than separate systems for voice and data communications. The primary elements of an IP-PBX client/server design—desktop IP telephones and telephony call server(s)—are indistinguishable to a data network management system when compared to with PC clients and a data processing server or database manager. All voice system moves, adds, and changes are performed from the data network management workstation, as are maintenance and service operations.

Rapid Deployment of New Technology and Applications

A client/server design lends itself more to rapid deployment of new technology and applications because there are fewer hardware elements in the system architecture than in a converged IP-PBX that retains the traditional proprietary common equipment components of a circuit switched PBX. It is far easier to implement a technology upgrade for a client/server IP-PBX because there are fewer if any, proprietary switching network elements, and new advanced applications can be implemented through a software upgrade or an optional applications server. Client/server designs based on third-party servers are easily upgraded and enhanced by replacing the existing server with a newer, more powerful server. Migration between client/server IP-PBX generations will be smoother and less disruptive than between converged system generations that are based on more proprietary and costly common equipment hardware.

Fully Distributed Network Design

A client/server IP-PBX is by definition a distributed network design. A single telephony call server can support premises and off-premises IP stations. Premises stations can be distributed in a single building or across a campus. Multiple server designs can be programmed to support redundant emergency call processing in case of individual server failure. The servers can be colocated or distributed for disaster recovery situations. Customers have multiple layers of LAN/WAN switching and routing that preclude single points of failure.

Scalability

A client/server design has the potential to be highly scalable because IP telephones are easily added to the system without the need for specialized port interface circuit cards, and port capacity can be expanded through the addition of another server. Converged IP-PBXs require port interface cards, if only for control signaling, and, except for the rare system model based on a distributed processing design, there are call processing and port capacity limitations when using a single common control complex. The switching and transport limits of a client/server design are virtually boundless because a customer can continually install switches and routers to the LAN/WAN infrastructure to support increased traffic or more stringent QoS levels.

There are many customers for whom a converged or client/server IP-PBX system design will satisfy financial, feature performance, and applications requirements. Many enterprise communications system customers may also decide that their circuit switched PBX system will continue to be a satisfactory solution for current and near-term needs. A customer may not be ready to immediately replace his legacy PBX system with an IP-PBX system, but should seriously consider testing ToIP technology very soon.