Active Security Monitoring

At this point, we have examined and hardened the working components of the existing security infrastructure, established procedures to confirm user and device identities, and logically separated voice and data traffic, thus allowing the network to now carry them. The next step in maintaining the security of this infrastructure is to monitor traffic and the state of key devices. This is accomplished by active monitoring.

Plenty of commercial and open-source tools exist to help with this, and in this chapter we will look at several categories of them. We won’t, however, discuss in any detail the large commercial network monitoring suites like NetIQ, SMARTS, BMC Patrol, HP OpenView Operations, HP Network Node Manager NNM, IBM Tivoli, Nortel Optivity NMS, Cisco Ciscoworks, Sun Solstice SunNet Enterprise Manager, Micromuse, Computer Associates CA Unicenter, and Microsoft Operations Manager 2000 (MOM). While we recommend that organizations employ one or more of these enterprise tool suites (particularly to monitor network jitter, packet loss, and latency), the configuration, use, or integration of any one of these tool suites with VoIP network monitoring components is complex, dependent upon both the suite chosen for monitoring, and the peculiarities of each particular network. For these reason we will have to leave this discussion to another time.

A related class of tools for both monitoring and performance testing of VoIP networks include tools like Empirix Hammer, Brix Network Verifier, and Shunra’s Virtual Enterprise. These tools use different techniques and metrics to monitor the functionality, performance, scalability, and robustness of VoIP networks to provide signaling and media quality data on every call. Administrators can monitor high-level network metrics via integration with their existing Network Management Systems or can drill into the details of any call down to individual protocol and network messages.

We will start off by discussing in more detail two intrusion detection (ID) technologies: NIDS (network-based) and HIDS (host-based). NIDS inspects all inbound and outbound network activity and identifies patterns of packet data that may indicate a network or system attack. NIDSs are normally arranged in a multiple-sensor-to-one-console configuration, where the sensors reside on dedicated appliances distributed at key network junctions, and report back to a central management console. HIDSs, on the other hand, normally reside on the server that they monitor. HIDS can also report back to a central management console. A third class of intrusion detection is exemplified by DShield or Symantec—distributed intrusion detection—where global system attacks are reported to, and consolidated by, a central manage-ment server. Intrusion detection is a requirement in contemporary networks since it is not possible to stay abreast of existing and potential threats to modern computing systems.

Next, we will take a look at logging, primarily focusing on syslog and SNMP. Syslog (system logger) provides a means to allow a machine to send event notification messages across IP networks to event message collectors (also known as syslog servers). The decision regarding how much and what types of data should be logged is a critical responsibility of the system administrator. However, in most modern systems the sheer amount of logging data generated by system loggers can easily overwhelm most system administrators. We have witnessed organizations that react to log events, not based upon the data contained in the logs, but rather according to the number of logs generated per some unit of time. In order to deal with this mass of data, many system administrators develop scripts or tools to examine the log files and extract the important information. These tools are important because, without them, log data is often ignored. SNMP (Simple Network Management Protocol) is the primary transport for most of the aforementioned large tool suites. There are, however, simple point solution SNMP tools available, and we’ll offer suggestions regarding general SNMP usage.

Finally, in this chapter, we will close with a section on penetration testing. Penetration testing is a means of monitoring the state of security controls on your VoIP network. The primary reason for testing systems or networks is to identify potential vulnerabilities and subsequently repair them. Penetration Testing (Pen Testing) is an intelligent combination of automated and manual examinations that are launched from either inside or outside the perimeter of a private network. This testing emulates the threat from hackers and other parties, and their attempts to enumerate and compromise visible services.

Although we are not aware of production ready VoIP-specific NIDS, several are rumored to be in development. As a note: Based upon data gathered from historical analysis of call flows, anomaly detection, particularly in a call center setting where traffic is more defined than in an entire converged network, may prove to be an effective NIDS strategy.

Distinct IP Telephony Features/Functions

Integrated port interfaces. Compared with a legacy digital telephone, an IP telephone can be designed and equipped to provide several unique feature/function capabilities. An IP telephone design attribute not available with traditional digital telephones is the integration of a multiport Ethernet hub/switch to allow multidevice sharing of a single connector port to the Ethernet switched network. Most current IP telephone models are equipped with two Ethernet port connectors: one connector for the Ethernet network and one for a desktop PC client. Mitel Networks has indicated that its next-generation models will have another external connector port to support two Ethernet devices external to the telephone. An integrated Ethernet port interface reduces telecommunications outlets, inside wiring, and Ethernet switch port requirements. Cisco Systems was the first supplier to incorporate an integrated Ethernet switch into its IP telephones in its 7900 series. Mitel Networks followed Cisco’s approach by including integrated Ethernet switch ports in its second generation of IP telephones. Avaya, still marketing its first generation of IP telephones, offers its IP telephones with an integrated Ethernet hub.

