Multiple System Private Networking

PBX private networking has evolved dramatically during the past 25 years. The earliest PBX networking arrangements consisted of two switch nodes linked by a dedicated, private line facility, such as an E&M tie trunk, to save on long distance toll charges. The primary benefit was cost savings. During the late 1970s more complex private tandem network configurations were made available, consisting of a meshed network of private line facilities linking tandem switch PBX nodes, main PBX nodes, and satellite systems. 

AT&T’s first modern private PBX networking option was called Enhanced Private Switched Communications Service (EPSCS). First tariffed in the mid-1970s, it was quickly replaced by the better known and higher-performance ETN offering in the late 1970s. AT&T’s innovative PBX private networking option was initially proprietary, but other leading PBX manufacturers at the time, including Northern Telecom (ESN), NEC (EPN), and Rolm (RolmNet), soon offered similar PBX options. After a few years, the competitive PBX offerings became compatible with ETN. By the mid-1980s, a customer could configure a network with a mix of PBX tandem switch nodes from multiple manufacturers.

The original ETN options were based on in-band signaling techniques supporting a network dialing plan and automatic alternate routing between nodes within the network. In addition to cost savings benefits using fixed tariff private line carrier facilities, customers enjoyed greater control over network operation and use. All of this was done initially with narrowband analog trunking facilities. The availability of digital T1-carrier trunk services in the mid-1980s would soon change the rules for PBX networking because in-band signaling would be replaced by out-of-band signaling.

The next step up the evolutionary PBX networking ladder was intelligent network signaling to support transparent feature/function operation between discrete locations served by independent PBX systems. AT&T’s DCS was the first intelligent, feature-transparent PBX networking option. The first implementation of DCS required an expensive private data circuit (a 9.6-Kbps DDS line) for the intelligent signaling link between PBX network nodes, but digital voice carrier services using T1-carrier circuits made out-of-band signaling a more economic and feasible solution for implementing intelligent PBX networks. Out-of-band signaling channel PBX systems could communicate with one another at a much higher level than before. The resulting intelligent network configuration would continue to offer customers traditional network transmission cost savings but also provide significant productivity gains and additional cost savings through the use of shared application features/ functions. Today’s intelligent private networking options may be configured with a variety of digital trunk services based on a variety of transmission and signaling protocols, including ATM and IP.

Multiple PBX system private networks are designed and implemented for a variety of reasons:

1. Reduction of communications expenses (transmission services, maintenance and administrative support)
2. Improved management and control of communications operations
3. Enhanced communications capabilities among station users
4. Shared applications resources

Reduced costs are always a motivating factor for any business venture, and a private network configuration can have a significant effect on monthly telecommunications service bills and personnel outlays. With private lines or a virtual network service offering, PBX networking features can cost-effectively route calls between endpoints over least-cost routes, minimize trunk circuit requirements, monitor and diagnose transmission carrier facilities for efficient operation and problem areas, and minimize support personnel through centralized management centers. PBX traffic carried over private line facilities incurs a fixed monthly cost regardless of the amount of traffic. Private tandem networks are based on concentrated trunk carrier interfaces at select switching node locations; large trunk groups translate into greater traffic handling capacity per individual trunk circuit. If a virtual networking service is used, interexchange carrier tariffs reward customers by decreasing billing costs as traffic volume increases, making it an attractive alternative for customers who cannot financially justify dedicated private line facilities.

When the customer communications system infrastructure expands in size and geographic scope, it is vitally important that there is a sense of uniformity across the network. Network heterogeneity requires fewer management tools and reduces personnel and training expenses. Network heterogeneity allows for the dispersion of system administrators across the enterprise, with the capability to provide individual administrators with global responsibilities regardless of their physical locations. Dispersing administrators means fewer administrators because there is no need to have local administrators dedicated to a single system. Network administrators can be centralized in a single location for an entire network of communications systems or distributed among several strategic locations, according to the organizational policies of the corporate enterprise.

The fundamental characteristic of a centralized network management center is the support of multiple communications systems and associated administrative/maintenance functions. Integrated network management service tools include fault management, system administration, traffic analysis, directory services, call accounting, support inventory management, and database import/export. Centralization of resources, combined with remote management services, can reduce personnel requirements, the largest single cost item in operating a communications system network.

Single System PBX Network: On-net Multilocation Support

The simplest network design consists of a single PBX system. There are several single system design configurations based on the location of the system’s station users. These configurations are used to support the following types of communications requirements:

1. One or more station users at the same location who are physically remote from all customer premises locations housing PBX common equipment

2. One or more station users residing on the customer premises but exceeding the maximum loop length for their desktop telephone equipment

3. Station users physically remote from the customer premises location housing the main PBX common equipment room but supported by local common equipment

The first PBX configuration option supports remote teleworkers. The second and third configurations are based on a distributed common equipment architecture. Some PBX systems have a standard distributed port interface cabinet/carrier design, and others use hardware options designed for remote premises communications requirements.

