| ||
The Communication Manager and its associated media gateways are considered the equivalent of a traditional PBX. In small deployments, voicemail and messaging applications may be deployed co-resident in the Communication Manager enclosure. In larger deployments, they would be hosted in adjunct servers and not necessarily considered part of the PBX proper. In addition to core telephony components, Avaya and third-party partners offer many adjunct systems to interact with and provide value-added services to the core VoIP components (for example, management systems).
The following sections provide a very brief introduction to an Avaya Communication Manager system. This information was extracted and compiled from several documents provided by Avaya, including Avaya Application Solutions: IP Telephony Deployment Guide and the Hardware Guide for Avaya Communication Manager.
Core call processing functions are implemented by the Communication Manager, which provides user and system management functionality, intelligent call routing, application integration and extensibility, and enterprise communications networking. The Communication Manager runs on a media server and on the existing family of traditional DEFINITY servers. The media server can be a module in a media gateway, or it can be a separate appliance. The media server provides centralized, enterprise-class call processing.
This call processing can be distributed across a multiprotocol network (including IP) to support a network architecture consisting of headquarters, branch, remote, small, and home offices. The Communication Manager has embedded capabilities for
Call center/Compact call center
Computer Telephony Integration (CTI)
Messaging
Conferencing systems
Unified Communication Center
Avaya media servers are designated S8 nnn (for example, S8300) and control media gateways and communications devices (the IP phones). In the H.323 paradigm, the media servers are the gatekeepers. Avaya also supports SIP, but this configuration was not reviewed for the book.
Communication Manager runs on top of a customized version of Linux (Red Hat Enterprise Linux 4); it can also execute on the legacy DEFINITY servers that run over the proprietary Oryx/Pecos operating system. The legacy servers are installed into Avaya CMC1, SCC1, and MCC1 media gateways. The DEFINITY servers are being phased out of the Avaya product line in favor of media servers, however, so we did not review these legacy servers for the book.
The Avaya S8300, S8400, S8500, and S87 xx -series are Linux-based media servers that support
Distributed IP networking and centralized call processing across multiservice networks
Dual server design with hot fail-over
Redundant LAN interfaces and remote survivable call processing
The S8300 and S8400 are cards housed in one of several media gateways. The S8500 and S87 xx are standalone server enclosures. Multiple S87 xx servers can be deployed for large loads and survivability . Figure 8-1 diagrams the S8300, S8400, S8500, and S87xx media servers.
A media gateway supports audio and signaling traffic that is routed between IP and circuit-switched networks. The Communication Manager running on Avaya media servers controls voice and signaling over a variety of media gateways. The media gateways contain the network and the endpoint interfaces, as well as call classification and announcement boards . Avaya media gateways are designated G nnn (for example, G700). The media gateway applications run on the VxWorks Real-time Operating System (RTOS).
Media servers and media gateways may be housed in the same or separate platforms. In larger configurations, these components are separated. For smaller configurations, the media server and media gateway are housed in the same platform. For example, the S8300 Media Server can be installed in a G350 Media Gateway. Such a configuration might serve a small or medium- sized business or a branch office of an multisite VoIP deployment. In the latter case, the S8300 Media Server may be configured as a LSP (Local Survivability Processor) in the event connectivity with the remote primary call controller at a headquarters site is lost. Figure 8-2 illustrates the various media gateways.
Figure 8-3 from the Avaya Application Solutions: IP Telephony Deployment Guide illustratesin general termsthe media servers and media gateways used to support certain numbers of communication devices (the IP phones).
The Communication Manager provides support for the following devices:
Avaya IP telephones 4600 Series (4602, 4606, 4612, 4620, 4621SW, 4622SW, 4624, 4625, 4630, and 4690)
Avaya IP telephones 9600 Series (9620, 9630)
Avaya digital telephones 6400 series, 2402, and 2420
Avaya IP softphone
Avaya IP softphone for Pocket PC
Avaya IP agent
Extension to cellular application
DEFINITY Wireless DECT system
Avaya wireless telephone solutions
Figure 8-4 illustrates several 4600 and 9600 series IP phones.
Avaya's primary signaling protocol is H.323. Avaya, of course, uses RTP for media/audio. Avaya also supports SIP, but this is much less common than H.323. Note, however, that Avaya embeds quite a bit of proprietary messaging within H.323 to support features they provided with their legacy handsets.
Avaya provides various management systems for controlling their VoIP systems, including various bundled and optional third-party tools. The combined management suite runs on a variety of platforms and operating systems, including various Microsoft Windows operating systems. The bundled management system is called the Avaya Integrated Management (AIM) Standard Management Solutions (SMS). Its components include the Avaya Installation Wizard (AIW), Native Configuration Manager, and Maintenance Web Interface. The System Access Terminal (SAT) allows administrators to manage Communication Manager objects. SAT access is through the web interface, telnet, or SSH. Figures 8-5 and 8-6 show several examples of the Avaya management screens.
Avaya also provides several application programming interfaces (APIs) to interact with Communication Manager from other Avaya or third-party platforms. These APIs are listed because they provide a possible vector for attack:
Application Enablement (AE) services Provides connectivity between applications and Communication Manager. This connector allows development of new applications and new features without having to modify Communication Manager or expose its proprietary interfaces.
CallVisor (CVLAN) Enables applications to communicate with Communication Manager. CVLAN sends and receives Adjunct-Switch Application Interface (ASAI) messages over shared ASAI links on TCP/IP. An application can use ASAI messages to monitor and control Communication Manager resources.
Device and Media Control API Provides a connector to Communication Manager that allows clients to develop applications that provide first party call control. Applications can register as IP extensions on Communication Manager and then monitor and control those extensions.
To be sure, these represent a rich set of APIs for interaction with the Communication Manager. However, the more adjunct servers and APIs that are added to a telephony deployment and permitted to interact with the core telephony applications, the tougher it is to secure all of those adjunct servers and applications to prevent them from being used as a conduit to attack or to subvert core telephony operations. Figure 8-7 illustrates a Communication Manager system, along with several management consoles and adjunct systems using Avaya-provided APIs.
Avaya does not manufacture their own networking infrastructure. Avaya Communication Manager systems are compatible with popular switching infrastructure from vendors such as Cisco, Extreme, 3COM, Nortel, and so on. For information on network-based attacks, including those unique to Cisco equipment, see Chapters 4, 5, 6, and 7.