The difference between an IP telephone with an integrated switch or hub may not be important to most customers, but providing a high level of voice-grade communications to the desktop is of primary importance. Voice communications QoS at the desktop can be supported using a variety of methods, such as Ethernet LAN 802.1 p/Q, or CoS programming (by switch or hub port). For example, each Cisco 7900 IP telephone internal Ethernet port can be programmed for different classes of service; the default service level of the voice port is a 5 and the data port is a 0. The system administrator can override the default service levels, if required, by an individual desktop station user. IP telephones with an internal Ethernet hub must include customized software to prioritize voice communications.

Besides Ethernet port connectors, current IP telephones may also support peripheral data devices through a USB port or infrared interface to a PDA. A USB port theoretically can be used for a variety of devices, such as printers, scanners, or digital cameras. There are several reasons to link a PDA through an infrared interface, including dialing from the directory or programming. Mitel Networks has introduced an IP telephone model with a docking station interface for a PDA. The PDA likely would function as the instrument’s display field, and provide data download capabilities for call processing and handling applications.

Ethernet power distribution. IP telephones, like PC clients, require power. Traditional PBXs power analog and digital telephones use internal power supplies to distribute power over inside telephony wiring. Converged (IP-enabled circuit switched) IP-PBX cannot distribute power across integrated IP gateway circuit cards to the LAN; neither can the LAN-connected telephony servers used in client/server IP-PBX designs. The first generation IP telephones were powered with an AC/DC transformer connected to a local AC power outlet. Each IP telephone required its own transformer and a dedicated UPS for emergency power support. Although an IEEE subcommittee had been working on its recommended standard for in-line power over an Ethernet LAN, IEEE 802.3af, Cisco could not wait and developed its own proprietary solution. Other proprietary solutions soon followed from other IP-PBX system suppliers, including 3Com and Alcatel. Third-party solutions, from suppliers such as PowerDsine, are available and work with IP telephones from other leading IP-PBX suppliers, such as Avaya and Siemens. In-line power options are currently priced at $50 to $100 per Ethernet port, but prices are expected to decline over time.

An Ethernet switch is equipped with an integrated or external power patch module, and power is distributed directly only to IP telephones, supported by the switch. Power is transmitted over unused Ethernet cabling wire pairs to only those Ethernet ports identifying themselves to the switch as IP telephone devices. IP telephones identify themselves to the LAN switch during an automatic self-discovery installation method or through manual programming by the system administrator. The Ethernet switch queries the IP telephone as to how much power is required or assumes a default power level.

Some of the basic specifications of IEEE 802.3af are:

• DTE power shall use two-pair powering, where each wire in the pair is at the same nominal potential and the power supply potential is between the two pairs selected.

• The power detection and power feed shall operate on the same set of pairs.

• The DTE power maximum voltage shall not exceed the limits of SELV per IEC 950.

• For DC systems, the minimum output voltage of the source equipment power supply shall be at least 40 V DC.

• For DC systems, the source device shall be capable of supplying a minimum current of at least 300 mA per port.

• The solution for DTE powering shall support mid-span insertion of the power source.

• 802.3af systems shall distribute DC power.

Until the IEEE 802.3af standard is finalized, IP telephones will continue to be powered by available in-line power options or local AC power transformers. need for stand-alone telephony gateway equipment linking a traditional PBX system and an IP router. Calls placed from an IP telephone can be routed directly across a LAN and WAN without IP telephony servers.