The first single system PBX networking category supports station users who are remote from all common equipment but require desktop communications support as if they were located at their organization’s premises. These type of station users are now referred to as teleworkers. Teleworkers fall into two categories:

1. Fixed teleworker

2. Mobile teleworker

A fixed teleworker has a permanent desktop location relative to the remotely located PBX system. Fixed teleworker solutions are sometimes referred to as small office/home office (SOHO) configurations. Mobile teleworkers are constantly on the move, but need to be linked to their PBX system whenever and wherever they are. Another popular term for a mobile teleworker is road warrior. Road warriors are the newest breed of PBX station user and are growing in number at an alarming rate due to the proliferation of mobile computing and communications devices.

There are several available PBX options that support fixed teleworkers who require the same level of communications service and support as station users at the customer premises location. The oldest, and most basic, PBX option supporting off-premises station users is the OPX feature, a solution available for more than 20 years. The OPX feature requires a special local exchange carrier trunk circuit, known as an OPX circuit, to provide PBX system communications and signaling support to a remote analog telephone. The loop length of an OPX circuit connection to the remote station is usually limited to several miles without repeaters. Provisioning of OPX trunk services is also constrained by LATA boundaries. OPX station users have full access to all PBX features and functions but are operationally limited by their analog telephone instruments. No analog telephone supports out-of-band signaling to support multiple line appearances and proprietary PBX display field information. Off-premises and intercom calls to the remote station user are routed over the PBX’s OPX trunk. The remote station user can initiate intercom calls to other PBX station users and uses PBX trunk facilities for placing calls outside the PBX system.

SOHO applications requiring a higher performance desktop terminal, similar to the one available at the customer premises location, had limited options until the early 1990s. During the past decade several fixed teleworker solutions have been implemented:

1. Remote ISDN BRI telephones

2. Proprietary and third-party local loop distance extender options

3. Remote IP telephones/softphones

The first SOHO option based on ISDN BRI services was implemented by Intecom in the early 1990s. The PBX system interfaces to the PSTN via a digital trunk circuit by implementing ISDN PRI services, and the remote teleworker uses an ISDN BRI line to support a desktop ISDN BRI telephone that offers performance capabilities comparable to those of proprietary digital telephone instruments. PBX control signaling is carried over the ISDN trunk circuit’s D-channel to the remote location. This solution provides remote teleworker access to all PBX system features and functions and can support remote data terminal equipment over the second ISDN BRI B-channel.

A popular SOHO solution has been the use of local loop distance extender equipment to support proprietary digital PBX telephones over the PSTN trunk carrier facilities used to transport voice communications and control signaling between the customer premises and remote location. The first distance extender options were based on hardware equipment at the customer premises location—the proprietary port circuit cards or gateway modules, used to convert the proprietary out-of-band digital desktop control signaling into CAS format for transport over analog trunk circuits to connect PBX and remote teleworker locations. A desktop gateway module at the remote teleworker location supports a proprietary desktop digital telephone. Leading suppliers of local loop extender equipment include MCK Communications and Teltone. The option was developed when residential digital line services, such as ISDN BRI, were not commonly available. The growing availability of digital subscriber line (DSL) services has eliminated the need to convert digital signaling to CAS format. The wideband nature of current digital services available to SOHO locations allows several remote digital telephones to be supported over a single DSL line. Rack-mount carrier gateways at the remote location can support 12, 24, or more digital telephones with one or more digital T1-carrier facilities.

One of the very few early benefits of IP telephony was support of remote IP telephones using dial-up analog or digital lines at a remote location. Almost all IP-PBX systems can remotely support desktop IP telephone instruments or IP softphones via LAN/WAN infrastructures. The remote location configuration may require an analog gateway module or a SOHO router to access the corporate WAN.

Road warrior options include IP softphone applications running on a notebook/laptop computer, or any DTMF analog telephone or cellular handset, linked to the main PBX system through a proprietary communications/signaling port interface card, gateway module, or teleworker server. The mobile IP softphone option can be implemented by local LAN access to the corporate WAN or a wireless dial-up option wherever the station user happens to be. Several PBX suppliers are currently marketing mobile telephone options behind their communications systems, including Avaya, Nortel Networks, and Siemens. The Avaya Definity and Nortel Networks Meridian 1 options are based on the MCK Communications Mobile EXTender gateway. The EXTender gateway is configured behind the PBX system with the use of standard digital port interface links. The Siemens solution is based on a HiPath Teleworker server linked to the HiPath PBX system. For each road warrior option, the remote desktop telephone or cellular handset appears to the PBX system as an extension of the station user’s customer premises desktop voice terminal. Any DTMF telephone can be logged into the PBX to receive and place calls through the centrally located communications system. Road warriors can use intercom; four-digit dialing plans; activate basic call processing features, such as hold, transfer, and conference; and use the private PBX network for long distance calling. Unanswered calls are routed to a call coverage station or VMS mailbox rather than the remote telephone’s mailbox.

