-
Cisco Voice Switch Services (VXSM) Configuration and Command Reference Guide, Release 5
-
About This Manual
-
Introduction
-
General Description
-
Configuration for VoIP Switching Applications
-
Configuration for AAL2 Trunking Applications
-
Configuring VXSM Features
-
Upgrading VXSM Code Images from a Previous Version
-
CLI Commands (? to dnpath)
-
CLI Commands (dapaal2cidfillertimer to uppath)
-
VXSM Troubleshooting
-
Media Gateway Clocking
-
Table Of Contents
Switching and Non-switching Operation
AAL2 Trunking (Non-switching) Operation
Trunking (Non-Switching) Features
1:1 Front and Back Card Redundancy
1:1 Front Card/Back Card Redundancy
Support for the Communications Assistance for Law Enforcement Act (CALEA)
General Description
This chapter provides a general description of:
•
The features and functions of the Voice Switch Service Module (VXSM) card set.
•
Physical
Physically, VXSM consists of a full height front card and a half height back card or cards. The front card includes a large daughter card on which the digital signal processors (DSPs) are installed. The front card and daughter card are installed as a single assembly and require only one slot. The complement of cards is as follows.
Front Cards
Two types of front card are supported, (see Figure 2-1).
•
•
Back Cards
The three types of back card are supported (see Figure 2-2).
•
•
Note
Ortronics 24 Port Patch Panel - Part # 808-044990
Ortronics 48 Port Patch Panel - Part # 808-045368•
MGX Chassis
VXSM cards can be installed either in a Cisco MGX 8880 or a Cisco MGX 8850 chassis. The differences between these chassis are as follows.
•
•
•
•
Note
Figure 2-1 VXSM Front Cards
Figure 2-2 VXSM Back Card
The pin assignments on the 24 T1/E1 back card are as shown in Table 2-1 and Table 2-2.
Card Slots
In an Cisco MGX 8880 chassis or an Cisco MGX 8850 chassis, VXSM cards can be installed in slots 1 - 6 and 9 - 14. Slots7 and 8 are reserved for PXM-45c cards.
The twelve slots (1 - 6 and 9 - 14) are available for VXSM cards. However, all installed AXSM and/or RPM-XF cards, also share these slots.
Slots 15 and 16 are reserved for SRM cards. These cards are typically not used in an Media Gateway application and the slots must be left empty.
When 1:1 redundant VXSM front cards are configured, the redundant pair must be installed in adjacent slots (for example, slots 1 and 2 or slots 9 and 10).
VXSM Firmware Images
VXSM is available with two versions of firmware. One version permits the user to configure support for the Communication Assisted Law Enforcement Act (CALEA); the other version does not. The user must specify which version, CALEA or non-CALEA, at the time of order.
The non-CALEA version supports three media gateway control protocols but only one at a time, the CALEA version supports TGCP only. The user must choose between either the H.248, TGCP, or MGCP protocol. The choice is made by executing the setrev command on the PXM. In this command the user specifies the VXSM card (by slot number) and selects the media gateway control protocol as one of the parameters. The effect of this command is to load a firmware image in the VXSM card in which the selected protocol commands and functions are enabled. The "non-selected" protocol commands and functions are not available.
Switching and Non-switching Operation
VXSM support two methods for routing voice calls, namely, a switching method for VoIP applications and a non-switching method for AAL2 trunking applications. The difference is how the internal and external connections are configured. A VXSM card can support only one or these methods at a time. However, the media gateway can support both methods by using different VXSM cards.
Switching (VoIP) Operation
In switching operations, VXSM switches voice traffic between the conventional TDM voice network and the packet network under the control of a media gateway controller (MGC). VXSM and the MGC must have IP connectivity and use either the H.248 (MEGACO) protocol, the TGCP protocol, or the MGCP protocol to communicate with each other.
Using one of these protocols, VXSM and the MGC keep each other informed at each stage of the call setup and call tear down processes (on/off hook, dial tone, dialing, hang-up, etc.). At each stage, the MGC instructs VXSM how to perform the next step.
During call setup, a bearer circuit is setup across the packet network. This bearer circuit is used to establish IP connectivity for the voice traffic between the calling and called media gateways.
VXSM uses either an AXSM card or an RPM-XF card as its interface to the packet network. In the case of the AXSM card, communication between the gateways is voice over ATM communication using AAL5 PVCs. In the case of the RPM-XF card, communication between gateways is voice over IP communication using a gigabit Ethernet network.
Figure 2-3, shows a block diagram of this process.
Figure 2-3 Switching Operation Block Diagram
Switching Features
Switching operation supports the following features.
TDM Network Side
Interfaces
4 OC-3/STM-1 and channelized 48 T1/E1
Companding
Mu law and A-law conversion,
Configurable mu law and A-law endpoints on network side
Echo cancellation
Echo removal on PCM samples using proprietary algorithm. 8, 16,24,32,64, or 128 ms tails
Tones
Detects V.25 (with and without phase reversal) and V.8 signals or V.21 preamble or CNG tone to discriminate between voice, fax and data calls
Upspeed to PCM upon fax/modem detection
The DSP module is capable of detecting DTMF tones while processing voice signals and transporting them in or out of band. (RFC 2833 and I.366.2 compliant)
Support for SS7 Continuity tone for 2 and 4 wire circuits
PRI Backhaul
In applications where ISDN D channel signaling line are connected to VXSM, the VXSM can be configured to extract the layer 3 (Q.931) packets and backhaul them to the media gateway controller (this feature is described later in this chapter). PRI backhaul supports the RUDP media gateway controller protocol.
Network Bypass
For calls that originate and terminate on lines on the same VXSM card or the same media gateway, VXSM can be configured so that the call is routed within the media gateway and does not use IP or packet network resources. This feature operates with H.248 media gateway control protocol only.
Packet Network Side
ATM
Real Time Protocol (RTP)
AAL 5 PVCs for bearer circuitsCodecs
G.711, G.726-(16K, 24K, 32K,and 40K), G.729a, G.729a/b, and G.clear (clear channel).
Connection Admission Control (CAC)
VXSM maintains information on available/used bandwidth on bearer virtual circuits. For PVC calls, before a call is admitted, a bandwidth check (based on code, packetization period, VAD, etc.) is made against the available PVC bandwidth. The result determines whether the call is accepted or rejected.
Packetization Period
The codec packetization period is configurable up to 80ms.
The VDB codec packetization period is configurable form 10ms to 30ms in 10ms increments
Jitter
Removes arrival time jitter from the incoming packet stream. Jitter buffer can handle up to 100 ms.
Silence suppression
Uses voice activity detection (VAD) on bearer circuits to detect silence and suppress the transmission of cells containing nothing but silence.VAD is applicable on codecs G.711, G.726, G729a, G.729b and G.729ab
Differentiated Services (DiffServ)
VXSM provides support for the quality of service (QOS) feature known as DiffServ. The DiffServ feature permits devices at the edge of the network to specify the contents of the Type of Service (TOS) field in the IPv4 header as a differentiated services point code. This point code can then be used by routers in the network to determine per hop behavior (PHB).
AAL2 Trunking (Non-switching) Operation
In a trunking operation, VXSM directs voice traffic between the conventional TDM voice network and one or more pre-provisioned AAL2 ATM PVC trunks on the packet network (see Figure 2-4). As it name implies, this mode does not involve switching and does not involve a media gateway controller. Associations are made between the DS0 and DS1 circuits in the TDM network and AAL 2 CIDs in the ATM packet network. These associations determine which trunk a call will use.
Voice streams are identified by a Circuit Identifier (CID) and packed into AAL 2 cells. The mode supports subcell multiplexing in which partially filled cells can be filled with data from other CIDs thereby improving the bandwidth usage of the trunk.
In this mode, signaling is not terminated and is passed over the trunk. CCS (ISDN PRI) signaling is transported over HDLC/AAL5. SS7 uses AAL2 profile CUSTOM 200 (clear channel).
Upon detection of a fax or modem tone, this mode supports the upspeed feature.
Figure 2-4 Trunking Block Diagram
Trunking (Non-Switching) Features
Trunking operation supports the following features.
TDM Network Side
Interfaces
4 OC-3/STM-1 (channelized) and 48 T1/E1
Companding
Mu law and A-law conversion,
Configurable mu law and A-law endpoints on network side
Echo cancellation
Echo removal on PCM samples using proprietary algorithm. 8, 16,24,32,64, or 128 ms tails
Tones
Detects V.25 (with and without phase reversal) and V.8 signals or V.21 preamble or CNG tone to discriminate between voice, fax and data calls
Upspeed to PCM upon fax/modem detection. The upspeed codec is configurable.
The DSP module is capable of detecting DTMF tones while processing voice signals and transporting them. (RFC 2833 and I.366.2 compliant
Packet (Trunking) Network Side
Codecs
G.711 (mu-law and A-law), G.729a, G.729ab, and G.clear (clear channel).
Voice activity detection
Uses a VAD algorithm, provides updates for the remote end on the background noise level so that the comfort noise generator can sound as natural as possible.
AAL2 CPS subsystem
ITU-T standard I.363.2 "B-ISDN ATM Adaptation layer specification: Type 2 AAL, to multiplex/de-multiplex multiple low speed AAL2 connections over a single ATM VC.
Timer_CU for subcell multiplexing timing
Sequence number protection checks for CPS-PDU
LI checks for each CPS-packet
Data transfers of CPS-Packets with CPS-INFO fields of up to 45 octets (no support for the 64 octet option)
CRC5 (HEC) generation/checking in the CPS-PH of the CPS-packet
OSF of the STF checking
Max_SDU_Deliver_Length" checking (the length of the received CPS-Packet Payload exceeds the maximum length)
Odd parity checking for the STF octet of the CPS-PDU
CPS-PDU padding as needed.
Support up to 248 channels (CIDs) of AAL2 per ATM VC (8..255).
AAL2 SSCS (I.366.2).
ITU-T standard I.366.2 "Service Specific Convergence Sub-layer for the AAL type2".
–
–
–
–
–
VXSM supports the following standard based (I.366.2 annex P) ATM profiles:
ITU 1,TU 2, ITU 3, ITU 7, ITU 8.In addition, the following Cisco custom profiles are supported, Custom 100, 101, 110, 200. Details of these custom profiles are provided in Chapter 5.
Note
Redundancy
The Cisco MGX 8880 or Cisco MGX 8850 and the VXSM cards support a variety of redundancy schemes both at the card and line level. The particular details of each scheme depend upon whether the back cards support OC-3 or T1/E1 lines.
Note
OC-3 Systems
OC-3 equipped systems support the following redundancy schemes.
•
•
•
•
Card and line redundancy can be combined in a single configuration.
1:1 Front Card Redundancy
In this scheme, the two VXSM front cards are installed in adjacent slots (slots 1 and2, 3 and 4, 5 and 6, 9 and 10, 11 and 12, 13 and 14). The active card has the OC 3 back card and the standby card has a redundant back card (see Figure 2-5). In the event of a front card failure, the redundant front becomes active. The lines in back card are connected, through the redundant back card to the redundant (now active) front card.
Figure 2-5 1:1 Front Card Redundancy
1:1 Front and Back Card Redundancy
In this scheme, VXSM front and back card sets are installed in pairs, namely, an active set and a standby set. For this feature to operate the active and standby VXSM card sets must be in adjacent slots (slots 1 and2, 3 and 4, 5 and 6, 9 and 10, 11 and 12, 13 and 14).
The VXSM 4-OC 3 back card provides a data path between the VXSM front card and the optical transceivers on back cards. It also provides the data path between the redundant front card and the optical transceivers on back card for front card redundancy. The VXSM back card also provides a data path between the adjacent front card and the optical transceivers on the back card for 1:1 legacy APS implementation.
The VXSM back card has an NVRAM on the board, which can be accessed via local front card or via the redundant front card when redundant configuration is enabled or via the adjacent back card when 1:1 legacy APS is enabled.
The 1:1 Front and Back Card Redundancy scheme is shown in Figure 2-6.
Figure 2-6 1:1 Front and Back Card Redundancy
If a failure occurs in either the active front card or the active back card, the whole standby card set automatically switches over and becomes the active card set. The new data path after switchover is shown in Figure 2-7.
Figure 2-7 1:1 Front and Back Card Redundancy after Switchover
Line Redundancy
SONET line APS redundancy can be set up either as same card or adjacent card.
In same card redundancy, a second Four-OC3 back card is installed in the lower bay providing lines 5 to 8 in addition to the lines 1 to 4 in the upper bay. One line in the upper bay is designated the working line and one line in the lower bay is designated the protection line.
In adjacent card redundancy, a VXSM front and back card set are installed in adjacent slots. Line redundancy is provided by designating one line on one back card and one line on the other back card as the working/protection set.
1+1 APS line redundancy
VXSM cards with SONET back cards also support 1+1 APS line redundancy in which there are two channels. One channel is designated the working channel and the other the protection channel.
In 1+1 APS architecture, the source node sends the data on both working and protection channel to the destination simultaneously. The destination chooses to receive the data from one of the two fiber channels, called the working channel. If there is a failure in the working channel due to fiber cut or other reasons then the destination simply switches over to the protection channel. The destination continues to receive the data from the protection channel even after the other channel is fixed which is referred as nonrevertive mechanism.
1+1 APS line redundancy can operate on both same card and adjacent card redundant configurations.
1:1 APS line redundancy
VXSM cards with SONET back cards also support 1:1 APS line redundancy
1:1 APS architecture is similar to 1+1 APS architecture in a way that there are also two fiber channels. Traffic is, however, transmitted only on the working channel. When the network is operating under normal conditions the protection channel is unused or only used for carrying low priority traffic. The nodes switch the traffic to protection channel only when a failure occurs.
1:1 APS line redundancy can only operate on a same card redundant configuration.
48 T1/E1 Systems
The 24 T1/E1 backcard is designed to support:
•
•
1:1 Front Card/Back Card Redundancy
Two VXSM front cards are installed in adjacent slots. Each front card has two 24 T1/E1 back cards installed, one in the upper bay and one in the lower bay. Each of the four back card has two 50-pin connectors, one for transmit and one for receive. Y-cables are used to connect lines to the corresponding connectors on each card set. The redundant arrangement is shown in Figure 2-8.
Figure 2-8 1:1 Front Card/Back Card Redundancy
For this type of redundancy one card set is the active set and the card set in the adjacent slot is the standby. During operation both the card sets are receiving traffic but only the active set is transmitting on the lines. In the case of any failure in the active front card, top back card or bottom back card, the redundant card set becomes the active card set. The switchover is supported with the Y cables.Therefore, in the case of a switch over, complete traffic (on all 48 T1 or E1 lines) is transferred to the adjacent slot.
1:1 front card redundancy
The 1:1 Front Card Redundancy scheme differs from the 1:1 Front Card Back Card scheme in that the redundant card set has redundant back cards (that do not have the lines connected to them) instead of 48 T1/E1 back cards. In this scheme Y cable operation is not be supported. The 1:1 Front Card redundancy is shown in Figure 2-9.
In this case a RCON card (gang card) is needed and there is no back card redundancy. The redundant back card is required to switch traffic from the active front card to the redundant front card in the event of a failure. The 1:1 redundancy is achieved with the RCON (gang card used for 1:N redundancy but with N=1 only)
Figure 2-9 1:1 front card redundancy
ISDN Signaling (PRI Backhaul)
When D channels of ISDN PRI lines are connected to the TDM side of the VXSM card, VXSM can be configured to extract the layer three (Q.931) frames from the ISDN stream and pass (backhaul) them to the gateway controller. Likewise, Q.931 frames received from the gateway controller can be encapsulated into layer two (LAPD Q.921) frames and transmitted over the appropriate D channel ISDN lines on the TDM side. This function is known as PRI Backhaul.
On the TDM side, ISDN PRI standards protocols are used. The Q.931 signaling frames are encapsulated in Q.921 (LAPD) frames and transported as High Level Data Link Control (HDLC) frames. The HDLC and Q.921 layers are terminated at the VXSM.
For communication between VXSM and the media gateway controller the protocol stack is based upon the Cisco proprietary Session Manger and RUDP (Reliable UDP).
Communication between the VXSM and the gateway controller is session based. One session set must be established. The session set contain one or two session groups (one for non-fault tolerant or two for fault tolerant configurations). Each session group can support up to four RUDP sessions.
Figure 2-10 shows the protocol stacks for RUDP.
Figure 2-10 PRI Backhaul Protocols using RUDP
The PRI backhaul feature can be configured as non-fault tolerant using a single gateway controller or fault tolerant using two gateway controllers; one active and one backup. Both configurations can be combined with 1:1 VXSM card redundancy. Automatic switchover is supported for both gateway controller or VXSM card failures.
On the ISDN side, specific DS1 lines used for D channels can be configured as ISDN LAPD.
Configuration of PRI backhaul using the CLI is described in Chapter 5.
NFAS/D-Channel Backup
When VXSM is performing ISDN PRI backhaul, the D-Channel in an Non-Facility Associated Signaling (NFAS) voice stream can be protected with the use of a backup D-channel.
NFAS voice streams employ 479B+D channels where a single signaling channel (D-channel) controls up to 20 DS1s interfaces. If the D channnel fails it can bring down all the 479 bearer B channels.
Announcements
In switching applications (H.248 media gateway control protocol only), VXSM includes an announcement feature in which pre-recorded announcements can be played on a voice channel under the control of the MGC. A set of announcement files is maintained on an announcement server. When an announcement is to played, the MGC uses the announcement package in the H.248 protocol to instruct VXSM to play the announcement. If the announcement has been previously cached by VXSM, the announcement is played out of cache. If not, VXSM uses TFTP to download the file from the announcement server, cache it, and play the announcement.
Announcement files must be in PCM format and no more than 30 second in play out duration (this represents a file size of approx. 240 kilobytes). When a file is downloaded from the announcement server, it is stored in a cache in the VXSM which can hold up to 136 announcements. When cache becomes full, any request for an announcement that is not in cache results in the requested file being downloaded and replacing an existing cached file on a "least recently used" basis.
Announcement files can be configured as permanent in which case they remain in cache and are never replaced.
In addition to the announcement files and the VXSM cache, the user maintains a list of announcement files on VXSM. This list is in the form of a table, indexed by the announcement number, and it contains the name of the file (with directory path, if applicable) in the TFTP server. It also contains (associated with each file) the default values of the optional parameters that the MGC provides with the "play announcement" signal. The mapping of announcement index number to announcement filename must be maintained both in the VXSM and MGC. The MGC specifies the file index in the signal to indicate which announcement it wants to play.
The MGC can specify that the announcement be played in the direction of the caller, or the called party, or both.
In the current implementation, no redundancy for announcement is supported.
Only the active VXSM card can communicate to the announcement server. All announcements are downloaded on the active card only. When a switchover happens, the newly active card downloads the permanent announcements from the announcement server as soon as it goes active. The dynamic announcements are downloaded on the newly active card on demand.
If a card switches over while playing an announcement, the announcement is not automatically continued on the newly active card. The MGC will have to explicitly restart the announcement on the newly active card.
Processing Voiceband Data
Within a voice circuit call, VXSM supports the handling of voiceband data such as clear channel, fax, and modem transmissions. VXSM can detect tones associated with voiceband data on both the voice and IP sides of the networks, and act accordingly. Upon detection of a voiceband tone, VXSM will perform the necessary upspeed procedure that may involve the following processing:
•
•
•
•
In order for upspeed to operate correctly, both ends of the connection must perform the upspeed procedure. For this reason, VXSM informs the other (remote) end of the connection when an upspeed procedure is to be performed. There are two different methods by which upspeed at the remote end is triggered.
In the first method, called Fax/Modem passthrough with NSE, VXSM informs the remote end when it detects a voiceband tone on the voice TDM side of a call. This procedure involves a Cisco proprietary protocol in which a Named Signaling Event (NSE) is sent to the remote end. This method can be used for connections where both ends are VXSM cards or where one end is a VXSM card and the other end is a NSE compliant Cisco product.
The second method, called Fax/Modem passthrough with IP side tone detection, relies on both ends of the connection being able to detect tones on both the TDM and IP sides. Thus both the originating and the terminating ends of the connection are able to detect the necessary tones and the need for any NSE type of message is eliminated. This method can be used with NSE compliant or none NSE compliant devices. Fax/Modem passthrough with IP side tone detection is only supported with TGCP or MGCP call setup.
Fax/Modem passthrough features are as follows:
•
•
•
•
•
•
Network Bypass
Network Bypass is a feature of a VXSM based media gateway for the efficient handling of calls that originate and terminate on the same gateway. This feature operates with H.248 media gateway control protocol only.
Depending upon their destination, incoming calls on a VXSM card can be routed in the following ways.
•
•
•
The VXSM network bypass feature, when enabled, examines the destination (NSAP address prefix) of each incoming call and makes a determination as to which of the three routing situations applies. If the incoming call is for a ds0 on the same or another VXSM card in the same gateway, the routing of the bearer circuit is made entirely within the VXSM cards in the gateway and does not involve the IP network. In this way the unnecessary use of network resources is eliminated.
Network bypass employs a mesh of user configured internal PVCs. The mesh consists of the following connections.
•
•
•
Figure 2-11 shows an example of the PVCs for a three VXSM gateways.
Figure 2-11 Example of PVC Mesh for Network Bypass
Support for the Communications Assistance for Law Enforcement Act (CALEA)
VXSM provides support for CALEA intercepted calls. The CALEA feature functions only in switching applications using the TGCP gateway control protocol.
During call setup, the media gateway controller uses the TGCP commands of CRCX and MDCX with CALEA parameters to signify that a call is to be subject to CALEA surveillance. During a CALEA call, the VXSM sends a duplicate of the call contents to a TGCP defined CALEA server.
VXSM supports up to 60 concurrent CALEA calls. Statistics collection for CALEA streams is not supported.
Note
Alarms and Statistics
VXSM has the ability to monitor a large number of operational parameters and measure their values against configurable threshold values. When a parameter falls outside its valid threshold, an alarm is set. Likewise, VXSM maintains a large number of counters for the purpose of collecting and maintaining running statistics.
Alarms
LED Indicators
The first level of alarm/status indicators are the LEDs located on the faceplate of the VXSM front card. Some of these LEDs refer to card level alarms and others to port level alarms.
Card Level LEDs
There are three card level LEDs, namely, ACTIVE, STANDBY, and FAIL.
•
•
•
Port Level LEDs
There are port level LEDs for each port supported by the front card. Four LEDs for the OC_3 version and 48 for the T1/E1 version.
The line LEDs are lit:
GREEN - if the line has been added and there is no alarm on that line.
ORANGE - if the line has been added and there is a YELLOW alarm condition on the line.
RED - if the line has been added and there is a LOS condition (RED alarm condition) on the line.
Software Alarms
The VXSM software is equipped to display a large number of alarm conditions through a set of Display commands. An equivalent set of Configure commands permit the user to set threshold levels that, when exceeded, trigger the individual alarms.
For example, alarms supported for OC-3 ports include.
•
•
•
Statistics
Statistics related to the network interfaces and ATM connections can be collected and stored in a local disk as statistics files. Users can see the value of the collected statistics either by executing certain display commands (for example, dspsvccnt, display SVC counters) or uploading the statistics files to a network management system such as Cisco WAN Manager.
The cnfcdstat (configure card statistics) command can be used to:
•
•
•
•
Data for previous intervals can be uploaded to an NMS while a current interval of data is being collected. However, the data for the current collection interval overwrites the data for previous intervals in the statistics file at the end of the current interval.
Some example commands for displaying statistics are:
dspbert—display BERT counters
dspchancnt—display channel counters