Compressed voice. Traditional digital telephones are designed with codecs that digitize analog voice signals into digital format using 8-bit word encoding and 8-KHz sampling, resulting in 64-Kbps digital transmission over inside wiring and across the internal PBX switching network. IP telephones can compress voice signals for lower transmission rates and decreased bandwidth requirements. The most common digital encoding schemes currently used for voice transmission over Ethernet and IP WAN networks are G.711 (64 Kbps), G.723.1 (5.3 to 6.3 Kbps), and G.729/A (8 Kbps). G.711 is traditional PCM (no compression), but the two other codec specifications use compression algorithms. The total bandwidth used for voice transmission with IP transmission protocol is greater than the noted transmission rates; about 16 Kbps of additional transmission bandwidth is required because an IP destination address and overhead signaling bits are added to the voice datagram packets. Compressed voice transmission creates an overhead delay factor that may affect the quality of a conversation, but the trade-off is the potential for more efficient use of expensive off-premises network transmission resources. A T1 carrier circuit that typically supports a maximum of 24 voice-grade channels can support an equal or greater number of voice channels, with sufficient available bandwidth for concurrent data communications transmission, if voice is encoded using G.729/A compression. Using an IP telephone for voice compression eliminates the need for stand-alone telephony gateway equipment linking a traditional PBX system and an IP router. Calls placed from an IP telephone can be routed directly across a LAN and WAN without IP telephony servers.

Other IP telephone functions that reduce transmission bandwidth requirements are VAD and silence suppression. VAD detects voice communications signals entering the handset mouthpiece (microphone), and silence suppression signals the onset of “silent” voice transmission. A telephone call usually has a high percentage of silence during a conversation between parties, often as much as 50 percent of total talk time. A circuit switched connection is highly inefficient because much of the time there is no voice activity, but 8-bit words of “silence” are transmitted. With VAD and silence suppression, an IP telephone can reduce bandwidth transmission requirements because packets are not continually transmitted when no one is talking. When there are no voice communications signals picked up by the IP telephone microphone, a special signaling packet is transmitted to the destination IP address indicating the beginning of a silent period, when no new voice packets are being transmitted between the two endpoints. When voice activity resumes, another signaling packet is forwarded to inform the destination IP address that incoming voice packets are now on their way, effectively ending the period of silence. VAD and silence suppression packets are transmitted only when someone is actually talking, resulting in fewer packets and more efficient use of network resources.

Web browser. The most significant feature difference between a legacy digital telephone and an IP telephone is the integration of an embedded Web browser and pixel-based display monitor. The first question most people ask about Web-enabled IP telephones is: “Why do I need a telephone with Internet access if I have a PC?” The manufacturers of Web-enabled IP telephones are quick to point out that their product should not be considered a replacement for a fully functional PC client, but as a supplemental communications device for access to information when data processing is not required. These new IP telephones are best described as network communications portals that combine telephony functions with access to network information servers.

Thin client IP telephones have many of the internal design attributes of a computer: CPU, memory, operating system, applications software, and embedded communications protocol stacks. The RTOS of the thin client IP telephone may be proprietary, as in the Cisco Systems 7940/7960 models or the popular VX Works RTOS used by the Siemens optiPoint 600. Avaya’s 4630 IP telephone was the first Web browser model with a color display and touch screen control. The use of color can greatly enhance the functionality and ergonomics of the desktop instrument, particularly when displaying graphic information or photographs. Touch screen control, instead of cursor control buttons, provides point-and-click mouselike activation of features and menu selection. A telephone with touch screen control is not new; industry veterans may recall the Northern Telecom M3000 digital telephone introduced in 1985.

General desktop applications using an integrated Web browser include:

• Access to directories external to the IP-PBX system directory database

• Messaging (voice, text, fax)

• Web page information screens

• Personal calendar

• Conference planning

• Transportation schedules and reservations

• Financial data (real-time stock quotes, investor information)

The accompany diagram of the Avaya 4630 IP telephone with a color touchscreen display illustrates the various applications supported by an IP telephone with an integrated Web browser interface.

Figure 1: Screenphone applications.

Figure 2: IP screenphone applications.

Figure 3: IP screenphone applications.

Figure 4: IP screenphone applications.

Using a telephone for e-mail or calendar access may seem strange if a personal computer is only inches away on the desktop, but it can be quicker and easier with the telephone. Telephones are always “on,” and information access is immediately available at a touch of a button. Booting up a desktop computer is getting longer and longer, as each release of Windows becomes more and more complex and the number of programs loading grows even larger. Many companies have several antivirus programs that run a series of system and memory checks before the computer is ready for use. The reliability level of a telephone has proved to be at least an order of magnitude greater than desktop computers, and it is less likely that the telephone will freeze due to program interactions or some other operating system glitch.