Cabling System Fundamentals

A structured cabling architecture design is intended to accommodate telecommunications technology changes with minimal impact on any of the other cabling subsystems, such as, electrical cabling. The target life cycle of an average cabling installation is up to 20 years. It is expected that a few generations of telecommunications systems will be installed and replaced or upgraded. Another planning assumption is that networking and bandwidth requirements will certainly increase during the life cycle of the cabling system. The following are key factors used to specify networks and cabling, as identified by Avaya in its SYSTIMAX CSC guidebook:

• Usage patterns, including combined size and duration of peak loads for all applications

• Expected increase in bandwidth demands

• The number of users and anticipated changes in that number

• Location of users and maximum distances between them

• The likely rate of change in users’ locations (churn)

• Connectivity with current and future devices and software

• Space available for cable runs

• Total cost of ownership

• Regulations and safety requirements

• Importance of protection against loss of service and data theft

PBX systems traditionally have been based on a star network topology. A star network topology includes many point-to-point links radiating from central equipment. The early LAN topologies were based on ring-and-bus network designs. A ring network topology has a continuous transmission loop that interconnects every device. The most familiar example of a ring network topology is the IBM token ring LAN. A bus network topology is a communications link that connects devices along the length of a cable. The original Ethernet LAN was based on a bus network topology.

Today’s dominant LAN technology is based on Ethernet standards. The logical topology of an Ethernet LAN is a bus topology, but the physical topology of the network is a star. Ethernet workstations that connect to an Ethernet hub or switch communicate over a high-speed bus housed in a hub or switch, but these network nodes are connected in a clustered star network topology. The star topology favored by PBX systems and adapted by Ethernet LANs is now the accepted communications system network topology.

The first Ethernet LAN installations were based on coaxial cable used for the transmission medium. During the mid-1980s the cabling used by PBX systems, known as unshielded twisted pair (UTP), was adapted for Ethernet LANs. Telephony UTP cabling was classified by IBM’s cabling system specifications as Category 3 and was used for 10Base-T Ethernet LANs operating at 10 Mbps. A 10Base-T Ethernet LAN used two pairs of Category 3 UTP cabling. A 100Base-T4 Ethernet LAN used four-pair Category 3 UTP cabling. A 100-Mbps Fast Ethernet, also known as 100Base-TX, used two-pair Category 5 UTP cabling. The 1000-Mbps (1 Gbps) Ethernet, 1000BASE-T, uses four-pair Category 5 UTP cabling. The 1000Base-TX, a lower cost alternative to 1000Base-T, uses the recently introduced Category 6 UTP cabling. PBX system telephony requirements can be satisfied with any of these UTP cabling types, making possible a single network cabling system infrastructure for voice and data communications applications.

In the SYSTIMAX SCS guidebook, Avaya lists the following considerations for choosing the type of customer network cabling:

• Maximum distance between network hubs and nodes

• Space available in ducting and floor/ceiling cavities

• The levels of electromagnetic interference (EMI)

• Likely changes in equipment served by the system and the way it is used

• Level of resilience required

• The required life span of the network

• Restrictions on cable routing that dictate cable bend radius

• Existing cable installations with potential for reuse

For the past two decades, most customers have used or installed two different cabling systems for telephony and data LAN applications. The evolution of the PBX system to an IP telephony platform will allow the large installed base of customers with installed circuit switched PBX systems to slowly phase out an infrastructure with two cabling systems and allow customers who are designing an entirely new converged voice/data network the opportunity to install a single cabling system. PBX systems installed before 1990 were implemented with Category 3 UTP, but more recent installations may have been based on Category 5 UTP, the same wiring used for data LANs. A newly installed communications system installation likely would be based on a generic cabling infrastructure using Category 5 UTP to provide for future needs.

A generic cabling system is a structured telecommunications cabling system capable of supporting a wide range of customer applications. Generic cabling can be installed before the definition of required applications because application-specific hardware (telephones, computers, etc.) is not part of the structured cabling design. Generic cabling can be enhanced through the use of flood wiring, which is the installation of sufficient cabling and telecommunications outlets in a work area to maximize the flexibility of the location for devices connected to the network. Many customers are currently installing four or six telecommunications outlets per work area, although the recommended minimum is two.

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.

The Case for Converged IP-PBX Systems

There are several advantages for implementing a converged IP-PBX system or a client/server IP-PBX. First let’s review the case for the converged IP-PBX system.

