Cisco MGX 8850 VISM, Release 1.5 Installation and Configuration
General Description
Downloads: This chapterpdf (PDF - 169.0 KB) | Feedback

General Description

Table Of Contents

General Description


VISM Operating Modes


Connection Management

Endpoint Service States

Restart in Progress (RSIP)

AAL2 Trunking

Digital Signal Processors

Redundancy and Bulk Distribution

Connection Admission Control

General Description

This chapter provides a general description of the features and functions of VISM 1.5 and how they can be used in a variety of applications. More details of VISM and its applications are provided in the Chapters 4, 5, and 6.


Each VISM installed in an MGX 8850 consists of a front card and a back card (if not in bulk mode). This two card set provides interfaces to an ATM packet network and to TDM T1/E1 lines.

Connections to the packet network are made through the MGX 8850 Cellbus to the OC-3 port located on the MGX 8850 PXM card.

Connections to the TDM T1/E1 lines are through ports located on the back card.

Available T1 back cards are:

RJ48-8T1-LM. This card supports 8 T1 lines using RJ48 connectors.

R-RJ48-8T1-LM. This card is used with a T1 front card in redundant configurations.

Available E1 back cards are:

RJ48-8E1-LM. This card supports 8 E1 lines using RJ48 connectors.

SMB-8E1-LM. This card supports 8 E1 lines using SMB connectors.

R-RJ48-8E1-LM. This card is used with a E1 front card in redundant configurations.

R-SMB-8E1-LM. This card is used with a E1 front card in redundant configurations.

Figure 2-1 shows a simplified diagram of the VISM architecture and its major components. These components include the Framer interfaces to the T1/E1 lines, an array of Digital Signal Processors (DSPs), an HDLC framer, and a Segmentation and Reassembly (SAR) section.

VISM is under the control of two independent processors. The main processor performs the VISM control tasks such as configuration, call-setup and management in conjunction with an external Call Agent, and the processing of commands from a Command Line Interface. The secondary processor handles the moving of the data through the system and any required payload processing such as inserting or deleting IP headers and ATM AAL processing.

Figure 3-1 VISM Block Diagram

Ingress traffic (from the TDM network to the packet network) is first processed by the T1/E1 framers and routed to the 36 Digital Signal Processor (DSPs) for echo canceling. The echo cancelled payload is then sent to another DSP for compression (if configured). The output from the DSP section is a stream of pulse coded modulated packets. The HDLC framer is used to process CCS signaling channels.

Processing of the traffic from the DSP section depends upon the mode of the VISM (Voice over IP or AAL2 Trunking). In the case of Voice over IP (VoIP), the data stream is encapsulated using Real Time Protocol (RTP), User Datagram Protocol (UDP), and Internet Protocol (IP). The appropriate headers are inserted into the data stream and the data stream is sent to the Segmentation and Reassembly section for AAL5 processing. For AAL2 Trunking, the data stream is sent directly to the Segmentation and Reassembly section in AAL0 mode.

The now AAL cells are passed across the MGX 8850 cellbus to the PXM card where they are transmitted as ATM cells to the packet network over an OC-3 link.

Egress traffic (from the packet network to the TDM network) follows the same path but in the reverse direction.

VISM Operating Modes

VISM embodies a set of operating modes each of which support a specific set of features and functions of the VISM operation. VISM 1.5 supports two operating modes, namely, VoIP and AAL2 Trunking. The structure of the mode feature is open ended and permits additional modes to be included in future releases.

The Command Line Interface (CLI) command cnfvismmode (configure vism mode) is used to set the desired mode. Upon initial installation, the VISM card is configured for VoIP and comes up in that mode.

Note The CLI and commands are described in Chapter 7.


The major features of the VoIP mode are:

Calls are setup under the control of one or more (up to 8) Call Agents using SGCP or MGCP protocol (CLI configurable).

CAS signaling can be extracted from the voice payload and backhauled to the Call Agent using xGCP (Simple or Media Gateway Control Protocol).

CCS signaling is not supported

The voice payload is converted to IP packets which are then tunneled through an AAL5 PVC to the IP network.

A single PVC for both signaling and data can be configured with a second (redundant) channel with automatic switchover in the event of a failure. AAL5 PVCs can also be configured to provide a split into control and bearer streams. If the signal and data streams are split between one or the other (but not both) of the PVCs can be provided with a second redundant PVC.

