VoIP Communications Systems Security

DoS attacks, whether they are intentional or unintended, are the most difficult VoIP-related threat to defend against. The packet switching nature of data networks allows multiple connections to share the same transport medium. Therefore, unlike telephones in circuitswitched networks, an IP terminal endpoint can receive and potentially participate in multiple calls at once. Thus, an endpoint can be used to amplify attacks. On VoIP networks, resources such as bandwidth must be allocated efficiently and fairly to accommodate the maximum number of callers. This property can be violated by attackers who aggressively and abusively obtain an unnecessarily large amount of resources. Alternatively, the attacker simply can flood the network with large number of packets so that resources are unavailable to all other callers.

In addition, viruses and worms create DoS conditions due to the network traffic generated by these agents as they replicate and seek out other hosts to infect. These agents are proven to wreak havoc with even relatively well-secured data networks. VoIP networks, by their nature, are exquisitely sensitive to these types of attacks. Remedies for DoS include logical network partitioning at layers 2 and 3, stateful firewalls with application inspection capabilities, policy enforcement to limit flooded packets, and out-of-band management. Out-of-band management is required so that in the event of a DoS event, system administrators are still able to monitor the network and respond to additional events.

Theft of services and information is also problematic on VoIP networks. These threats are almost always due to active attack. Many of these attacks can be thwarted by implementing additional security controls at layer 2. This includes layer 2 security features such as DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, Port Security, and VLAN ACLs. The fundamental basis for this class of attacks is that the identity of one or more of the devices that participate is not legitimate.

Endpoints must be authenticated, and end users must be validated in order to ensure legitimacy Hijacking and call interception revolves around the concept of fooling and manipulating weak or nonexistent authentication measures. We are all familiar with different forms of authentication, from the password used to login to your computer to the key that unlocks the front door. The conceptual framework for authentication is made up of three factors: “something you have” (a key or token), “something you know” (a password or secret handshake), or “something you are” (fingerprint or iris pattern). Authentication mechanisms validate users by one or a combination of these. Any type of unauthenticated access, particularly to key infrastructure components such as the IP PBX or DNS server, for example, can result in disagreeable consequences for both users and administrators.

VoIP relies upon a number of ancillary services as part of the configuration process, as a means to locate users, manage servers and phones, and to ensure favorable transport, among others. DNS, DHCP, HTTP, HTTPS, SNMP, SSH, RSVP, and TFTP services all have been the subject of successful exploitation by attackers. Potential VoIP users may defer transitioning to IP Telephony if they believe it will reduce overall network security by creating new vulnerabilities that could be used to compromise non-VoIP systems and services within the same network. Effective mitigation of these threats to common data networks and services could be considered a security baseline upon which a successful VoIP deployment depends. Firewalls, network and system intrusion detection, authentication systems, anti-virus scanners, and other security controls, which should already be in place, are required to counter attacks that might debilitate any or all IP-based services (including VoIP services).

H.323 and SIP suffer security vulnerabilities based simply upon their encoding schemes, albeit for different reasons. Because SIP is an unstructured text-based protocol, it is impossibly to test all permutations of SIP messages during development for security vulnerabilities. Its fairly straightforward to construct a malformed SIP message or message sequence that results in a DoS for a particular SIP device. This may not be significant for a single UA endpoint, but if this “packet of death” can render all the carrier-class media gateway controllers in a network useless, then this becomes a significant problem. H.323 on the other hand is encoded according to ASN.1 PER encoding rules. The implementation of H.323 message parsers, rather than the encoding rules themselves, results in security vulnerabilities in the H.323 suite.

Threats to VoIP Communications Systems

Converging voice and data on the same wire, regardless of the protocols used, ups the ante for network security engineers and managers. One consequence of this convergence is that in the event of a major network attack, the organizations entire telecommunications infrastructure can be at risk. Securing the whole VoIP infrastructure requires planning, analysis, and detailed knowledge about the specifics of the implementation you choose to use.

Table 1 describes the general levels that can be attacked in a VoIP infrastructure.

Table 1: VoIP Vulnerabilities 

Vulnerability	Description
IP infrastructure	Vulnerabilities on related non-VoIP systems can lead to compromise of VoIP infrastructure.
Underlying operating system	VoIP devices inherit the same vulnerabilities as the operating system or firmware they run on. Operating systems are Windows and Linux.
Configuration	In their default configuration most VoIP devices ship with a surfeit of open services. The default services running on the open ports may be vulnerable to DoS attacks, buffer overflows, or authentication bypass.
Application level	Immature technologies can be attacked to disrupt or manipulate service. Legacy applications (DNS, for example) have known problems.