A converged IP-PBX system occupies the gray zone between the traditional PBX system and the evolving client/server design because it can offer customers the best of both worlds: the reliability, redundancy, and feature/function performance benefits of legacy circuit switched PBXs and the unique capabilities of ToIP technology to leverage LAN/WAN infrastructure in support of dispersed common carrier equipment and desktop terminals. A converged PBX system is best viewed as a bridge between the existing circuit switched world of voice communications and the emerging packet switched world. Instead of attempting to leap from the old world to the new world in one jump, it makes more sense to travel a longer, but less risky, road.

A converged IP-PBX system and an IP packet switched client/server platform can provide each of these customer benefits. The latter solution is usually optimized in a green field situation—a new customer location without a previously installed system, although a customer may still elect to install a converged system for incremental migration from a circuit to a packet switched solution. Many customers with an existing circuit switched system installation are likely to upgrade to a converged system with a minimal investment in new hardware and/or software. In contrast, a client/server design represents a major design break from previously installed circuit switched PBX systems and entails replacement of most existing common equipment and desktop terminal instruments.

The following are probable reasons a customer requiring ToIP capabilities might choose a converged IP-PBX system solution instead of an IP packet switched client/server design:

1. ToIP requirements

2. Investment protection

3. Critical reliability

4. Private network compatibility

5. Feature requirements

6. Pricing

ToIP Requirements

A large number of PBX system customers may not currently require ToIP capabilities for their enterprise communications system, although future plans are very likely to require support of ToIP options. A converged IP-PBX system is fully capable of being configured without any IP-based elements at initial installation but can support such a requirement when needed. The group of customers who are risk-averse may also choose to delay installation of ToIP options at the present time because they are taking a wait-and-see attitude toward the emerging technology. Early versions of products incorporating new technology may not satisfy accepted benchmark reliability standards for telephony applications. In addition, ToIP standards are still in a state of flux, and customers may wish to wait until control signaling protocol and voice codec standards have stabilized. Some first-wave customers who installed IP-PBX systems shortly after product introduction have watched as evolving standards and system upgrades obsoleted their installed terminal equipment, voice codecs, and/or telephony servers. A converged IP-PBX reduces this risk by allowing customers to upgrade and enhance their system for active ToIP capabilities when the time is acceptable.

A converged IP-PBX system is also ideal for customers who wish only to test ToIP technology without installing a 100 percent IP peripheral solution. For trial purposes it is less costly to use a converged IP-PBX system that is also functioning as the full-time circuit switched communications system than to purchase and install a dedicated IP packet switched client/server design. For trial purposes, a select number of IP peripherals can be installed on a converged IP-PBX system. If the trial is successful, additional IP ports can be equipped and activated when needed. A very important factor in the successful implementation of an IP-PBX system is the LAN/WAN infrastructure, because the network must be properly designed and programmed to provide an acceptable Quality of Service (QoS) level for real-time voice communications applications. A small-scale IP-PBX trial is usually necessary to discover in advance whether or not a major LAN/WAN overhaul is needed. What works on paper does not always work in real life. Using a converged IP-PBX system is the most efficient solution for trial testing ToIP QoS levels for station and/or trunk traffic communications.

Investment Protection

All customers make substantial financial and organizational investments in their installed premises communications system and usually seek to maximize their return on investment (ROI). Replacing an installed circuit switched PBX system with a new IP packet switched client/server design solution at the present time may be counter to this customer objective. For example, a customer may not have fully depreciated the installed system’s common equipment and desktop terminals. Replacing cabinet and port interface hardware with a telephony call server and gateways and digital telephones with new IP telephones is an expensive proposition, as are major upgrades to the LAN/WAN infrastructure to support real-time voice-grade QoS levels. Training expenses for station users, system managers, and maintenance personnel also add to upfront cost outlays. Additional costs are associated with a disruption of communications operations and procedures when migrating from an installed system to an entirely new platform. Although the data communications world has grown accustomed to constant change, one of the most fundamental characterizations of the voice communications world is reluctance to change.

Upgrading an installed circuit switched PBX system to a converged IP-PBX system is less costly than overhauling the entire communications system and network and is typically a far less disruptive experience because most station users are likely to retain their legacy desktop terminal equipment over the short term. The few station users who migrate to a ToIP desktop are more easily trained and supported in this environment. All of the features and functions available to station users before the system upgrade will remain available afterward, which is not usually the case if the legacy common control design is replaced with a new telephony call server loaded with a different software package.

PBX life cycles have fluctuated during the past several decades. Before the introduction of the computer-controlled digital PBX in the 1970s, the typical installed life of a PBX system was greater than 10 years. PBX systems did not change significantly over short periods. During the 1980s, the typical PBX life expectancy shrunk to between 6 and 8 years because of continual major design changes and dramatic software program upgrades. Since the early 1990s, the life cycle of an installed PBX system has slowly been increasing because system designers have become more cognizant of product migration strategy and its effect on market positioning and sales. Another reason for increased system life is that an increasing number of recent system performance enhancements and upgrades had minimal effect on the core processing and switching system design, because they were focused on peripheral server applications. The concept of upgrading an older PBX system to the current platform instead of the earlier system forklift approach makes possible a cost effective and operationally efficient migration from a circuit switched design platform to a converged circuit/packet switched system.