In VoIP mode, VISM operates in conjunction with a Call Agent as shown in Figure 3-2. and Figure 3-3

Figure 3-2 VISM using VoIP for Multi-service Access Application

Figure 3-3 VISM using VoIP for Tandem Switch Application

The control path, including all signaling and interfacing to the telephone SS7 network is managed by the call agent which controls VISM using MGCP or SGCP to request setup of the bearer path. The creation of the bearer path is handled by VISM through the creation of a packet network bearer circuit between the calling and called parties for the duration of the call

This call setup procedure between the VISM and Call Agent employs either Media Gateway Control Protocol (MGCP, the VISM default protocol) or Simple Gateway Control Protocol (SGCP). The protocol used between the Call Agent and other Call Agents C-ISUP (Cisco ISDN User Part) using the telephone SS7 network.

Briefly, the call setup procedure is comprised of the following steps.

1. Call setup starts with calling party lifting the handset and dialing a number. The resulting on/off hook and digit signaling is sent to the Call Agent either directly or by VISM through CAS backhauling over SGCP.

2. The Call Agent at the originating end looks up the called number in a table and locates the remote Call Agent that manages the called number. It forwards the IP address of the calling VISM to the remote Call Agent using C-ISUP.

3. The remote Call Agent responds by providing the IP address of the remote VISM back to the originating VISM.

4. With the exchange of IP addresses, a bearer circuit is setup across the IP/ATM network between the calling and the called VISMs. The procedure also involves the negotiation of coding, compression, etc. Endpoints, that identify the two ends of the call to the VISM/DS1/DS0 level, are identified with the bearer circuit so that a complete end to end bearer circuit is established between the calling and called parties. At this point the voice call can proceed.

5. During the call, CAS signaling is sent to the Call Agent for processing. Any resulting action required of VISM is executed by commands from the Call Agent.

In VoIP mode, a single AAL5 PVC is setup for communication with the packet switching network. All calls use this single PVC and it is the responsibility of the network edge router to extract the IP addresses from the voice payloads and route the traffic across the IP network. Figure 3-4 shows the RTP, UDP, and IP protocol stack that is used for transporting VoIP using AAL5. RTP is used because it contains a time-stamp that can be used for dejittering at the remote end.

Figure 3-4 VoIP Protocols

Connection Management

SGCP and MGCP assume a Connection Model where the basic constructs are Endpoints and Connections. Connections are grouped into Calls. One or more connections can belong to the same call. Several connections, that may or may not belong to the same call, can terminate in the same endpoint.

Figure 3-5 Connection Model

SGCP 1.0 and SGCP 1.1 consist of five commands: Notification Request; Notify; Create Connection; Modify Connection; and Delete Connection. MGCP extends SGCP to include: Endpoint Configuration; Audit Endpoint; Audit Connection; and Restart In Progress. SRCP introduces: Audit Gateway; Audit Line; and extends: Notification Request; and Notify.

The Notification Request command is used by the call agent to request the gateway to send notifications upon the occurrence of specified events in an endpoint.

The Notify command is used by the gateway to send a list of observed events to the call agent,

The Create Connection command is used by the call agent to setup a new connection at the gateway.

The Modify Connection command is used by the call agent to modify a gateway's view of a connection.

The Delete Connection command is used by the call agent to terminate a connection.

The Endpoint Configuration command is used to specify the encoding of signals that will be received by the endpoint.

The Audit Endpoint command can be used by the call agent to audit information related to a given endpoint.

The Audit Connection command can be used by the call agent to audit information related to a given connection.

The Restart In Progress command is used by the gateway (VISM) to signal that an endpoint (or a group of endpoints) is brought into or taken out of service.

The Audit Gateway command can be used by the call agent to find out the status of the gateway.

The Audit Line command can be used by the call agent to find out the status of a given line.

Endpoint Service States

Endpoints exist in one of two service states, namely, in-service and out-of-service. The state of an endpoint is determined by user configuration commands and line alarm conditions. When an endpoint is added, it is automatically put into in-service state and, likewise, when an endpoint is deleted is automatically brought out-of-service.

When endpoints are brought out-of-service, the transition can be graceful or forced. If graceful, no new connections are permitted but on-going connections are allowed to end naturally. If forced, no new connections are permitted and all ongoing connections are terminated immediately.