The Fundamental Enterprise Communications Systems

Current voice communications systems comprise five fundamental product categories:

Key Telephone System (KTS)

Private Branch Exchange (PBX)

Automatic Call Distributor (ACD)

Voice Messaging System (VMS)

Interactive Voice Response (IVR)

The first three categories support call processing and switching functions to enable telephone calls between two or more station users. The latter two product categories are designed to work in conjunction with one of the three core communications switching systems to provide optional services beyond a basic station-to-station call. It’s possible to integrate voice messaging or IVR capabilities into a KTS, PBX, or ACD product design, but most companies don’t. Instead, customers have traditionally chosen to install external, stand-alone systems for messaging and voice response applications. (Many small KTS products have an integrated voice messaging function, but the messaging features are typically not as robust as stand-alone offerings.)

KTS
A KTS is a customer-premises communications system designed to support basic voice applications and relatively small station user requirements. KTS got its name from its historical use with proprietary telephones, known as key telephones, which interface with a central control cabinet known as a Key Service Unit (KSU). The KSU is equipped with the system’s call processing control, port interface cards, and a variety of system/service circuit cards, such as Dual Tone Multi Frequency (DTMF) receivers and Input/Output (I/O) interfaces. The KSU performs central office line connection, intercom functions, paging, and station connections. Its common control elements include a call processor and system memory databases, and its most important function is the provisioning of dial tone. Other basic call processing functions are call answering, dialing, and transaction features such as hold, transfer, call forward, and conference.

Oddly, not all KTS products require a KSU. Instead, the intelligence needed to perform call processing and switching can be built into the circuitry of each key telephone instrument. Such systems are easy to install and maintain, but usually have limited feature and function capabilities, and are acceptable only for customers with modest port-size requirements. The KSU-less system is usually installed to work behind Centrex services offered by local telephone operating companies, which provide the more advanced features and functions through their central office communications switching system.

Common to KTS telephone instruments are designated, programmable key buttons for making and receiving off-premises calls over telephone company line circuits (trunks). The term KTS takes its name from the telephone instrument keys (analogous to typewriter keys) integrated into the product design. The line keys for each telephone instrument have direct access to off-premises telephones. Because trunks are distributed over and shared across groups of select telephones, each station user’s desktop instrument must be provisioned with multiple-line access keys. This is the distinguishing characteristic of a KTS: station user selection and access to designated telephone company lines. A pure KTS product supports only multi-line key telephone instruments and is incapable of supporting industry standard 2500-type single-line analog telephones unless a designated line circuit is dedicated to a single analog telephone instrument. Needless to say, it’s unusual for a customer to configure a KTS in this manner. Small system customers who want station users with 2500-type telephones to have shared access to a pool of trunks do have an alternative: a KTS/Hybrid product (see below), designed to support a mix of proprietary multiple-line button phones and nonproprietary single-line analog phones.

PBX
PBXs aren’t just big KTSs with more features and functions. The two share architecture elements, but PBX systems are designed for more robust functionality, greater growth capacities for ports, traffic, and call processing, and more levels of redundancy. PBX basic architecture includes the common control carrier/cabinet, port carriers/cabinets, and port circuit cards. Peripheral equipment support includes proprietary telephones, both single and multiple line, and industry standard single-line analog telephones.

First, let’s look at the major design and operational difference between a KTS and PBX. PBX stations can place calls over telephone company trunks only with the shared pool access method. The sole exceptions are telephones equipped with an optional private line for inbound and outbound calls. [Note: for reasons too complex to explain, the term line, when used in relation to a PBX system, usually refers to all customer premises equipment peripheral endpoints and is not a reference to a trunk circuit, as it would be with a KTS. The terms station and line are both used for PBX endpoints (telephones, modems, fax terminals) that are not off-premises trunk circuits.]

Hybrid System
Hybrid communications systems also share operating functions common to standard KTS and PBX systems. Original Hybrid systems were designed to more closely resemble KTS rather than PBX systems, although differences between the product categories are diminishing. Like KTS, Hybrid systems are based on a control cabinet similar to a KSU and can support a variety of port circuit boards for interfacing to station and trunk circuit equipment. All Hybrids support multiple-line proprietary key telephones and industry-standard single-line analog telephones. In a Hybrid system, phone access to line circuits is identical to that of a pure KTS, but single-line analog phones access a defined pool (group) of telephone company line circuits. This latter design capability is what distinguishes a pure KTS from a Hybrid system. The Hybrid’s port-oriented architecture design permits custom configurations to suit specific business applications. The architecture and technology design foundations of current Hybrid systems are more similar to PBXs than to KTSs. In fact, features and functions are sometimes difficult to distinguish from more expensive PBX systems.