The Web browser feature can be especially useful in vertical markets where voice station users do not normally have a desktop computer. The healthcare, retail, and hospitality sectors are characterized by a significant number of stations users who have voice-only instruments at their disposal. For example, many nursing stations still have dumb CRT terminals for information access. In the retail sector, most point-of-sale (POS) terminals have no Web server access. In hotels, guest rooms have telephones, and Ethernet ports, but no computers. There is also a sizable number of installed telephones across all industry sectors with no nearby PC client. Many telephones are not located on a desktop shared by a computer: lobby telephones; cubicle telephones; conference room telephones; and wall-mounted telephones in hallways, cafeterias, or locker rooms. An IP telephone with a Web browser can be used as an information kiosk in public locations, such as shopping malls, bus terminals, or airports.

Mobile. There are three subcategories of mobile telephones for use behind a PBX system: cordless, premises wireless, and cellular. PBX cordless telephones can be proprietary or standard 2500-type analog. Proprietary cordless telephones are supported by proprietary PBX port circuit cards and have a unique signaling and control channel that allows for multiple line appearances and full PBX feature access and performance (including display-based information). Usually using spread spectrum technology and operating in the 900-MHz frequency range, a proprietary cordless telephone can often be used as a substitute for desktop models. A growing number of circuit switched PBX systems supports this option, including Avaya, Nortel, Siemens, NEC, and Toshiba. Analog cordless telephones, the same type commonly used for residential applications, appear to the PBX system as 2500-type telephones and offer limited feature/function access but a degree of station user mobility not offered by fully wired desktop models.

Premises wireless handsets are included as part of a premises wireless telephony option working behind the PBX system. The wireless handsets for these systems are proprietary to each system’s controller cards and base station transceivers. Base station coverage is limited in terms of geography and traffic handling. Most base stations support radio transmission ranges of about 50 to 150 meters, and between 2 and 12 simultaneous conversations per coverage cell. The wireless handsets closely resemble consumer cellular telephones, with several notable differences. Several manufacturers market wireless handsets with multiple line appearance buttons, fixed and programmable feature/function keys, and multiline displays that provide station users with information and data comparable to those of desktop digital telephone models. The high cost of a premises wireless handset and the infrastructure required to support coverage and traffic has limited the appeal of wireless telephony options, despite the ability of the station user to stay in touch with the PBX system regardless of location within the customer premises.

The first generation of premises wireless handsets was based on traditional circuit switching TDM/PCM standards. The recent introduction of wireless IP telephony solutions allows customers to use the existing LAN infrastructure to support distributed base stations. IP-PBX systems can interface directly to the wireless LAN infrastructure, but an MG is required for work behind a circuit switched PBX system. A leader in wireless IP is Symbol Technologies, whose Spectrum 24 wireless LAN system supports a wireless IP handset for use behind a PBX system. The Spectrum 24 uses spread spectrum frequency hopping within the 2.4- to 2.5-KHz band for transmission between access point transceivers and handheld communications devices. Data rates up to 2 Mbps per channel are supported. Each access point serves as an Ethernet bridge and can support wireless transmission coverage up to 2,000 feet in open environments and up to 180 to 250 feet in a typical office or retail store environment. Symbol’s NetVision Phone system provides enterprise voice communications capability and allows for integration into an existing PBX system (via a gateway) for premises and off-premises communications. The system includes NetVision Phones, access points, and a telecom gateway (third party). Each access point typically can support between 12 and 16 active clients and up to 10 voice-only conversations. There is a voice prioritization algorithm at the access point and client levels to minimize voice transmission delays. Fast roaming and load balancing support hand-offs between access points. Access point pinging detects and tracks station devices. The NetVision Phone is based on the ITU H.323 standard and converts analog voice signals into compressed digital packets (G.729/A 8-bit sampling rate, 160 bytes per packet) that are sent via the TCP/IP protocol over standard data LAN networks with the CSMA/CA wireless access protocol. TCP/IP addressing is used to tie to an extension number or a name directory. Several dialing mechanisms are supported:

• Direct entry of complete or partial IP addresses

• Direct entry of an “extension” number

• Speed dial operation via speed dial keys

• Recall/redial of a previous number

• Using a name directory internally mapped to an IP address

• Pressing the Send button begins the keypad dialing process