The delete endpoint(s) command causes a graceful transition.

Endpoint can also be brought into and out of service through specific commands which operate either on a line by line basis or on the entire VISM card (gateway). These specific commands are configure line in-service (cnflnis), configure line out-of-service (cnflnoos), configure gateway in-service (cnfgwis), and configure gateway out-of-service (cnfgwoos). These commands allow the user to specify either a graceful or forced transition.

If an alarm condition on a line is raised, all endpoints on the line are brought into a forced transition to out-of-service. An automatic return to in-service is performed when the alarm is cleared unless a specific out-of-service command is executed in the meantime.

Restart in Progress (RSIP)

The Call Agent is kept informed of the state of all endpoints through the use of the xcgp Restart in Progress (RSIP) command. The minimum requirements for this process to operate are:

At least one Call Agent must be configured using the add media gateway controller (addmgc) command.

A protocol must be added for each media gateway controller using the add media gateway controller command (addmgcprotocol) command.

Each Call Agent to receive RSIP messages must be "Associated" with VISM using the configure media gateway controller command (cnfmgc) command.

VISM issues an RSIP when:

One or more endpoints are added or deleted (addenpt, addendpts, delendpt, delendpts)

A line is configured in-service or out-of-service (cnflnis, cnflnoos).

The VISM card (gateway) is configured in-service or out-of-service (cnfgwis, cnfgwoos).

The card is powered up or reset. In this case the RSIP is delayed by a random amount (up to a configurable maximum duration) to avoid an avalanche of RSIPs arriving at the Call Agent when an entire MGX 8850 with multiple VISMs is powered up or reset.

When the state of multiple endpoints are changed simultaneously, VISM minimizes the number of RSIP commands through the use of the wildcard "*" convention of naming endpoints.

When an RSIP is sent to Call Agents, VISM expects an acknowledgement. If no acknowledgement is received after a timeout period, the RSIP is sent again. This process is repeated a number of times after which, if no acknowledgment is received, an acknowledgement is assumed. Both the timeout period and the number of retries are configurable by the user (cnfxgcpretry).

AAL2 Trunking

The major features of the AAL2 Trunking mode are:

The voice payload is transported across the packet network using an AAL2 PVC. Multiple voice channels are supported in a single PVC using CIDs (channel identifiers) and subcell multiplexing. A single VISM supports up 64 AAL2 PVCs.

Call setup through a Call Agent is not supported. All bearer paths are provisioned using either the Command Line Interface (CLI) or Simple Network Management Protocol (SNMP)

If CAS signaling is used, the signaling is transported across the packet network along with the voice payload using AAL2 Type 3 packets.

CCS signaling channels are supported and are transported across the packet network using a separate AAL5 PVC.

Configurable packetization periods and idle channel suppression are supported.

In AAL2 Trunking mode, VISM provides a set of AAL2 trunks carrying the voice payload over the packet network. An example in which VISM operates in conjunction with Cisco's 3810 Multiservice Access Concentrator at the other end of the trunk is shown in Figure 3-6. In this example the Cisco 3810 is located at the customer's premises and interfaces with TDM telephone network through the customer's PBX. The MGX 8850/VISM is located at the Central Office and interfaces to the Central Office Switch through T1 lines.

Voice payloads and CAS signaling are transported across the AAL2 trunk. If a channel is configured for CCS signaling, the signaling is transmitted by extracting HDLC frames and forwarding them over pre-provisioned AAL 5 virtual circuits (the voice payload is still transmitted using AAL 2).

In this role, the VISM does not support any call control terminate any signal functions but merely passes signal traffic to and from the trunk.

Figure 3-6 VISM used for AAL 2 Tunneling

Digital Signal Processors

A major feature of VISM is the array of Digital Signal Processors (DSPs) that provide the extensive capability for the efficient processing of voice signals.

Each VISM contains 37 DSPs. Twelve are general purpose and can be configured to perform echo-cancellation or data compression. Twenty four can be used for data compression only. One DSP is a Jukebox DSP which is used to load code (program) overlays to the other 36 DSPs.

In addition to the DSPs there is one HDLC controller which is used for CCS signal processing.

Together the DSPs support the DS0 channels of the eight T1/E1 lines.

A time slot interchanger routes the DS0s to:

A data compression DSP, or