Upgrading a circuit switched PBX system to a converged IP-PBX system may be as simple as adding a few new port interface cards that provide ToIP gateway and gatekeeper functions for IP peripherals (stations, trunk). A gateway used for ToIP applications is defined as a device that provides a translation, or conversion, between IP and TDM/PCM signaling protocol and communications signals. There must be a physical and logical interface between circuit and packet switched communications networks. A gatekeeper performs or facilitates several basic call control functions within an IP communications network: peripheral equipment registration with the network; address translation of LAN aliases (i.e., telephone directory numbers into IP addresses); and bandwidth management of LAN/WAN network resources. The gatekeeper function in a pure IP communications design is similar to the call control processor in a traditional PBX system. Additional interface cards may be required for support of remote cabinets and port carriers when using the LAN/WAN to transport intercabinet signaling for call control and voice communications traffic. In some cases there may be a requirement for a call processing and/or system memory upgrade. It is most likely that a generic software release upgrade would be required unless a very recent software release is already installed.

A sizable percentage of the current installed base of circuit switched PBX systems can be upgraded to a converged IP-PBX system platform with the hardware/software additions just described. It is estimated that more than 65 percent of the current installed PBX base can be upgraded to a converged IP-PBX system without a major system overhaul. As the oldest installed PBXs are replaced or upgraded, the percentage of upgradeable systems will continue to increase. More than two-thirds of currently installed circuit switched PBXs can be upgraded in place to a converged IP- PBX system platform while protecting up to 90 percent of a customer’s original hardware/software investment. Examples of circuit switched PBXs installed during the past decade that are easily upgraded to a converged system include Avaya Definity ProLogix and ECS models, Nortel Networks Meridian models (Option 11C/51C/61C/81C), Siemens Hicom 300 models, and NEC NEAX 1000/2000/2400 models. These systems alone represent almost two-thirds of the North American installed PBX system base.

Critical Reliability

Traditional circuit switched PBX systems are known for their high reliability standards. The frequently quoted 99.999 percent system reliability benchmark is not a marketing gimmick but the reality. Five “9s” does not apply to every system PBX system component, such as a port circuit card, but to overall system availability. Individual port circuit cards or telephone instruments occasionally may fail, and software glitches may cause a feature failure or call disconnect, but total system failure is a rarity in the world of telephony. The reason for high system reliability, as a result of very low PBX system component failure rates, commonly expressed as Mean Time Between Failures (MTBF) or Mean Time Between Outages (MTBO), is that many system operations are supported by redundant hardware and/or software elements and great care in the electronic design and manufacture of hardware components. During the past decade, most PBX customers have installed and operated their communications systems without ever experiencing a catastrophic failure. Traditional circuit switched PBX technology has reached the bottom plateau of the failure rate curve. In case of failure, redundant system elements, such as main processor boards, system memory storage, switch network and transmission paths, and power supplies, are usually duplicated in a hot standby mode for intermediate and large PBX system models from many, but not all, system suppliers. For example, the Siemens HiPath 4000 and NEC NEAX 2400 IPX systems offer optional duplication of the listed critical system elements.

Although a converged IP-PBX is designed and equipped with several new hardware components and its software generic program includes new features and functions, the system, for the most part, is based on tried and true technology. The most important architecture element of any PBX system design is its common control complex, whether it is based on a proprietary cabinet carrier equipped with several printed circuit board modules or a third-party processing server. All PBX functions begin and end under the control and supervision of the common control complex. Traditional circuit switched PBXs and the upgraded converged IP-PBX version are based on the same common control complex, with perhaps a few modifications, such as an upgraded processor board. The hardware and software components and the core internal diagnostics, maintenance, and management functions remain basically unchanged when the system is upgraded to support ToIP capabilities and applications. The catastrophic failure rate should remain at (or be very close to) the expected 99.999 percent level. Unless an expensive fault tolerant server is used in the client/server IP-PBX system design or a dedicated back-up server is available, the common control reliability level will be less than that offered by a converged IP-PBX system. It should be noted that no client/server IP-PBX system currently uses a fault tolerant server, and very few are currently available with a backup server option.

The reliability of the PBX center stage switch complex is also a very important system factor for minimizing occurrences of catastrophic failure and supporting communications connections. In a converged IP-PBX, the center stage switch function is necessary for all calls among circuit switched peripherals and calls between circuit switched and packet switched peripherals. A client/server IP-PBX design makes use of LAN/WAN switches and routers for all call connections, even calls originating or terminating at non-IP ports. Although some converged IP-PBXs are based on a redundant internal switch network design with numerous duplicated hardware elements, a redundant LAN/WAN design requires multiple switches and routers at the Layer 2 and Layer 3 network levels for redundant connections and transmission paths for calls. More equipment is needed, more communications links must be supported, and more overhead costs are incurred. A configuration with a sizable number of non-IP peripherals in the IP-PBX configuration favors a design with traditional circuit switching capabilities in addition to ToIP capabilities. Except in a few isolated situations, there are very few intermediate/large customer installations that have mandatory requirements for 100 percent IP station users. Until the percentage of IP desktops outnumbers traditional analog and digital desktops, the converged IP-PBX system solution may be the preferable solution for customers with ToIP requirements.

