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.