NetVision is a single line telephone, with a second “virtual line appearance” to support two concurrent conversations (one line is active and the other is in the hold mode). Intercom calls are supported between the phones over the LAN infrastructure, including broadcast capability to any number of phones. A multiline display field provides for incoming CLID services, and fixed function keys are used for one-button feature access. Symbol also offers a NetVision Dataphone for use with Spectrum 24. This telephone handset has an integrated Web client for accessing applications and databases and bar code scanning capability. Proprietary versions of NetVision telephones are used by Nortel Networks and Mitel Networks behind their IP-PBX systems. The NetVision IP wireless telephony system interfaces to the IP-PBXs via port interface gateway line cards. The accompany diagram illustrates the integration of the wireless NetVision handsets into an Ericsson MD-110 PBX configuration (Figure 5). The NetVision terminals are typical of IP wireless handsets that are designed for enterprise mobile applications.

Figure 5: Virtual IP telephony extensions.

Premises cellular is the third mobility communications option. The same cellular handset used with network cellular services, such as Sprint PCS, AT&T Wireless, and Cingular, can also interwork with a PBX system for premises mobile communications requirements. The first premises cellular options required an on-site mobility server and cell transceiver that linked to a local carrier’s network. The mobility server provided an interface between the PBX system and the premises cellular infrastructure to support control signaling and feature support to cellular handsets while the station user was on the customer premises. This mobile communications option had several drawbacks, including cost (mobility servers and transceivers are expensive for limited numbers of subscribers) and network compatibility. The premises transceiver could link to only one cellular carrier service, such as TDMA or GSM. All premises subscribers required a cellular handset that worked with the same network carrier service. Although some business customers supplied their employees with a cellular handset and had a low-cost contract with a single service provider, the more likely scenario was that PBX station users had a great variety of cellular handsets supported by different network service carriers. A better solution was needed than an expensive cellular infrastructure linked to a single service provider.

Ericsson, a leader in mobile communications networks, developed a more cost-effective and flexible premises cellular option. The MD-110 Mobility Extension option is based on an integrated interface circuit card housed in the PBX’s port carrier that can support a cellular handset with the use of any type of service standard from any local carrier. An ISDN PRI trunk circuit link is used to network the PBX system to the cellular network. Dialing procedures from the cellular handset will be in line with the terminal’s existing network service procedures, plus fully support the MD110-procedures, including station features (via voice prompts) and network call routing. The Ericsson Mobility Extension option is carrier service provider and transmission/encoding independent.

PC client softphone. The final category of PBX telephones is the PC client softphone. There are several categories of softphones. The first generation of softphones was based on CTI desktop applications using first-party (desktop telephone API link) or third-party (client/server configuration) call control. The CTI-based softphone requires a telephone instrument (analog or digital) for voice transmission to/from the desktop. An IP softphone is a PC client functioning as the voice terminal using an integrated microphone/speaker option to support LAN-based voice transmission, with signaling and control to and from a telephony server over the LAN/WAN infrastructure. For implementation of either softphone, a station user accesses and implements PBX features (dialing, call answering, call coverage, call processing) using a keyboard and/or mouse control for a GUI computer screen. Communications solutions using PC client software tools offer station users many advantages over traditional telephone instruments, with a limited number of feature/line keys and relatively small noncolor display fields. The accompanying diagram is an illustration of the Nortel Networks i2050 soft client phone (Figure 6). Some suppliers also offer customized client keyboards with integrated handsets for use as a softphone. The accompanying photograph is a Siemens optiKeyboard designed for use with its family of softphone client solutions (Figure 7)

Figure 6: IP softphone: Nortel Networks i2050.

Figure 7: Siemens optiKeyboard.

Market demand for CTI-based softphones has been very weak. Many station users prefer to depress traditional telephone buttons to access features rather than interact with a GUI-based computer screen to perform drag, point, and click operations. Telephone instruments also offer a far greater degree of reliability than PC hardware/software and are not affected to the same level as AC-powered desktop computers by local power problems. A major problem associated with first-party control CTI softphones was the requirement of a relatively expensive digital telephone equipped with an API link to the desktop computer. Third-party control client/server CTI configurations could be implemented with a lower-priced analog telephone, but station user functionality is severely affected when the desktop computer fails or is not performing properly. The primary market for desktop CTI has been among call center customers because the current ACD agent position depends heavily on desktop computer equipment and GUI-based interactions, and the cost of the solution is not significant compared with overall contact center expenses.

The emergence of IP-PBX systems may spur demand for PC client softphones because the cost of the solution may be far less than that of a high performance IP telephone. There likely will be great resistance to IP softphones from most station users who have grown comfortable with traditional telephone instruments, but the many potential benefits of the new solution may stimulate market demand.