Private Network Compatibility

There has been significant growth in the number of PBX private networks during the past 20 years. Private networks initially were limited to Fortune 500–type customers who had sufficient traffic volume to justify expensive private line facilities. The boom in private networks can be traced to the introduction of virtual private networking (VPN) services in the 1980s, such as the AT&T’s Software-Defined Network (SDN), and the continuing decline in private line lease rates that coincided with the increased availability of wideband and broadband digital carrier facilities. Many present-day private networks are based on a mix of private lines and virtual network facilities and provide a high degree of feature-transparent operation across PBX system locations.

Intelligent feature transparent networking requires a common PBX system platform for optimal transparency of feature/function operation. The evolving Qsig.931 standard for interoperability between dissimilar PBX systems currently provides a limited level of transparency among most of the leading PBX systems. Although a Qsig-based private network implementation may be adequate for some customers, it is not an acceptable solution for most customers. A multisystem network, including PBXs from a variety of suppliers, does not lend itself to a unified systems management solution. The option to centralize network and systems management functions at one location is not currently available in a mixed system platform network. There are other network issues to consider, such as feature/function and desktop terminal uniformity. Unique features on one system cannot be supported transparently across the network to be enjoyed by all stations users. If station user interfaces and telephone instruments are not standardized across the network, training costs increase and station user productivity is affected when an individual moves between network locations.

Taking into account these private networking issues, a customer wishing to migrate from a circuit switched PBX to an IP-PBX is best served by upgrading the installed system to a converged system platform. The upgraded and converged IP-PBX system will retain existing networking capabilities, and station users will have continued access to their accustomed feature sets. A few converged IP-PBX offerings, such as the Siemens HiPath 3000/4000 families and NEC NEAX 1000/2000/2400 families, provide IP station users the option of simply adding an IP adapter to the installed digital telephone or installing a replacement IP telephone with the same look and feel as the older digital telephone model. Replacing a circuit switched PBX system with a client/server IP-PBX system from another supplier will reduce networking performance and force station users to learn how to use a new telephone to access and implement a different feature set.

Feature Requirements

Each customer has unique feature requirements, although there is a common core of features on most everyone’s shopping list that is available with most every PBX system, regardless of switching technology or architecture design. A survey of the leading circuit switched PBX systems indicates that there are at least 500 software features that support a wide range of customer applications, ranging from basic station user desktop features, such as Call Forward, to advanced contact center ACD features, such as ACD agent skill profiling. Most station users, when surveyed, will come up with a list of fewer than a dozen PBX features that they commonly use in their everyday workplace. This does not mean that PBX systems should have a much smaller set of features because the typical station user uses a small percentage of currently available features.

Different station users use different features, and it is likely that in a large system environment a very high percentage of the available PBX features are used by at least one of the system’s station users or administrators. Unique user populations within the PBX system make use of different features groups, such as attendant features, message center features, or ACD features. There are also many PBX features that station users are not aware of that support high-level system operations that are activated concurrently with many station users operations, such as CDR for off-premises calls, or Automatic Route Selection (ARS) when placing long distance calls.

Most of the currently marketed circuit switched PBX systems have software feature packages based on more than 20 years of additions, upgrades, and enhancements. A converged IP-PBX based on its antecedent circuit switched system platform would share the same highly developed and refined feature package, with no sacrifice in performance potential. Very few client/server IP-PBXs are based on previously available circuit switched PBX software feature packages. Most of the first-generation client/server designs are from system suppliers relatively new to the communications system market, with less than 5 years of software feature development. In addition, a few experienced PBX system manufacturers currently offer client/server IP-PBXs with far fewer features and functions than are available with their traditional circuit switched systems.

An analysis of the currently available client/server IP-PBX systems reveals that there are several functional areas where these new system designs are likely to be feature deficient when compared with circuit switched or converged system designs. Feature/function gaps are most common in attendant position, ACD, and private networking. There is also the occasional missing desktop station user feature that has been a longtime standard offering on circuit switched that customers cannot do without.

It has been the standard practice for customers to always ask for more features and functions in their new communications systems in addition to the features they have in their currently installed PBXs. Upgrading to a converged IP-PBX would satisfy this requirement. Replacing a circuit switched PBX system with a client/server IP-PBX that lacks more than a few traditional features and functions should not be acceptable because a smart customer does not trade a few new ToIP features for longtime available features.