Unfortunately confusion reigns when it comes to product category typing a communications system as KTS, Hybrid, or PBX. Some manufacturers call their Hybrid offering a KTS/Hybrid and others may refer to it as a Hybrid/PBX. The naming issue gets interesting in the United States because the Federal Communications Commission classifies customer premises communications systems as either KTS or Hybrid based on how single-line telephones access the central office. If the phone can access only one line as programmed by the system administrator, the system is a KTS; if it can access a pooled group of lines, the system is considered a Hybrid. Some manufacturers may even register a single system as both because the call processing software allows configuration flexibility for either pooled- or single-line access from a single-line telephone. Note that designating the product as a KTS, Hybrid, or PBX system may have financial consequences based on telephone company jurisdiction because trunk tariffs for linking a customer premises communications system to the central office can differ between KTS and PBX. (This was more common 15 years ago than it is today.) Ultimately it is the local telephone company that defines the type of system the customer is seeking to connect to the central office.

ACD Systems
The central component of a customer call center is an ACD. ACD systems were originally developed to handle large volumes of incoming calls and automatically route them to designated answering positions. ACD systems are designed and customer programmed to satisfy higher quality of service standards than PBX systems for the following call processing functions:

Screening

Routing

Queuing

Answering

Most PBX systems can be programmed to function as ACD systems, but few ACDs can be programmed to function as PBXs and continue to support most of the latter product’s standard or optional features and functions. Nevertheless, an ACD system shares many of the architecture and feature capabilities of a PBX system. You can think of it as a PBX designed for a very specific application—to distribute incoming calls equitably to a group or groups of answering stations. We usually call ACD answering stations agents, and this is the fundamental difference between PBX and ACD system service: calls handled by a PBX are routed to a specific station user, whereas ACD calls are routed to a group of stations, although call analysis programs can be used to route the call to a specific agent in a group.

ACDs exhibit several architecture design and feature standards that are often not adhered to for PBXs. A true ACD system is based on a nonblocking switch network design, has sufficient call processing power to handle a large volume of complex call types, and has software program- ming features that can screen, route, and distribute calls to agent positions fast and efficiently. Other distinguishing standard ACD system attributes are the ability to support specialized stations, known as supervisor positions, and an integrated MIS reporting system used to monitor, track, and analyze call center operations. All of these features are standard in stand-alone ACD systems, but PBX systems may fail to meet the same standards. Indeed most PBXs must be traffic engineered to support non-blocking switch network access and post-equipped with optional software and external applications servers to all but the most basic ACD feature and MIS capabilities.

Early ACD systems were stand-alone products designed exclusively for a call center environment with large call volumes, such as an airline reservation center. During the early 1980s several PBX systems were designed with optional software that could support basic ACD functions but could not match their performance level. By the 1990s a growing number of PBX systems enhanced with optional ACD software and external MIS reporting systems started to look functionally competitive with stand-alone ACDs. Similar PBX systems with optional ACD packages now control more than 80 percent of the market for call center communications systems. Although stand-alone ACDs hold their own at the high end of the market for large, complex feature and function requirements, PBX and ACD systems totally dominate the call center market segment for systems with fewer than 100 agents. Many KTS/Hybrid systems can also be configured with optional ACD capabilities and are gradually penetrating the very small call center market segment for systems with fewer than 20 agents. Why has the average size of an ACD call center system continually declined over the past 20 years? Customers are realizing that programmable call routing, distribution, and reporting features are beneficial for a variety of nontraditional ACD applications, such as internal help desks and groups of attendant positions. Today’s average ACD installation has only about 60 agent positions, and that number is declining.

Voice Messaging System
Most enterprise environments use a VMS as the primary call coverage point for unanswered calls, but you’d be selling the VMS short to think of it only in terms of message record and store. A good VMS mailbox can:

Be programmed for different greetings

Offer incoming callers a menu of options for leaving a message or transferring to another station

Act as an automated attendant position to answer and route calls

Serve as an automated information system or an outbound call messaging system