An echo cancellation DSP and then a data compression DSP, or

The HDLC controller (for CCS processing)

DSPs are loaded with their programs at boot time and can perform the following functions:

Voice Compression/Decompression - VISM permits the user to define codec templates in which each template defines which compression algorithms are permitted. The user can then configure VISM to use a particular template.

When used for compression, the DSPs can support the following algorithms, G.711 64Kbps (mu-law/A-law), ADPCM G.726 32 kbps, G.729a, G.729ab.

Echo Cancellation - When used for echo cancellation, the DSPs can support near end echo cancellation with a tail (delay) of up to 128 msec. The echo cancellation meets ITU G.168 requirements.

Voice Activity Detection - A Cisco proprietary VAD method can be enabled to prevent packets containing silence from being transmitted.

Comfort Noise Generation - The generation of a comfort noise can be enabled at the receiving end during periods of silence.

Digit Detection - The DSPs support the detection of DTMF/MF address signals. The DTMF/MF detector performs under all call establishment environments including on- and off-net. The DTMF detector meets the EIA-464B specification and the MF detector meets the ITU specification for R2 inter-register signaling receivers.

Fax/Modem Detection - The DSPs can monitor the lines and detect the modem or fax tones. Upon detection, VAD and echo cancellation is turned off and codec is changed to G.711.

CAS Signaling - The DSPs can monitor the lines and extract CAS signaling (ABCD bits) for backhauling to a call agent over xGCP (SGCP or MGCP) or for transport through an AAL 2 PVC.

VISM employs the concept of DSP templates. Each template identifies a set of supported voice encoding types. The template to be used by VISM is specified through the CLI cnfcodectmpl (configure codec template) command.

VISM 1.5 supports two templates as follows:

Template 1. This template supports G.711u, G.711a, G729ab, and G.726/32 codecs.

Template 2. This template supports G.711u and G.711a only (no compression).

The structure of DSP templates is open-ended and permits the addition of other templates in future releases.

Redundancy and Bulk Distribution

1:N redundancy for VISM cards with or without Bulk Distribution can be provided through the use of the Service Redundancy Module (SRM-3T3). VISM redundancy is cold redundancy in which ongoing calls do not persist during switchover.

1:N redundancy with Bulk Distribution requires a spare VISM card to be installed and the system uses the three T3 ports of the SRM back card instead of the normal T1 lines on the VISM back cards (which are not required when bulk distribution is used). TDM voice data transmitted or received over the T3 ports are distributed to the VISM card as if they had been received over VISM T1 back card ports in the normal manner. This feature reduces the number of physical lines required to support VISM but requires external multiplexing equipment to multiplex and demultiplex the T1 data onto the T3 lines.

1:N redundancy without Bulk Distribution also requires a spare VISM card equipped with a VISM T1 redundant back card. In this arrangement the VISM cards require and use their normal T1 back cards.

With or without bulk distribution, 1:N redundancy provides for the spare VISM card automatically taking over the functions of a failed VISM card. When the failed card is repaired, switching back to the repaired card is not automatic and must be done manually through the command line interface.

Setting up redundancy is accomplished through the MGX 8850 PXM command line interface which includes a set of redundancy commands (add redundancy, addred, for example). See the Cisco MGX 8850 Command Reference for details).

Note 1:1 redundancy using Y-cables is NOT supported by VISM.

Connection Admission Control

VISM 1.5 includes the Connection Admission Control (CAC) feature whereby the effect of a new call on the bandwidth utilization of the ATM PVC is calculated before the new call is either admitted or rejected.

Each call requires a connection between two endpoints and requires a certain amount of bandwidth. This bandwidth is expressed as cells per second (cps) and depends upon the encapsulation method, the coding/compression method, and whether Voice Activity Detection (VAD) is enabled or not.

CAC maintains a table of all currently active calls and their bandwidth requirements. When a new call is requested, CAC calculates the total bandwidth requirements of all the current calls and adds the bandwidth required by the newly requested call. The new total is then compared with the pre-provisioned bandwidth (cells per second) of the ATM PVC.

If the new bandwidth total exceeds the pre-provisioned bandwidth of the PVC, the call request is rejected. If the new bandwidth total is less than or equal to the pre-provisioned bandwidth of the PVC, the call is accepted.

The default condition is for CAC to be enabled.