IP Telephone Design Basics

All manufacturers base their IP telephone on proprietary design schematics and circuitry, but there are common design elements across the unique terminals. IP telephone basics include:

• User interface

• Voice interface

• Network interface

• Processor complex and associated logic

The accompanying diagram illustrates the internal design elements of an IP telephone instrument (Figure 1)

Figure 1: IP telephone design.

The user interface elements provide four classic telephone user function interfaces: keypad for dialing numbers; a variety of keys for line and feature access; a display for user prompts, caller feedback, messages, and other call processing information; serial interface to allow communications to an external device, such as a PDA, to allow synchronization of telephone information; speed dialing; and customer programming. An audible indicator (ringer) is also included to announce incoming calls.

The voice interface converts input analog voice signals into 8-bit digital word bit samples. Speech signals are sampled at an 8-KHz rate to create a 64-Kbps digital bit stream to the processor by using a standard PCM codec. Voice signal compression and IP encoding functions are performed by processor complex elements. The processor complex performs voice processing, call processing, protocol processing, and network management software functions. The complex consists of a DSP for voice-related functions and a MCU for the remaining control and management functions. The DSP and MCU each have associated memory. DSP memory usually includes RAM and ROM elements; MCU memory usually includes RAM and Flash elements. The Flash memory element supports software upgrades.

The network interface allows the transmission and reception of voice packets to and from the telephone terminal based on 10BaseT or 10/100BaseT Ethernet running TCP/IP protocols. Some IP telephones may be equipped with multiple RJ-45 Ethernet connector ports and an integrated Ethernet hub/switch to support connections to the customer premises LAN and desktop PC clients. Newer IP telephones also may be designed with a USB connector port.

Basic IP telephone software modules include a variety of user interface drivers (display, keypad, ringer, user procedures), voice processing modules, telephony signaling gateway modules, network management modules, and system service modules. The voice processing software modules include a PCM interface unit; a tone generator (call progress tones, in-band DTMF signaling digits); a line echo canceler unit (ITU G.168-compliant echo cancellation on sampled, full-duplex voice port signals); an acoustic echo canceler for terminals equipped with a speakerphone; VAD; voice codec unit (compression and packeting of the 64-Kbps digital stream received from the station user based on a variety of algorithms, such as G.711, G.723.1, G.729/A, etc.); packet playout unit (compensation for network delay, jitter, and packet loss); packet protocol encapsulation unit (based on RTP, which runs directly on top of the UDP); voice encryption (to ensure privacy); and a control unit (coordinates the exchange of monitor and control information between the voice processing module and the telephony signaling and network management modules).

The telephony signaling gateway subsystem in an IP telephone performs the basic functions for call setup and teardown procedures. Software modules used by this subsystem include call processing, address translation and parsing, and network signaling. The most widely implemented network signaling standard used by currently available IP-PBX systems is H.323 protocol. H.323 is an ITU standard that defines several signaling and protocol specifications for multimedia communications between LAN-based terminals and network equipment. The main H.323 standards used for VoIP in an IP telephone are H.225–Call Signaling Protocol (based on Q.931), H.245–Control Protocol; RAS Protocol; and RTCP. An emerging network signaling standard not currently used by any commercially available IP-PBX, but being planned for by most suppliers, is SIP. SIP is the protocol developed and promoted by the Internet Engineering Task Force (IETF) and is forecasted to be widely implemented in network hosted services, such as IP-Centrex, and may eventually replace H.323 as the primary signaling protocol used by premises communications systems.

TIA IP Telephony QoS Recommendations

The TIA has done extensive research and analysis to understand IP telephony voice quality. It used the ITU-T recommendation G.107 E-model to develop its own recommendations for optimizing IP telephony QoS levels, categorizing them by sources of potential speech impairment: delay, speech compression, packet loss, tandeming, and loss plan. The E-model consists of several models that relate specific speech impairment factors and their interactions with end-to-end performance.

The specific recommendations, as summarized in TIA/EIA/TSB116, are:

• Delay recommendation 1—Use G.711 end to end because it has the lowest Ie value (equipment impair value) and therefore allows more delay for a given voice quality level.

• Delay recommendation 2—Minimize the speech frame size and the number of frames per packet.

• Delay recommendation 3—Actively minimize jitter buffer delay.