VMSs can be interfaced to almost all current generation KTS/Hybrid, PBX, and ACD systems by using a signaling link between the VMS, the switching system, and its voice communications channels. The signaling link is usually referred to as the voice mail system interface or, in standards parlance, the Station Message Detail Interface (SMDI). Among other functions, the link activates the message-waiting indication at a user station. Its voice communications channels will be based on 2500-type analog station interfaces, a standard interface supported by all systems.

Here’s what happens when a caller leaves a message. VMS coders/decoders (codecs) take the transmitted voice communications signals from the switching system, digitize them, and compress them for storage purposes. The same codecs will convert the digitally compressed messages back to analog format for station user playback. The voice quality of VMS playback largely depends on compression algorithms that may degrade the original message to optimize storage capabilities by using a low sampling rate or bit scheme. Filters and automatic gain control improve sound quality, but if stored messages are forwarded to another station or broadcast to hundreds of stations, further digital compression occurs as messages pass through interim mailboxes. Moreover, when VMS is used behind IP telephony, playback quality weakens if stored message transmission is packetized using IP codecs. This is a technical issue being addressed by designers and developers of the new IP-PBX systems.

Because the market trend is toward Local Area Network (LAN)–connected application servers, the traditional method for setting up signaling between the switch and the external VMS is slowly changing. The new, improved method is to insert an Ethernet TCP/IP link between the switching system and the LAN-connected VMS. At the same time, the newer VMS server design is also driving the market for Unified Messaging systems (UMSs). Many people think that first-generation UMS failed to take hold because they were based largely on traditional VM systems design and user operation. In contrast, second-generation systems are based largely on e-mail server design and user operation and are gaining greater market acceptance. Several new client/server PBX system designs include the VMS or UMS function as an integrated feature capability.

Interactive Voice Response System
An IVR system is a communications system product that typically functions as an intermediary between a PBX system and external computer databases. An IVR can also function as a stand-alone enterprise communications system, without a PBX system, because it can support standard PSTN trunk interfaces. Analog and digital trunk interfaces are supported by most IVR systems to connect to the customer premises PBX system or directly to the PSTN. IVR systems are used for several customer applications, including automated voice response and feedback, automated directory, call routing.

The primary system link for an IVR system is not the switching system, but an external computer system. The IVR mediates between voice callers and computer databases with customer-written scripts and menus prompting callers to respond to prompts with dialpad entries on their phones. The IVR system interprets the DTMF signals from the dialpad and is programmed to respond with another voice prompt, a recorded announcement, or a “spoken” answer to the caller’s inquiry. IVR speech is based on a text-to-speech programming algorithm, for which appropriate “answers” can be stored in the IVR database (which usually has limited memory storage capacity) or (more commonly) an external computer database.

Some IVR systems with ASR capabilities don’t require DTMF input to respond to caller voice commands and questions. Voice-based interaction with the IVR can significantly speed up the IVR transaction process by bypassing many call prompt levels of the programming tree. There are also many instances when callers find it easier and faster to speak digits or words instead of using the dialpad to enter digits in response to a call prompt command. ASR systems have been famously slow to penetrate the market because of reliability and cost barriers, but recent advances in programming and the declining cost of digital signal processors have made ASR more prevalent. We anticipate that the next major technology advance for automated response systems is speaker verification, an important capability to simplify the system interaction process and raise security levels.

Convergence of KTS/Hybrid and PBX Systems
KTS and PBX architectures began their gradual convergence of design and function with the introduction of the first KTS/Hybrid systems. The early 1980s saw major differences in call processing, switching, and port cabinet-design pure KTSs and PBXs. KTSs used analog switching and transmission standards and were based on a common control system design, with limited traffic, processing, and port capacities. Features were necessarily limited, and options such as multiple system networking and ACD were unheard of. Migration between KTS models—even on the same manufacturer’s product platform—usually required KSU fork-lifts. However, most PBX systems of the day employed digital switching and transmission standards, with digital desktop telephone and trunk interface support. PBXs were designed to handle greater traffic, processing, and port expansion requirements and offered numerous advanced features not available on any KTS.

Hybrid systems began to blur these category differences as PBX design technology and feature capabilities were applied to a KTS-like platform, nudging Hybrid switching network design away from the traditional dedicated line access and intercom path. The result more closely resembled the digital Time Division Multiplexing (TDM) bus design used by PBX systems. Hybrid systems could support customer port capacities far in excess of KTSs, some basic networking options, and call center applications.

