|
|
This chapter provides an overview of the Cisco telephony controller software for releases 4.0 through 4.2.x.
This guide uses the terms telephony controller software or telephony controller application to mean the Cisco telephony software that runs in the UNIX environment on a host server. The terms telephony controller or telephony controller node refer to the combination of this software and the host server. The Cisco telephony controller software supports a variety of solutions, including the Cisco VSC2700 with the Catalyst 8500 series Multiservice Switch Routers solution and the Cisco SS7/CCS7 Dial Access solution (DAS). This guide pertains to single or failover configurations.
This chapter includes the following sections:
The Cisco telephony controller software is part of several solutions designed to perform call processing, protocol conversion, and call switching and routing functions. The telephony controller software runs on a Sun Microsystems host server and is used in a variety of solutions. Currently, the software is available as part of a Cisco Virtual Switch Controller (VSC) or Cisco Dial Access Solution, (DAS). A brief description of the available solutions follows.
The Cisco VSC solution consists of a telephony controller node in conjunction with Cisco Catalyst 8500 Series Multiservice Switch Routers as gateways to provide voice over ATM (VoATM) services to enterprise customers. The gateway receives voice, video, and data from a PBX and communicates with the VSC via Simple Gateway Control Protocol (SGCP) over an IP network. The VSC routes calls to other gateways through the ATM network. Figure 1-1 shows an overview of a typical VSC configuration.
See the Cisco VSC2700 Network Solution Integration Guidelines (78-6463-xx) for more information on the VSC.
The DAS consists of a Cisco SC2200 signaling controller running telephony controller software in conjunction with Cisco network access servers (NAS), such as the Cisco AS5200, Cisco AS5300, or Cisco AS5800 to provide SS7 services to large dial Points of Presence (POPs). The signaling controller emulates a terminating or originating end-office telephone switch in the Public Switched Telephone Network (PSTN).
Figure 1-2 shows the setup for a DAS with mated signal transfer point (STP) pairs using A links. In this redundant system, the STPs share the load and protect your system against failure by diverting the traffic around the failure. This setup includes only one NAS, and all the DAS components are located on the same subnet.
See the Cisco SS7/CCS7 Dial Access Solution System Integration Guidelines (78-6011-xx) for more information on the DAS.
As part of a total dial access or switched solution, the telephony controller software provides support for many telephony features, including the following:
1.1.3.1 Physical Signaling and Bearer Interfaces
The telephony controller software works with T1/E1 and V.35 interfaces, as well as with Ethernet signaling. The telephony controller software can be used with T1/E1 intermachine trunking (with a DAS) as well as ATM (with a VSC solution).
1.1.3.2 Signaling and Call Processing Functions
The telephony controller software supports these signaling and call processing functions:
1.1.3.3 Management and Billing Functions
The telephony controller software provides the following management and billing functions:
1.1.3.4 Hardware Platforms
Table 1-1 lists the available hardware platforms for the telephony controller software.
| Cisco Product Number | Configuration | Platform | NEBS Compliant | AC/DC |
|---|---|---|---|---|
Cisco SC2201 | Single system | Sun Netra T1120 | Yes | DC |
Cisco SC2202 | Dual system | Sun Netra T1120 | Yes | DC |
Cisco SC2211 | Single system | Sun Enterprise 450 | No | AC |
Cisco SC2212 | Dual system | Sun Enterprise 450 | No | AC |
Cisco VSC2701 | Single system | Sun Netra T1120 | Yes | DC |
Cisco VSC2702 | Dual system | Sun Netra T1120 | Yes | DC |
Cisco VSC2711 | Single system | Sun Enterprise 450 | No | AC |
Cisco VSC2712 | Dual system | Sun Enterprise 450 | No | AC |
1.1.3.5 Protocols
The telephony controller software supports numerous telephony protocols:
1.1.3.6 Security Features
The telephony controller software provides standard UNIX security features. You can control access to the telephony controller software by setting permissions for user IDs. Only users in the transpath group can perform most system operations. For example, users must enter Man Machine Language (MML) commands to perform actions such as retrieving the status of processes or process groups, setting channels In-Service and Out-of-Service, and blocking calls. When MML is started, it looks in the /etc/group file to see if the user is in the transpath group. If not, that user will have "monitor" access and will not be able to use certain MML commands. If the user is in the transpath group, the user will have "monitor and control access" and will have full MML access. See the "Setting Up the Transpath Group and Users" section for more information.
In addition, configuration is performed on the Network Element Management Server (NEMS) and files are retrieved from this machine using a utility on the host server. Therefore, only approved users with access to the host server can set up and change system configurations or load configuration files onto the server. See the "Installing Your Configuration Files" section for more information.
The telephony controller software runs on a UNIX platform and performs four call processing functions:
The telephony controller software architecture includes five subsystems:
All the components in Figure 1-3 are described in the following sections.
The telephony controller software execution environment (XE) provides the following features:
The XE provides common services to the telephony controller software applications, as shown in Figure 1-4.
Functions provided by the XE are listed in Table 1-2 through Table 1-4.
| Function | Description |
|---|---|
Timers | Provide support for comprehensive set of timer functions for processes. |
Process shell | Provides a framework used by processes to interface with the services provided under the XE. It features:
|
Signal handling | Provides an interface between processes and conditions signaled via the operating system. |
IPC1 | Permits processes to exchange messages. |
| 1IPC = interprocess communication |
| Function | Description |
|---|---|
Process management | Performs orderly startup, shut down, and monitoring of processes. This is also used to implement cut-over to a new version of a process with minimal interruption of service. |
Alarm management | Registers, sets, and clears alarms. Alarm settings and clearances are automatically reported to processes that request this service. This capability can be used to report alarms to attached management interfaces, enabling such processes to implement necessary recovery action. |
Log management | Logs messages to shared log files, based on a facility (that is, type of process writing log message) and logging level (severity). |
Command management | Exchanges commands and responses. This service is also used to provide a unified interface to the protocol conversion engine and/or to external systems that control or monitor the XE platform through a management interface. |
Configuration management | Notifies processes when configuration data has changed. It coordinates dynamic reconfiguration across all processes on the platform. |
Access control | Ensures that platform services are provided only to those authorized to use them. |
| Function | Description |
|---|---|
Statistics | Updates shared counters used for reporting and alarms. Alarms based on shared counters are automatically generated on behalf of all processes on the platform. Measurement reports are automatically generated at periodic time intervals |
Report management | Generates scheduled reports. |
The call processing application translates signaling protocols, as shown in Figure 1-5.
Table 1-5 lists the three components of the call processing application and descriptions.
| Component | Description |
|---|---|
Protocol adapters |
|
Call control state machines |
|
Call context data | Contains call state information for each call currently managed. |
The telephony controller software provides five management interfaces to monitor and control your system:
The I/O subsystem contains channel controllers that have protocol stacks for each base protocol. Channel controllers perform three functions:
Channel controllers perform these procedures on messages from the engine. They also handle channel management messages and service state changes. At a minimum, the system includes two channel controllers (one for each protocol).
The API provides a published set of calls that allow third-party applications to interface with the system.
The telephony controller produces call detail records (CDRs) similar to those produced by switches or other network elements that are used for a customer's billing system. These records are written as a set of files that are spooled to a directory where they can be collected by an external system. You can set a date threshold for these files and any files older than that date are automatically purged when disk space runs low. You can also disable the CDR generation option. (See the "Call Detail Records" section for more information.)
Overload is detected by sampling the length of the engine's main input queue. Sampling is performed by the engine as part of normal message processing.
The telephony controller provides basic protection from overload using two mechanisms:
The overload parameters for your system are configured in the XECfgParm.dat file. See the "XECfgParm.dat - XE Configuration Parameters" section for more information.
Telephony measurements are continuously updated on the telephony controller and reported at 5-, 15-, 30-, and 60-minute intervals to a set of log files. These files are spooled to a directory where they can be collected by an external system. You can set a date threshold for these files, and any files older than that date are automatically purged when disk space runs low.
Records contain the following data:
See the "Measurement Records" section for more information, including a list of telephony measurements taken by the telephony controller.
The telephony controller supports the following set of alarms:
Alarms are captured on the telephony controller by the SNMP agent, which then forwards the alarms to the SNMP manager. The SNMP Manager runs on HP OpenView software on the NEMS. (See the "Retrieving and Clearing Alarms" section for more information on alarms.)
Now that you have a brief overview of the telephony controller software, go to "Preparing Your Telephony Controller," for information on setting up your system.
Posted: Fri Apr 30 15:39:41 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.