• Delay recommendation 4—Actively minimize one-way delay.

• Delay recommendation 5—Accept the [TIA’s] E-model results, which permit longer delays for low Ie codecs, like G.711, for a given R value (transmission rating factor).

• Delay recommendation 6—Use priority scheduling for voice-class traffic, RTP header compression, and data packet fragmentation on slow links to minimize the contribution of this variable delay source.

• Delay recommendation 7—Avoid using slow serial links.

• Speech compression recommendation 1—Use G.711 unless the link speed demands compression.

• Speech compression recommendation 2—Speech compression codecs for wireless networks and packet networks must be rationalized to minimize transcoding issues.

• Packet loss recommendation 1—Keep (random) packet loss well below 1 percent.

• Packet loss recommendation 2—Use packet loss concealment (PLC) with G.711.

• Packet loss recommendation 3—If other codecs are used, then use codecs that have built-in or add-on PLCs.

• Packet loss recommendation 4—New PLCs should be optmized for less than 1 percent of (random) packet loss.

• Transcoding recommendation 1—Avoid transcoding where possible.

• Transcoding recommendation 2—For interoperability, IP gateways must support wireless codecs or IP must implement unified transcoder-free operations with wireless.

• Tandeming recommendation 1—Avoid asynchronous tandeming, if possible.

• Tandeming recommendation 2—Synchronous tandeming of G.726 is generally permissible. Impairment depends on delay, so long-delay digital circuit multiplication equipment (DCME) equipment should be avoided.

• Loss Plan recommendation 1—Use TIA/EIA/TSB122-A, the voice gateway loss and level plan.

Following the Cisco Systems and TIA recommendations and guidelines may prove to be a difficult task if aging network infrastructure is installed that cannot support most, if not all, of these QoS control mechanisms. It is obvious from the material covered in this chapter that a close working relationship between voice and data communications personnel is required to successfully implement and operate an IP-PBX systems. If IP telephony QoS is not comparable to the experience station users have grown accustomed to with their circuit switched PBX system, the new technology may be rejected as an enterprise communications solution, even if it offers potential cost savings and the benefit of new applications support. A green field location offers the best bet for a large IP-PBX system installation because it is easier to begin from scratch than to attempt a network upgrade while continuing to support ongoing communications operations.

The DiffServ model divides traffic into a small numbers of classes. One way to deploy DiffServ is simply to divide traffic into two classes. Such an approach makes good sense. If you consider the difficulty that network operators experience just trying to keep a best-effort network running smoothly, it is logical to add QoS capabilities to the network in small increments.

Suppose that a network operator has decided to enhance a network by adding just one new service class, designated as “premium.” Clearly, the operator needs some way to distinguish premium (high-priority) packets from best-effort (lower-priority) packets. Setting a bit in the packet header as a one could indicate that the packet is a premium packet; if its a zero, the packet receives best-effort treatment. With this in mind, two questions arise:

• Where is this bit set and under what circumstances?

• What does a router do differently when it sees a packet with the bit set?

A common approach is to set the bit at an administrative boundary, such as at the edge of an Internet service provider’s (ISP’s) network for some specified subset of customer traffic. Another logical place would be in a VoIP gateway, which could set the bit only on VoIP packets.

What do the routers that encounter marked packets do with them? Here again there are many answers. The DiffServ working group of the IETF has standardized a set of router behaviors to be applied to marked packets, which are the PHBs. PHBs define the behavior of individual routers rather than of end-to-end services. Because there is more than one new behavior, there is a need for more than one bit in the packet header to tell the routers which behavior to apply. The IETF has decided to take the ToS byte from the IP header, which has not been widely used in a standard way, and redefine it. Six bits of this byte have been allocated for DSCPs. Each DSCP is a 6-bit value that identifies a particular PHB to be applied to a packet. Current releases of Cisco IOS software use only 3 bits of the ToS byte for DiffServ support. This is adequate for most applications, allowing up to eight classes of traffic. Full 6-bit DSCP support is under development.

One of the simplest PHBs, and one that is a good match for VoIP, is EF. Packets marked for EF treatment should be forwarded with minimal delay and loss at each hop. The only way that a router can guarantee this to all EF packets is if the arrival rate of EF packets at the router is limited strictly to less than the rate at which the router can forward EF packets. For example, a router with a 256-kbps interface needs to have an arrival rate of EF packets destined for an interface that is less than 256 kbps. In fact, the rate must be significantly below 256 kbps to deal with bursts of arriving traffic and to ensure that the router has some ability to send other packets.