By the mid-1990s many customers couldn’t tell the difference between a Hybrid system and a full-function PBX system because the design platform and feature sets were so similar as to be indistinguishable for all but the most unique customer requirements. High-end Hybrid systems could support customer port requirements up to several user stations. They accommodated networking options such as digital T1-carrier trunk interfaces and ISDN PRI services, ACD options including MIS reporting packages similar to the early PBX/ACD systems, and some integrated voice messaging and wireless communications options. Hybrid system digital telephones were more advanced, often offering customers a greater selection of multiple-line key and display models. It was not unusual for Hybrid telephones to offer the large display fields and soft-key feature buttons that are only now becoming a PBX standard.

Today’s Hybrids are often larger in capacity than many entry-level PBX systems and can support most, if not all, of the same features and functions for the majority of customer requirements. They can be intelligently networked, and they can satisfy complex call center requirements. Some manufacturers offer the same telephone models for both their Hybrid and PBX models, allowing customers a migration path between the two platforms, and most manufacturers have announced that their recently shipped IP telephones will work behind either systems.

As Hybrid systems expanded, PBX systems grew smaller. Until recently PBX systems were not priced to be competitive against Hybrid systems at the same station sizes. (The target market for competitively priced PBX systems usually began at 40 stations.) This PBX price problem was created by the higher cost of its more robust common control cabinet or carrier. During the past few years the PBX manufacturers have responded by redesigning their common control systems and downsizing the control cabinet/carrier hardware equipment. Although today’s PBX systems remain higher priced than a KTS/Hybrid configured for the same number of stations and trunks, the price differential has been continually shrinking. There is currently a 10 to 15 percent price difference between the two system platforms compared with 25 to 50 percent a decade ago. Today there are entry PBX models designed around a single printed circuit board for call processing, memory, and switch network functions. These new models are price competitive but port limited, usually designed for customers with 20 to 40 station size requirements at initial installation, but equipped with the call processing capability to support all of the features and functions of PBX models many times their port capacity.

PBX systems based on client/server designs are targeted primarily at the small/medium enterprise (SME) market, defined as ranging from about 20 stations to about 120 station, and overlaps with the Hybrid system market. A typical Hybrid system installation is about 25 stations. Shipments of PBX systems based on client/server designs are currently averaging about the same station size as Hybrid systems, and few have been installed at customer locations with port requirements above 100 stations. As you might expect, most of the systems being replaced by the client/server PBX systems are Hybrid systems, against which the newer PBXs can offer more bundled applications and support (either current or planned) for IP endpoints. The current generation of installed-base Hybrid systems may someday support IP endpoints but only after costly system upgrades. For the vast majority of users, it will be less expensive to install a new system than to upgrade the old. The first generation of IP telephony systems designed for the very small KTS/Hybrid customer is just beginning to make its way into the market.

Under the circumstances, we can predict that the traditional Hybrid system eventually will be replaced by the new communications system, client/server design, competitive product offerings, or upgrades to the system manufacturer’s new design platform. But this picture is also affected by customer size. Almost all market demand forecasts predict that the new PBX designs will be far more successful in smaller rather than larger line size markets, because the latter customer segment is less likely to replace a reliable and upgradeable installed system for a system that has not yet proved as reliable. The cost factors for large system replacement go far beyond the system purchase and installation price. Too much is at stake for large line size customers to risk the lesser reliability level of an OEM server running an operating system, such as Windows NT, not originally developed for real-time industrial applications. Only a few of the new client/server systems are built on more reliable and flexible operating systems, such VX Works, and custom-designed common control elements. Branch offices may sacrifice reliability for a less expensive system, but a large line size corporate or regional headquarters customer would not.

Enterprise Communications Systems Today | PBX Systems for IP Telephony

Today’s enterprise communications market is in a considerable flux caused by major ongoing changes in the technology of core products and the network infrastructure. Notably, voice communications systems are migrating from a time- to a packet-based switching and transmission design. The last major market and product shift occurred in the mid-1970s when the first computer stored program control (SPC) and digital switching communications systems were announced and shipped to replace older generation electromechanical systems. Although every generation believes that product 2upgrades and enhancements occurring in their prime are the most significant ever, telecommunications managers who remember the limited feature and function capabilities available on communications systems 30 years ago may be less impressed with the current market upheaval than industry newcomers who have learned to expect a new generation of products every 18 months from the data networking world.

Today’s typical enterprise voice communications network includes many, if not all, of the following ingredients:

1. A core communications switching system (Private Branch Exchange [PBX] system, Key Telephone System [KTS], or KTS/Hybrid system) that provides dial tone, call setup and teardown functions, and more call processing features than any one customer is likely to use

