-
Cisco Voice Switch Service Module (VXSM) Configuration Guide Release 5.4
-
About this Guide
-
Cisco Voice Switch Service Module Introduction
-
Cisco Voice Switch Service Module Description
-
Configuring VoIP Switching Applications
-
Configuring Switches for AAL2 Trunking Applications
-
Configuring VXSM Features
-
VXSM as a Signaling Gateway
-
Loading and Upgrading VXSM Code Images
-
VXSM Troubleshooting
-
Media Gateway Clocking
-
Table Of Contents
Cisco Voice Switch Service Module Description
Voice Switch Service Module Physical Description
Time-Division Multiplexing Network Side
Virtual Gateways and H.248 Terminations
Virtual Media Gateway Domain Names
Support for H.248 Congestion and Overload
Backhauling Signaling Channels
Communications Assistance for Law Enforcement Act Support
E911 Emergency Services Support
Voice Quality Monitoring Feature
RFC 3611 Voice Quality Monitoring
RTCP XR Extended Network Quality Metrics
Quality Alerts for Voice Band Data Calls
Busy Line Verification and Operator Interruption
AAL2 Trunking Operation—Non switching
Trunking Features—Non switching
Multiprotocol Service Module Interoperability
1:1 Front and Back Card Redundancy
1:1 Front Card/Back Card Redundancy
Processing Fax and Modem Traffic
Cisco Voice Switch Service Module Description
This chapter describes:
•
The features and functions of the Cisco Voice Switch Service Module (VXSM) card set
•
Voice Switch Service Module Physical Description
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 one assembly and require only 1 slot. The complement of cards is as follows.
Voice Switch Service Module Front Cards
Three types of front card are supported (see Figure 2-1).
•
•
•
Note
Voice Switch Service Module Back Cards
Four types of back card are supported (see Figure 2-2).
•
•
•
Note
Ortronics 24-port Patch Panel: Part Number 808-044990
Ortronics 48-port Patch Panel: Part Number 808-045368•
MGX Chassis
VXSM cards can be installed in either a Cisco MGX 8880 or a Cisco MGX 8850 chassis (Figure 2-1 and Figure 2-2). The differences between these chassis are as follows.
•
•
•
•
Note
Figure 2-1 Cisco MGX 8800 Series Chassis with VXSM Front Cards
Figure 2-2 Cisco MGX 8800 Series Chassis with VXSM Back Cards
The pin assignments on the 24 T1/E1 back card appear 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 through 6 and 9 through 14. Slots 7 and 8 are reserved for PXM-45c cards.
The 12 slots (1 through 6 and 9 through 14) are available for VXSM cards. However, all installed AXSM, MPSM, and 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 remain 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: CALEA and non-CALEA:
•
•
The user must specify either CALEA or non-CALEA at the time of order.
Both the CALEA and non-CALEA versions support MGCP and TGCP control protocols but only one at a time. Non-CALEA also supports H.248.
At the time of installation, user must:
•
•
To execute these choices, use the setrev command on the PXM after the VXSM cards are installed. The user specifies the VXSM card (by slot number), the gateway controller protocol, and codec template. Then, the selected firmware and DSP images load onto the VXSM card. The non selected protocol commands and codec functions are disabled.
VXSM Card Applications
Regardless of the firmware image that is installed, VXSM cards can be configured to perform the following three types of applications:
•
•
•
One VXSM card can be configured to perform all three applications concurrently in which TDM lines are assigned to the specific applications.
The following sections describe the two types of media gateway applications. VXSM as a signaling gateway is described in Chapter 6.
Switching Operation—VoIP
VXSM support two methods for routing voice calls:
1.
2.
The difference is how the internal and external connections are configured. VXSM can support AAL2 trunking, AAL5 trunking, and VoIP concurrently on the same VXSM card.
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 the H.248 (MEGACO) protocol, MGCP protocol, or the TGCP protocol to communicate.
Using one of these protocols, VXSM and the MGC communicate at each stage of the call setup and call tear down processes (on/off hook, dial tone, dialing, hang-up). At each stage, the MGC instructs VXSM how to perform the next step.
During call setup, a bearer circuit is set up 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:
•
•
Figure 2-3 shows the switching process.
Figure 2-3 Switching Operation Block Diagram
Switching Features
Switching operation supports the following features.
Time-Division Multiplexing Network Side
Interfaces
4 OC-3/STM-1, 6 T3/E3, 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 in Backhauling Signaling Channels. PRI backhaul supports RUDP (Reliable UDP) and SCTP (Stream Control Transport Protocol) as transport protocols.
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 protocol only.
Busy Line Verification and Operator Interrupt
A caller can request that an operator check a called station to ascertain whether or not it is busy. This feature permits the operator to interrupt an ongoing call and relay a message to the called party.
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
For 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) is made against the available PVC bandwidth. The result determines if the call is accepted or rejected.
Packetization Period
The codec packetization period is configurable up to 80 ms.
The VDB codec packetization period is configurable from 10 ms to 30 ms in 10 ms increments.
Jitter
Removes arrival time jitter from the incoming packet stream. Jitter buffer can manage up to 135 ms.
Silence Suppression
Uses voice activity detection (VAD) on bearer circuits to detect silence and suppress the transmission of cells containing silence. VAD is applicable on codecs G.711, G.723.1, G.723.1 Annex A, G.726, G729a, G.729b, and G.729ab
H.248 Transparent IP-IP Connections
When an H.248 IP-IP connections is created in which the codec and packetization period are the same for each end of the bearer leg, VXSM can be configured to establish the connection in "transparent" mode. Because no transcoding of the bearer stream is necessary in transparent mode, transcoding is eliminated thus permitting bit transparency as well as the better bearer latency (less transit delay over the IP-IP connection). In the transparent mode, the SSRC (Synchronization SouRCe) is also preserved across the connection.
Differentiated Services
VXSM provides support for the quality of service (QoS) Differentiated Service feature known as DiffServ. DiffServ 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).
VoIP Security
VXSM provides a set of security features for the protection of bearer and signaling traffic in switching VoIP applications using TGCP. In particular, these features are designed to meet PacketCable standards.
E911 Emergency Services
VXSM supports an emergency services feature in which 911 dialed emergency calls are automatically directed to an E911 tandem switch and then onto a public safety answering point (PSAP).
Virtual Media Gateways
For H.248 switched applications, a VXSM card has the capability of being partitioned into a number of Virtual Media Gateways (VMGs) where each VMG is a logical entity residing within a physical VXSM card. This feature can be used in applications in which a single Media Gateway Controller (MGC) does not have the capacity to control one VXSM gateway. By partitioning the VXSM card into several VMGs, the control of VXSM's physical and ephemeral terminations can be distributed among several Media Gateway Controllers (one physical termination per MGC).
The VXSM Virtual Media Gateway feature permits a VXSM card to be partitioned into a maximum of 12 virtual gateways. Each of the virtual gateways appears to the MGC as a complete media gateway client and is identified by its own unique domain name. If one VMG goes out of service, the services provided by other VMGs are not affected. VXSM will clear call related data only for the VGM going out of service.
Figure 2-4 shows a VXSM card partitioned into four virtual gateways.
Figure 2-4
VXSM with Four Virtual Media Gateways
Virtual Gateways and H.248 Terminations
Physical terminations are statically partitioned among VMGs. Ephemeral terminations belong to the VMG whose controlling MGC creates them. One termination belongs to one, and only one, VMG. The finest granularity at which physical terminations are allocated to a VMG is at the T1/E1 level. Individual T1/E1 trunks may be added to a VMG, in any order.
The user must first create the required number of VMGs and then allocate terminations to their VMGs as they are provisioned. If VXSM is not to be partitioned, then the user creates only one VMG and associates all physical terminations with it.
Virtual Gateway Redundancy
VXSM supports redundancy at the physical gateway (VXSM card) level. One VXSM card acts as active for all of its VMGs, and another VXSM card acts as standby for all of its VMGs. In case of a failure, a physical gateway (VXSM card) level switchover is performed in which all VMGs on the active card are switched over to the standby card (Figure 2-5).
Virtual Media Gateway Domain Names
For systems using call control protocols other than H.248 (for example, MGCP), VXSM operates as a single media gateway and is assigned a single domain name.
For systems using the H.248 call control protocol, a VXSM card is configured as a number of virtual media gateways in the range of 1 to 12. Each virtual media gateway must be assigned it own unique domain name using the VmgwDomainName parameter in the addh248assoc. Once created it can be changes with the cnfh248mg command. This parameter permits the user to provision a domain name as a character string of up to 64 characters.
Both the addh248assoc and the cnfh248mg command also have a port number and a mIdUsePort parameter. The mIdUsePort parameter determines whether the port number will be used in conjunction with the domain name in the mld field of H.248 messages.
For example, if the VmgwDomainName parameter is used to assign the domain name of VMGW001 and the port number is specified as 2848, the mId of the virtual media gateway is:
VMGW001 if mIdUsePort is set to No port number, or
VMGW001:2848 if mIdUsePort is set to Use port number.
Figure 2-5
Virtual Gateway Redundancy—VXSM Card Level
Support for H.248 Congestion and Overload
VXSM supports the H.248.10 Congestion Control Package, and the H.248.11, Overload Control Package.
The H.248.10 MG Congestion Control Package is used to exchange congestion information between the MG and the MGC. VXSM reports congestion events to the MGC if congestion control has been enabled and MG detects a congestion event.
The H.248.11 MG Overload Control feature protects VXSM from processing overload that prevents the timely execution of H.248.1 transactions. MG Overload happens when the utilization of resources crosses a threshold and MG is close to being unable to respond to MGC transactions in a sufficiently timely manner to avoid the calling customer abandoning the call in setup.
When the H.248 overload feature is enabled, VXSM monitors and detects gateway overload condition. Upon detection of an overload condition, VXSM sends a Notify to the MGC when it receives an ADD command, in this way the MGC can adjust the calling rate to bring MG out of overloaded condition.
Backhauling Signaling Channels
For applications in which the signaling lines or channels are connected directly to VXSM, VXSM can be configured to relay the signaling messages to the Media Gateway Controller (MGC) for call control processing. This backhauling relay function consists of extracting the level 3 signaling message from the level 2 transport protocol, encapsulating it into the IP protocol stack, and relaying it onto the MGC.
To meet the requirements of various service provider networks, VXSM support a number of TDM network-side and the IP network-side protocol stacks for this purpose. VXSM supported backhaul protocols are shown in Table 2-3.
Table 2-3 VXSM Supported Backhaul Protocols
ISDN D-channel (Q.931, Q.921
UDP, RUDP
ISDN D-channel (Q.931, Q.921)
SCTP, IUA
DPNSS or DASS 2 trunks
SCTP, DUA
•
•
•
•
•
•
ISDN/RUDP Backhauling
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 3 (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 2 (LAPD Q.921) frames and transmitted over the appropriate D channel ISDN lines on the TDM side. This function is known as PRI Backhaul. Both T1 and E1 lines are supported.
The backhaul feature can be configured as either:
•
•
Both configurations can be combined with 1:1 VXSM card redundancy. Automatic switchover is supported for both gateway controller and VXSM card failures.
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 manager 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-6 shows the protocol stacks for ISDN/ RUDP.
Figure 2-6 ISDN Backhaul Protocols Using RUDP
ISDN/SCTP Backhauling
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 2 (LAPD Q.921) frames and transmitted over the appropriate D channel ISDN lines on the TDM side. This function is known as PRI backhaul. E1 lines only are supported.
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 Streaming Control Transmission Protocol (SCTP) and the ISDN Q921-User Adaptation (IUA) layer.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers network-level fault tolerance through supporting of multihoming at either or both ends of an association, congestion avoidance, and resistance to flooding.
Figure 2-7 shows the protocol stacks for ISDN/ SCTP.
Figure 2-7 ISDN Backhaul Protocols Using SCTP
DPNSS/SCTP Backhauling
For applications in which DPNSS trunks are connected to the TDM side of the VXSM card, VXSM can be configured to extract the DPNSS layer 3 frames from the data stream and pass (backhaul) them to the gateway controller. Likewise, DPNSS layer 3 frames received from the gateway controller can be encapsulated into DPNSS layer 2 frames and transmitted over the appropriate trunks on the TDM side.
Note
DPNSS trunks are supported on E1 lines only.
For communication between VXSM and the media gateway controller the protocol stack is based upon the Streaming Control Transmission Protocol (SCTP) and the DPNSS/DASS User Adaptation Layer (DUA).
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers network-level fault tolerance through supporting of multihoming at either or both ends of an association, congestion avoidance, and resistance to flooding.
Figure 2-8 shows the protocol stacks for DPNSS/ SCTP.
Figure 2-8 DPNSS Backhaul Protocols Using SCTP
Note
VoIP Security Features
VXSM provides a set of security features for the protection of bearer and signaling traffic in switching VoIP applications using TGCP. In particular, these features are designed to meet PacketCable standards.
RTP and RTCP bearer streams can be protected across an IP network through the use of encryption and authentication algorithms that are applied to the bearer payloads.
The specific security algorithms that are used for any particular call are negotiated during call setup (using TGCP) between the two ends (for example, media terminal adapters) with the media gateway controller acting as a mediator in the process. The signaling links between the media gateways and the media gateway controllers are protected using Internet Security (IPSec and IKE) protocols.
When the algorithms agree, they are used to secure the voice payload.
Note
Figure 2-9 shows the protection in effect for a PacketCable call between two Media Terminal Adapters (MTA).
Figure 2-9 Signal and Bearer Security
Note
Signal Security
VXSM supports protection of the signaling channel through the use of IP Security (IPSec) and Internet Key Exchange (IKE) protocols.
The signaling channel (TGCP) is used to negotiate cipher suites (algorithms) that are to be used on the bearer channel. However, the signaling channel must be capable of protection.
1.
2.
3.
–
–
IPSec supports two modes:
–
–
The following IPSec features are supported by VXSM:
•
•
•
•
Bearer Security
Each VXSM is configured by the user (CLI) to include a table of permissible cipher suites where a cipher suite is a record containing one encryption algorithm, one authentication algorithm and a preference.
When a call is originated, setting up security for the call is accomplished in two phases:
1.
2.
RTP encryption:
•
•
RTP authentication:
•
•
•
RTCP encryption:
•
•
RTCP authentication:
•
•
Note
3.
Encryption algorithms:
•
•
Authentication algorithms:
•
•
Communications Assistance for Law Enforcement Act Support
VXSM provides support for Communications Assistance for Law Enforcement Act (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 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
E911 Emergency Services Support
VXSM supports an emergency services feature in which 911 dialed emergency calls are automatically directed to an E911 tandem switch and then onto a Public Safety Answering Point (PSAP).
Enhanced 911 (E911) is a Federal Communications Commission (FCC) initiative to increase public safety by the deployment of a nationwide, seamless communications system for emergency services that includes the provision of location information for wireless 911 calls.
The E911 feature on VXSM primarily supports Packet Cable applications, and is implemented using the packet cable specified MO (MF OSS) package in the TGCP protocol. The E911feature is shown in Figure 2-10.
Figure 2-10 VXSM E911 Feature
1.
2.
3.
4.
The E911 feature is supported on all versions of VXSM cards, but only T1 circuits are supported.
If redundant hardware has been configured, active E911 calls are preserved during a switchover in the event of a failure.
Announcements Feature
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:
1.
If the announcement has:
–
–
Announcement files:
–
–
2.
3.
In the current implementation, no redundancy for announcement is supported.
Note
4.
5.
Voice Quality Monitoring Feature
When configured for VoIP switched applications using the H.248 call control protocol, the VXSM Voice Quality Monitoring (VQM) feature provides the ability to monitor, collect, and report voice quality metrics to the Media Gateway Controller and/or the remote Media Gateway. Together, the values of the collected metrics represent a measure of the quality of voice calls transmitted across the network. Service providers can use these metrics to observe and diagnose quality problems and to provide a measure for Service Level Agreements between the provider and its customers.
VXSM supports two methods of performing VQM functions:
1.
2.
VXSM can support either of these methods but not both simultaneously. These methods differ in the choice of protocols used to communicate with the remote MG and the MGC and the voice quality metrics that are reported.
RFC 3611 Voice Quality Monitoring
RFC 3611 voice quality monitoring (VQM) uses RTP control protocol extended reports (RTCP XR) VoIP metrics (Figure 2-11).
Figure 2-11 RTCP XR VoIP Metrics Method
RTCP XR VoIP metrics use the RTP control protocol extended reports (RTCP XR) provision in RFC 3611 to append VoIP metrics reports to the normal RTCP packets. This method also involves the Media Gateway Controller (MGC) through the use of H.248 and the H.248.30 RTCP extended performance metrics packages. The two packages are the RTCP XR base package (rtcpxr) and the RTCP XR burst metrics package (xrbm). The voice metrics defined in these packages are consistent with those defined in the RTCP XR VoIP metrics report block. The media gateway controller is able to set up properties and retrieve statistics (voice-metrics) defined in these packages.
RTCP XR Extended Network Quality Metrics
XNQ voice quality monitoring (VQM) uses RTCP XR extended network quality (XNQ) metrics (Figure 2-12).
Figure 2-12 RTCP XR XNQ Metrics Method
This method uses the RTP control protocol extended reports (RTCP XR) provision in RFC 3611 to append XNQ metrics reports to the normal RTCP packets. This method also involves the media gateway controller (MGC) through the use of the H.248 RTCP extended network quality metrics package. The voice metrics defined in these two packages are consistent with those defined in the RTCP XR XNQ metrics report block. The MGC can set up properties and retrieve statistics (voice-metrics) defined in these packages.
Voice Quality History Reports
VXSM can maintain a history table to generate voice quality history reports to help service providers track their service level agreements. The history report tracks the minimum, maximum and average of the various voice metrics. History table entries are updated only if VQM feature is enabled.
The statistic upload function is used to retrieve the history table periodically. After the voice metric history table is retrieved, the history table is reset.
Voice Quality Alerts
VXSM has the capability of generating voice quality alerts that are reported to the Service Provider in real-time. Voice quality alerts are determined by comparing the measured value of a trigger voice metric to a threshold value. For each voice metric, the threshold values are determined by the following two parameters.
•
•
When the measured value of a voice metric is worse than the reference value by more than the threshold percentage a voice quality alert is triggered.
VXSM supports one trigger per call at any one time. There is no support for multiple simultaneous triggers in a single call. Each T1/E1 interface can be configured with a different trigger metric. In addition, a default trigger metric can be configured for the whole gateway or a virtual gateway. If neither the gateway nor T1/E1 interface level trigger metrics are configured, no quality alert events or traps are generated and the MGC cannot enable quality alert events.
Voice Quality alert events are reported to the MGC and are based on the H.248 network package. This package allows for multiple thresholds, however, VXSM supports only one. Upon receipt of multiple thresholds, only the last threshold takes effect. If the MGC specifies the alert threshold percentage parameter when enabling a quality alert event, the MGC specified value overrides the threshold value provisioned on VXSM. If MGC does not enable a quality alert event, no alert event notification is sent to the MGC even though a quality alert trap may be generated to the SNMP Manager. After an alert notification is sent to the MGC, VXSM does not re-arm the quality alert event. Thus, a subsequent cross over of the alert threshold does not trigger another alert notification to the MGC.
SNMP voice quality alert traps are also supported. If the voice quality alert event is detected, VXSM can send SNMP quality alert traps to an SNMP Manager if the VQM trap is enabled.
Quality Alerts for Voice Band Data Calls
Upon detection of a modem tone (modem, fax, or TTY), upspeed takes place. Depending on the upspeed method, the Codec may be modified by the gateway or the Call Agent. Further, the jitter and a number of other parameters are reconfigured to better handle the VBD mode. After upspeed occurs, the call statistics are reset and the VBD and its associated thresholds trigger and thresholds are downloaded to the DSP.
The reason for resetting the statistics immediately after the upspeed is to avoid using the statistics collected during the voice-phase. VBD connections are usually more sensitive to frame-loss than voice connections. Consequently, the VBD trigger information might cause an instant quality alert alarm due to lost frames accumulated during the voice phase. These (old) statistics have no bearing on the quality of the VBD connection and should be discarded.
If traps/events are generated at a high rate, the VXSM performance may be affected. Thus, trap and event throttling may be required. The rate of trap and event-handling is configurable. Commands are provided to configure the number of trap/event to be processed in a specific time interval. The detected traps/events are placed into queues and processed at the rate configured in the system. Excess traps that cannot be buffered in the queue are lost.
Note
Busy Line Verification and Operator Interruption
VXSM now supports Busy Line Verification and Operator Interruption (BLV/OI) through the MT package of the TGCP protocol under the control of a Call Agent. A caller can request that an operator check a called station to ascertain whether or not it is busy. This feature permits the operator to interrupt an ongoing call and relay a message to the called party.
AAL2 Trunking Operation—Non switching
VXSM support two methods for routing voice calls: 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.
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 (Figure 2-13).
Figure 2-13 Trunking Block Diagram
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 uses.
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.
Trunking Features—Non switching
Trunking operation supports the following features.
TDM Network Side
Interfaces
4 OC-3/STM-1 (channelized), 6 T3/E3, 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).
V.110 Traffic Handling
VXSM supports the detection and handling of V.110 traffic used for modem and fax devices on mobile networks. This feature is used in conjunction with the AAL2 Trunking function.
Upon detection of a V.110 bit pattern, VXSM provides a Clear Channel circuit for the duration of the V.110 (data) session, like modem upspeed operations, this function dynamically allocates more network bandwidth to the connection during the data session
Specifically this feature supports the situation where the Mobile Service Provider either doesn't control the data services or relies on IWF services from an external ISP. In this case V.110 traffic traverses the trunking network provided by the MGX.
During a V.110, VXSM employs a silence detector. If silence is detected for a period of 4 seconds or more, there is an automatic downspeed to the previously existing codec and associated parameters.
The VXSM V.110 feature supports:
•
•
•
•
•
•
Packet Network Side—Trunking
Codecs
G.711 (mu-law and A-law), G.729a, G.729ab, and G.clear (clear channel).
Voice Activity Detection
Uses a voice activity detection (VAD) algorithm, provides updates for the remote end on the background noise level so that the comfort noise generator can sound natural.
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 Sublayer 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 on custom profiles appear in Chapter 5.
Note
Multiprotocol Service Module Interoperability
For AAL2 trunking applications (MGX 8850 only), VXSM can now operate in conjunction with a Multiprotocol Service Module (MPSM) in which the MPSM provides the interface to the ATM network (Figure 2-14). In this way, the MPSM offers an alternative to the AXSM network interface. Interworking with the MPSM enables the MGX Voice Gateway to support IMA, ATM, and Frame Relay services with channelized capability on DS1 and DS0 levels.
The MPSM card must be configured for ATM context using the MPSM cnfclictx atm command. After the context is set to ATM, provisioning is performed with the upln, addport, and addcon command sequence. For more details, refer to the MPSM user documentation.
Figure 2-14 Media Gateway with MPSM Network Interface
Redundancy Support
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 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 one configuration.
1:1 Front Card Redundancy
In this scheme, the two VXSM front cards are installed in adjacent slots (slots 1 and 2, 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 (Figure 2-15). If a front card failure occurs, 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-15 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: 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 and 2, 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 through a local front card or through the redundant front card when redundant configuration is enabled or through 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-16.
Figure 2-16 1:1 Front and Back Card Redundancy
If a failure occurs in either the active front card or the active back card, the entire standby card set automatically switches over and becomes the active card set. The new data path after switchover is shown in Figure 2-17.
Figure 2-17 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, 4 OC-3 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:
•
•
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 support 1:1 APS line redundancy
1:1 APS architecture is similar to 1+1 APS architecture in 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.