The rate limiting of EF packets may be achieved by configuring the devices that set the EF mark (e.g., VoIP gateways) to limit the maximum arrival rate of EF packets into the network. A simple, albeit conservative, approach would be to ensure that the sum of the rates of all EF packets entering the network is less than the bandwidth of the slowest link in the domain. This would ensure that, even in the worst case, where all EF packets converge on the slowest link, the link is not overloaded and the correct behavior results.

In fact, the need to limit the arrival rate of EF packets at a bottleneck link, especially when the topology of the network is complex, turns out to be one of the greatest challenges of using only DiffServ to meet the needs of VoIP. For this reason, an approach based on integrated service and the RSVP is appropriate in those situations where it is not possible to guarantee that the offered load of voice traffic will always be significantly less than link capacity for all bottleneck links.

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.

Centrex or PBX : IP Telephony

For several years the term Voice over Internet Protocol (VoIP) has been used to identify the transmission of voice signals over any IP-based network. In the business context, VoIP now refers to the transmission of voice and/or video communications over a managed WAN or LAN.

Some consultants and one or two telecom manufacturers have used the term telephony over Internet protocol (ToIP) to describe the switching of real-time, conversational traffic in systems that are attached to IP data networks.

The words "IP telephony" have emerged as the umbrella term that covers both VoIP and ToIP, which can be delivered either by an IP-PBX (housed on the customer's premises) or by IP-Centrex (for which the call processor is owned and accommodated by the carrier).

Some organizations have been using VoIP to reduce the cost of longdistance service, particularly international service, for several years. In countries that have highly competitive interexchange carriers it is generally no longer worthwhile to use VoIP, after allowing for the cost of gateway hardware and software. Several international carriers, such as the T-Systems division of Deutsche Telekom, have specifically promoted the use of IP networks for international traffic.

IP telephony has been validated since the year 2000 by the availability of some IP-PBXs. An IP-PBX system or IP-Centrex service may deliver only VoIP (through appropriate trunk and line interfaces), only ToIP (by retaining interfaces for the existing analog and digital devices), or both in the form of IP telephony. Now that IP has become, by far, the most popular protocol for data transmission and is widely deployed in networks of all sizes, from one room to worldwide, organizations have access to the appropriate transport technology to gain the advantages of convergence. Full convergence between multimedia and data applications requires the availability of both VoIP and ToIP, which are both inherent to the concept of IP-Centrex.

Interface Standards
The key to success with IP-Centrex will be a high level of interoperability between devices and systems or applications. This will be a major move away from the proprietary interfaces that have kept acquisition costs up and made application implementations complex with PBX systems. The acceptance of a limited number of open standards will also facilitate more competition between a broader range of manufacturers and service providers.

The earliest call control standard for mapping users' names or telephone numbers into and IP source or destination addresses was H.323, which was adopted by the International Telecommunications Union (ITU). H.323, was originally intended to define how multimedia communications were to be transmitted over a data network between teleconference units and, as used for VoIP, defines only a restricted feature set, with different enhancements being made by various manufacturers. H.323 does not define transmitted voice quality, is considered to be too processing intensive, and depends on the use of intelligent workstations.

A working group of the IETF created the session initiation protocol (SIP) to lessen call setup times and take better advantage of the Internet infrastructure than H.323. SIP is most likely to become the interface standard of choice between telephone sets and computers with ToIP systems.

A third standard, officially known as H.248 but more generally as MGCP or Megaco, is being jointly developed by the IETF and ITU, with support from some, but not all, major manufacturers. The H.248/ MGCP protocol addresses the needs of multimedia conferencing and is intended for use with media gateway controllers (MGC).

Every communicating device on an Internet protocol-conforming network must have an IP address, so that a desktop with a telephone, a PC, and a softphone (within the PC) or a video terminal needs to be allocated three addresses. There must be a process with the network for mapping telephone numbers to corresponding IP addresses.

Also, any endpoint's address must be known in order to be accessible; in some circumstances, this requirement becomes a security concern. This situation can be problematic in that multiprotocol label switching (MLPS), which is widely used in managed wide area networks (WANs), does not allow for any "spoofing" (i.e., the alteration and retransmission of any part of a signal in order to hide the address contents and therefore discourage hacking).