Pricing

Price is a concern for all customers across all market segments. Very few customers have unlimited funds for their next communications system purchase. Among all the customer purchase criteria, pricing is the most prevalent. Every PBX system configuration has its own price point, and few customer configurations are identical. One cannot say that a converged IP-PBX is always priced higher or lower than a client/server IP-PBX because it is configuration dependent. Based on current pricing schedules, however, comparisons between the two IP-PBX design types can be made for specific defined configurations, and there are several pricing model assumptions that are usually valid regardless of system model:

1. An IP telephone is priced higher than a digital telephone with comparable capabilities, such as line appearances, programmable feature buttons, display field, speakerphone option.

2. Analog station (telephones, fax terminals) and PSTN trunk circuit connections are more expensive with a client/server design because gateways are more expensive than the traditional port circuit cards used in converged IP-PBXs.

3. Emergency power costs are greater for a client/server design because there is more distributed hardware equipment, such as telephony call servers, database servers, Ethernet switches, routers, and desktop terminals.

4. The cost to add an incremental IP port to a converged IP-PBX is greater than a client/server design because the converged system requires a port circuit card housed in a port carrier to support the added port.

5. Cabling costs for a green field installation are less for a client/server design than for a converged design.

Adding a few IP ports to a circuit switched PBX upgraded to a converged system will naturally be far more cost effective than replacing the entire system with a client/server design. If a significant number of IP ports are required, however, the cost of a client/server design is likely to be less expensive because the only significant variable cost is the price of a telephone. Converged systems require gateway/gatekeeper function port circuit cards to support IP telephones and/or IP trunk circuit connections for non-IP stations.

Figure 1 and 2 shows the two types of IP-PBX designs at a fixed port capacity. The customer configuration assumes a mix of single-line analog telephones, multiple-line telephones (digital or IP), PSTN local trunk circuits, and private network trunk circuits (PSTN or IP WAN). Design requirements such as redundancy (call processing, memory storage, power, switching) can significantly influence the shape of the two curves, as can advanced application requirements, such as contact centers, but the general trend lines would remain the same.

Figure 1: IP-enabled circuit switched PBX.

Figure 2: TDM/LAN IP-PBX.

Major differences in the design types are best exemplified at the two extremes of the price plots, 0 percent and 100 percent IP ports. At minimal mandatory IP port requirements, a converged system is priced significantly less than a client/server design that is ill-suited to support non-IP ports, despite a lower cost for common control and reuse of LAN switches and IP routers, because IP telephones are more expensive and support of analog devices is very expensive. At maximum IP port requirements, a converged system is priced significantly more than a client/server design because of the requirement for gateway/gatekeeper port circuit cards. As mandatory IP port requirements increase, a client/server design is the favored solution because higher priced IP telephones are offset by reduced common equipment and wiring costs as compared with a converged solution.

A few closing comments regarding IP-PBX system pricing:

1. Client/server designs are priced lower than converged solutions as mandatory IP port requirements increase and/or traditional circuit switched port requirements decrease.

2. Green field environments are optimal for client/server designs because the newly installed LAN/WAN infrastructure can be initially designed and voice-grade QoS, and a single cabling system can be installed for all media communications needs.

3. Upgrading a circuit switched PBX to a converged IP-PBX system is more cost effective than replacement with a client/server system, regardless of IP port requirements, because the common control complex and cabinet equipment is already in place and paid for.

Current IP-PBX System : Siemens

Siemens
Siemens purchased three major PBX makers, based in the United States, Belgium, and Britain, during the early 1990s and so has the largest share of the worldwide installed base of PBX systems. The company also claims to have sold more digital CO ports, at well over 100 million, on its EWSD system than any other telecom manufacturer.

For small and medium-sized enterprises, Siemens offers the HiPath 3000 family of IP platforms, with the user capacities that are stated in Figure 1. These systems can be linked in an IP-based network with the AllServe 150 applications processor, to support up to 1,000 users.


Figure 1: Capacity of HiPath 3000 call servers.

Each of these call servers is available in a 19-inch rack-mounting form (the 3300) or as a cabinet, which is wall-mounting (3550) or floor-standing (the HiPath 3750). For markets with European ISDN standards, Siemens also supplies two smaller systems, which are not strictly IP-PBXs: the HiPath 3150, for up to 14 users, and the HiPath 3250, with two basic rate interface (BRI) ports.

In association with its HiPath systems, Siemens introduced a range of optiPoint 500 phones, replacing the optiPoint 300 sets, which had garnered praise for their ergonomic qualities but could not support in-line dc power over the LAN. Five optiPoint 500 IP telephones are available, ranging from an entry model to the advanced, of which three have a Universal Serial Bus (USB) interface, while four models have a display and loudspeaker. Additionally, the optiPoint 400 phones are multiprotocol sets designed for platform and location independence, while still having a built-in Ethernet interface and power-over-LAN capability.