2. A management system to support fault and configuration operations

3. A call accounting system that analyzes and processes call detail records to generate billing and traffic reports

4. A voice messaging system that offers a wide array of services far beyond a basic answering system

Other widely used products that support basic voice applications in the enterprise include automated attendants, paging systems, and voice announcers. It is naturally assumed, but sometimes overlooked, that each network system user has some type of desktop or mobile telephone to access the core communications switching system. Other stand-alone desktop equipment scattered around the enterprise is likely to include facsimile (fax) machines and modems for dial-up data network access.

Customers with call center system requirements will install, at a minimum:

1. An Automatic Call Distributor (ACD)

2. A Management Information System (MIS)

As the call center requirements become more sophisticated, subsystems and options will be added to the basic ACD. These might include an Interactive Voice Response (IVR) system, an Automatic Speech Recognition (ASR) system, or a Computer Telephony Integration (CTI) application server. Users now routinely expect that all of these call center system elements will gradually merge with the Web server and e-mail server to form a mixed media e-contact center.

Twenty years ago almost none of these products existed beyond the core communications switching system. Small-line-size customers during the early 1980s with basic voice communications requirements would have a KTS or perhaps one of the recently introduced KTS/Hybrid systems. Intermediate and large-line-size customers with more advanced requirements preferred a PBX system, although what counted as advanced capabilities at the time would include features and functions considered basic today, such as Direct Inward Dialing (DID), Call Detail Recording (CDR), and Automatic Route Selection (ARS). These features were once available on only large, sophisticated, and relatively expensive PBX systems, but they can now be found on KTS products targeted at very small customer locations. The trickle-down theory of KTS/PBX feature and function options says that optionally priced advanced features and functions designed primarily for customers of large PBX systems eventually become standard offerings on entry-level KTSs.

The number of available features on PBX systems has increased exponentially since the first SPC models were introduced in the 1970s. A leading-edge PBX system marketed in 1980 had a software package with about 100 features for station, attendant, and system operations. By 1990 the number of features had more than doubled. Today a typical PBX system boasts more than 500 features, including optional hospitality, networking, and ACD options, and today’s typical KTS/Hybrid system offers more performance options than any PBX system in 1980. Despite the significant increase in features designed for desktop access and implementation, the majority of PBX station users (i.e., people with phones on their desks) use fewer than ten features on an everyday basis. Ironically, today’s typical station user may use fewer features than he would have used 20 years ago because many once-popular features, such as call pick-up and automatic callback, are rarely implemented. One reason for the decline in use of once common desktop features is the prevalence of voice messaging systems that preclude the use of many manually operated features for call coverage situations.

As a result, today’s PBX developers continue to write new feature software programs for the non-typical station user. Studies show that most station users implement about six features on an everyday basis, and features in general use are limited to hold, transfer, conference, and a few others. However, system designers cannot assume that the set of features in general use will be the same for every station user. Many features are used by a small number of system subscribers, but they are no less important than those used by the majority. For example, a feature such as Flexible Night Service may be used only by the system’s sole attendant console operator, and the Recent Change History feature may be of value only to the system administrator, but these features are as vital to the few individuals who implement them as Call Forwarding is to a typical desktop telephone station user. Many of the hundreds of PBX features introduced during the past 20 years were developed at the explicit request of customers. When a customer or a small group of customers demanded a new feature, a PBX manufacturer first determined that anticipated demand justified its development. Once offered by a major manufacturer, the new feature soon became available on systems from most competitors.

It’s important to note that some perfectly viable features are unique to special categories of customers or station users and may be used by as few as one system subscriber per enterprise. A feature’s value is not determined solely by how many individual station users implement the feature, but also by potential cost savings and productivity improvement at a station, system, or network level.

Of course, most customers do not have stringent demands on PBX system design architecture attributes; they’re looking for basic growth and redundancy requirements. A station user who doesn’t have telecommunications system acquisition or management responsibilities cares nothing about the technical underpinnings of the telephone system he’s using. He picks up the telephone handset, listens for dial tone, punches a number or activates a feature, and is satisfied by the experience almost every time. As long as that’s true, the station user won’t be asking whether the system has analog or digital transmission, circuit-switched or packet-switched connections, a proprietary software operating system, or a standard off-the-shelf Windows solution. People who should care about PBX system technology and reliability standards, applications support, and future product direction are the telecommunications manager, voice/data networks director, or CIO.