-
Voice Interworking Service Module, Release 2.0
-
2.0(1.1) Version Release Notes Cisco MGX 8250/8230 VISM
-
About this Manual
-
Introducing VISM
-
Installation
-
General Description
-
Tandem Switch Application (VoIP Mode)
-
Multi-Service Access Application (VoIP Mode)
-
AAL2 Trunking Application
-
Command Line Interface
-
Troubleshooting
-
Cabling Summary
-
Specification
-
VISM Clocking
-
2.0.(0) Version Release Notes, Cisco MGX 8850 VISM
-
2.0.1 Version Release Notes Cisco MGX 8250/8230 VISM
-
Table Of Contents
CCS Signaling (NFAS PRI/Backhaul)
Redundancy and Bulk Distribution
General Description
This chapter provides a general description of the features and functions of VISM 2.0 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.
Architecture
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:
•
AX-RJ48-8T1. This card supports 8 T1 lines using RJ48 connectors.
•
Available E1 back cards are:
•
•
•
•
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 the12 of the 36 Digital Signal Processor (DSPs) that are configured 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 2.0 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. Thereafter, the VISM card comes up in its configured mode.
Note
VoIP
The major features of the VoIP mode are:
•
•
•
•
•
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 and/or tear down 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).
Briefly, the call setup procedure is comprised of the following steps.
1.
2.
3.
4.
5.
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:
•
•
•
VISM issues an RSIP when:
•
•
•
•
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 time-out 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 time-out period and the number of retries are configurable by the user (cnfxgcpretry).
CAS Signaling
In applications where CAS signaling carried within the T1 and E1 channels is used, VISM 2.0 can monitor the CAS signals and communicate them to the Call Agent using the gateway control protocol. The Call Agent then instructs VISM as to what actions VISM should take. VISM can be configured using the cnfcasvar command to handle various CAS variations such immediate start, wink start, ground start, etc.
CCS Signaling (NFAS PRI/Backhaul)
In applications where CCS ISDN PRI signaling is used, VISM 2.0 can be configured to pass (backhaul) CCS signals between the user PBXs and the Call Agent(s).
When VISM is configured for CCS processing, T1 and E1 lines can be specified as using CCS signaling. For such lines a particular DS0 is specified as an ISDN D channel carrying the PRI signaling. Using the DS0, a connection is setup between the PBX and VISM using level 2 Q.921 signaling protocol. The Q.921 link is terminated at the VISM.
On the Call Agent side, an RUDP/UDP/IP connection is used to carry level 3 Q.931 signaling between VISM and the Call Agent. This link to the Call Agent flows through an intermediate router. From VISM to the router, the RUDP/UDP/IP packets are segmented and transported as AAL5 ATM cells.
The function of the VISM PRI/Backhaul feature is to provide an interface between the PBX and the Call Agent.
Signaling from the PBX is received on the D channel as level 3 Q.931 messages encapsulated in the information field of level 2 Q.921 LAPD information frames. VISM also handles all Q.921 frame types. VISM can be configured to support either the User or Network side of the LAPD protocol. This features allows interoperability with the Cisco AS5300 Voice Gateway.
For information type frames, VISM extracts the Q.931 frame, places it in an RUDP datagram which is then further encapsulated in UDP and IP packets (using the IP address and a specified port number of the destination Call Agent). The SAR section of VISM segments the IP message into AAL5 ATM cells for transport to the Call Agent via an edge router. Thus when using CCS, communication between VISM and the Call Agent involves both call control information using xGCP protocols and CCS signaling using Q.931 protocol. Both are transported using the AAL5 ATM connection.
Signaling from the Call Agent to the PBX is handled in the same manner but in reverse. Signaling from the Call Agent is stripped of its RUDP, UDP, and IP headers and trailers and is encapsulated into Q.921 information type frames for transmission to the user's PBX.
Notice that in this whole process, VISM is not aware of the signaling content but merely acts as an interface between the PBX and the Call Agent.
The VISM PRI/Backhaul process is shown in Figure 3-6.
Figure 3-6 PRI/Backhaul Path
For RUDP links between VISM and the Call Agent(s), the concept of sessions with a session manager is employed.
A session represents a single RUDP link to a specified Call Agent. Sessions are organized into session groups and session groups are organized into session sets. VISM supports up to 64 such sessions and up to 16 session groups.The architecture supports multiple session sets but Release 2.0 currently supports only one session set .
Multiple RUDP links for a specified Call Agent are set up as sessions in a single group. A group is required for each Call Agent for which CCS signaling is to be backhauled. Within a group, each session is assigned a specified priority level. When an active session fails, the session manager switches to the next highest priority backup session within the group. The example of the hierarchy of sets, groups, and session is shown in Figure 3-7.
Figure 3-7 RUDP Session Hierarchy
At both the Q.921 and Q.931 protocol levels, VISM maintains a set of counters for the collection of statistics. Statistics such as the number of frames/packets/bytes sent and received, the number of resets, the number of discards and retransmissions, etc. See the CCS session and lapd display commands in Chapter 7 for details.
PRI/Backhaul includes a comprehensive set of commands that are available to the user through the Command Line Interface (CLI). These commands permit the user to:
•
•
•
•
Details of these commands are provided in Chapter 7.
AAL2 Trunking
The major features of the AAL2 Trunking mode are:
•
•
•
•
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-8. 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-8 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:
•
•
•
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. For V.90 and 9600 baud fax, upon detection, VAD and echo cancellation are turned off and codec is changed to clear channel. For 14,400 baud fax, upon detection, VAD is turned off, echo cancellation is turned off provided there is no phase reversal (usually the case) and the codec is changed to clear channel. Note that if the codec is already set to clear channel, the DSP cannot detect tone and, therefore, Fax and Modem are not detected.
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 2.0 supports two templates as follows:
Template 1. This template supports G.711u, G.711a, G.729a, G.729ab, G.726/32 and clear channel codecs.
Template 2. This template supports G.711u, G.711a only (both with no compression) and clear channel.
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.
Note
Connection Admission Control
VISM 2.0 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.