The Siemens CorNet package facilitates networking over an IP WAN, or the PSTN with the more powerful HiPath 4000 or 5000 platforms, and Siemens emphasizes that applications need only be installed once to be accessible across the entire company and from every workstation. Under the HiPath brand name are Xpression for unified messaging, ProCenter for multimedia contact centers, and Fault Management software.

The HiPath 4000 is an IP convergence platform, available in three models, that supports up to 30,000 users on the largest system. The HiPath 5000 is a pure IP communications system, to which all the features and functions of the Siemens' HiCom300 PBX have been transferred, and which can be installed on industry-standard servers running Microsoft Windows NT or Windows 2000.

Siemens deployed its HiPath 5000 system to support over 1,000 IP phones and soft clients in its new San Jose, California, facility during 2000. A detailed diagram, showing how many of Siemens' IP telephony products may be used, is shown in Figure 2.


Figure 2: Siemens' HiPath systems and terminals.

The RG 2500 is a VoIP gateway that transforms voice signals into IP packets (or vice versa). The optiClient 330 is a PC-based soft client, using the Windows format. The HiPath AP 1100 and 1140 provide analog ports on the line side. The PhoneMail system is a high-performance voice mail product that was inherited by Siemens from ROLM via IBM.

Current IP-PBX system : Nortel Networks

Nortel Networks
Nortel Networks claims that it is the only telecom equipment supplier to "remain in both camps," believing that it is absolutely necessary to give the customer the choice between a TDM-based PBX, for the lowest single site costs, and an IP-PBX, where that may make sense.

Nortel is certainly the leader in providing IP-enabled telephony, through an Internet Telephony Gateway (ITG) Trunk card, which plugs into a Meridian 1 PBX and may be programmed to support trunks with an IP-network. Another version of this ITG can have up to 96 users connected to one card on the line side, so that the capacity of Nortel's Meridian Option 81C can go up to 16,000 IP phones. Nortel's ITG Line Card actually has 24 DSP ports.

Most of Nortel's large PBX customers have implemented these ITG cards to carry voice traffic over IP long-haul networks, and this was an excellent way for these organizations to gain VoIP expertise. Microsoft Corporation, for example, connected 87 Meridian 1 PBXs over its IP-VPN and recovered the cost of these ITG installations, with long-distance savings, in less than 6 months.

Nortel offers two remote office units, the models 9110 and 9150, which support IP phones, but overcome the problems of local calling and emergency 911 requirements by using BRI/ISDN trunks. These units have a key capability of dynamic fallback, even during a conversation, between an IP network and the PSTN. If the trunk channel over the customer's IP-VPN fails or degrades badly, the call is switched to the PSTN, but it can return automatically to the IP network upon restoration of service, saving the customer money.

A variety of client endpoints is available for VoIP use. Nortel has two IP phones (the i2004 and i2002), the i2050 softphone, software to make the Palm Pilot SIP-enabled, wireless phones made by Symbol, and an IP-adapter base for the 39xx series of digital sets. If a Nortel IP phone and a PC are to share one LAN outlet, then a three-port switch adapter base for the i series phones must be purchased. The use of these peripherals in a CSE 1000 configuration is shown in Figure 1. Nortel reports that some early IP telephony installations used a dedicated LAN, with no data traffic on the same wiring.


Figure 1: Succession CSE 1000 configuration.

Previously existing subsystems for unified messaging (Call Pilot), contact centers (Symposium), and system management (Optivity) have been adapted to interface with the CSE 1000, which is Nortel's enterprise-level, IP-oriented call server, using the brand name Succession. One CSE 1000 can handle up to 1,000 users and at least 10 servers may be in one network. This server uses the same UNIX-like operating system as Nortel's smaller TDM PBX, the option 11C system, so that it was fairly easy to transfer all 450 telephony features to a pure IP architecture.

The Succession Media Gateway, the unit that provides links to WANs, uses TDM trunk cards that are the same as those purchased for legacy Meridian PBXs, delivering a major cost saving to customers. This media gateway has some local call processing capability and is, therefore, useful for remote locations to provide service survivability.

Nortel's multimedia exchange system, the CSE-MX, is a good example of the benefits that come with IP telephony and new protocols, such as SIP. The CSE-MX is a multimedia application server, which facilitates video conferencing and instant messaging within an enterprise network. With multimedia services the setup of a multiparty video conference, between preregistered participants, should be feasible with a few mouse clicks, and collaborative working between remote offices is greatly improved by the sharing of Web sites, files, visuals, and electronic whiteboard.

The CSE-MX also supports dynamic registration (i.e., "find-me and follow-me" service) for mobile and telecommuting users, and provides a personal call agent. This function can be used for call screening and call routing to user-defined locations, which should result in the need to process fewer voice and electronic mail messages.