Downloads |
Table Of Contents
Information About Trunk Management
Congestion Monitoring and Management Features
T1/E1 Alarm Conditioning Feature
Call Admission Control Features
Analog Centralized Automatic Message Accounting E911 Trunk Feature
How to Configure Trunk Conditioning and Connections
Prerequisites for Configuring Trunk Conditioning and Connections
Configuring Trunk Conditioning
Configuring Trunk-Conditioning Signaling Attributes
Assigning Trunk-Conditioning Attributes to Network Dial Peers
Assigning Voice Classes to Voice Ports
Verifying Signaling Attributes and Trunk Conditioning
Configuring T1/E1 Alarm Conditioning
Assigning Alarm-Generation Parameters
Verifying Alarm-Generation Parameters
Configuring PLAR (Switched) Connections
Configuring Trunk and Tie-Line Connections
Configuring PLAR-OPX Connections
Configuration Examples for Trunk Conditioning and Connections
PLAR (Switched Calls) Configuration: Example
Permanent Trunks Configuration: Example
How to Configure Trunk Monitoring and Management
Configuring Analog Centralized Automatic Message Accounting E911 Trunk
Configuring CAMA Card for CAMA Signaling
Monitoring and Maintaining Analog CAMA-E911
Configuring Voice Ports to Support DID
Verifying DID Voice-Port Configuration
Configuring Call Admission Control
Configuring Call Admission Control for H.323 VoIP Gateways
Configuring MGCP VoIP Call Admission Control
Configuring Local and Advanced Voice Busyout
Configuring the Busyout Trigger Event
Configuring a Voice Port to Busy Out
Configuring a Voice Port to Monitor the Link to a Remote Interface
Configuring a Busyout-Monitoring Voice Class
Configuring a Graceful Busyout
Configuring Busyout Monitor Gatekeeper
Configuring Fallback to Alternate Dial Peers
Configuring Destination Monitoring without Fallback to Alternate Dial Peers
Configuring Call-Fallback Cache Parameters
Configuring Call-Fallback Jitter-Probe Parameters
Configuring Call-Fallback Probe-Timeout and Weight Parameters
Configuring Call-Fallback Threshold Parameters
Configuring Call-Fallback Wait-Timeout
Configuring VoIP Alternate Path Fallback SNMP Trap
Configuring Call-Fallback Map Parameters
Verifying PSTN Fallback Configuration
Monitoring and Maintaining PSTN Fallback
Configuration Examples for Trunk Monitoring and Management
Analog Centralized Automatic Message Accounting E911 Trunk: Examples
Local Voice Busyout Configuration: Examples
Alarm Trigger for Busyout of Voice Ports Configuration: Example
Call Admission Control: Examples
Call Admission Control for H.323 VoIP Gateways: Examples
MGCP VoIP Call Admission Control: Examples
Trunk-Management Features
This document describes how to condition and connect trunks and how to configure the following trunk-management features:
•
Analog Centralized Automatic Message Accounting E911 Trunk
•
•
–
–
•
–
–
•
•
•
Feature History for Analog Centralized Automatic Message Accounting E911 Trunk
12.2(11)T
This feature was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series.
Feature History for Analog DID (Direct Inward Dial)
12.1(5)XM
This feature was introduced on the Cisco 2600 series and Cisco 3600 series.
12.2(2)T
This feature was integrated into this release.
Feature History for Busyout Monitor
Feature History for CAC Features (Call Admission Control for H.323 VoIP Gateways and MGCP VoIP Call Admission Control
12.1(5)XM
This feature was introduced on the Cisco AS5300, Cisco AS5400, and Cisco AS5800.
12.2(2)T
This feature was integrated into this release.
Feature History for Local and Advanced Voice Busyout
Feature History for PSTN Fallback
Feature History for T1/E1 Alarm Conditioning
12.1(3)T
This feature was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco MC3810.
Feature History for Trunk Conditioning
12.0(3)XG
This feature was introduced on the Cisco MC3810.
12.0(4)T
This feature was integrated into this release.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and CatOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn.
Note
Contents
•
•
•
•
•
Information About Trunk Management
A trunk is a communication line between two switching systems—in this case, the switching equipment in a central office (CO) and a PBX. It is a physical and logical point-to-point connection with a permanent wire over which network traffic travels. A backbone is composed of a number of trunks.
VoIP simulates trunk connections between PBXs that are connected to Cisco routers or access servers on each side of the network.
In Figure 1, two PBXs connect to a router using a simulated trunk and a recEive and transMit (E&M) voice port. In this case, a permanent, nonswitched connection transparently connects the two PBXs.
Figure 1 Simulated Trunk Connection
Simulated Lines and Trunks
Simulated lines and trunks enable a telephone user at one location to dial an access code to access a PBX at another location. The user hears a second dial tone from the remote PBX. You can configure two types of simulated connection—switched and permanent—for both analog and digital systems. The connection command creates these connections.
The connection trunk command creates a permanent call that is connected as soon as the routers on each end are booted (see Figure 2). Permanent calls pass limited telephony signaling and operate without collecting digits or requiring changes to the overall dial plan.
Figure 2 Connection Trunk Configuration
The calls simulate a permanent tie line between two PBXs. Both ends must be configured and have compatible voice-port signaling that is either E&M to E&M or foreign exchange office (FXO) to foreign exchange station (FXS). The signaling cannot be FXO to ground-start.
When a switched call is configured (see Figure 3), the user can make a call without dialing any digits. Telephony signaling, such as hookflash, is not passed. If the remote telephone does not answer and digits from an attached telephony device are not collected, the call does not roll over to voice mail.
Figure 3 Connection Private-Line Auto Ringback (PLAR) Configuration
The switched-call configuration works with any type of voice port (E&M, FXO, or FXS) and without any effect on an existing dial plan. It is commonly used to connect PBXs in which the remote devices appear to be physical extensions. The PBX, rather than the router, provides dial tone to the extensions.
The connection tie-line command creates a switched call between two stations or PBXs, and this call bypasses the switch. The connection plar-opx command creates a call that is similar to a switched call. The connection does not take place between the PBX and the local router until the far-end FXS device answers. This enables the PBX to provide centralized voice mail or attendant services when the remote device does not answer.
Trunk Conditioning
The Trunk Conditioning feature enables you to create a voice class, configure specific signaling attributes to the voice class, and then map the attributes in the voice class to either a Voice over Frame Relay, Voice over ATM, or a Voice over HDLC dial peer. Using the voice class, you can define the keepalive-signaling packet interval and the signal pattern (ABCD) bit pattern for Cisco-trunk (private-line) calls.
Trunk-conditioning signaling attributes apply to permanent point-to-point voice connections (private lines and tie lines) that you create using the connection trunk command.
Trunk conditioning enables control over Cisco private-line calls that are sent over Frame Relay or ATM networks. When private-line or tie-line calls are sent between two PBXs, fault indications are sent to the sending PBX. If the call fails, the PBX can select an alternate path to route the calls. Selecting an alternate path applies to analog connections or digital T1/E1 using channel-associated signaling (CAS) ABCD signaling. It does not apply to common-channel signaling (CCS).
When T1/E1 CAS is carried in transparent pass-through mode for arbitrary, unknown, or unsupported CAS protocols, you must define on-hook/idle patterns so that the digital signal processor (DSP) code can sense the idle call state and shut off the flow of voice packets when no active call is in progress. This mode provides an additional idle bandwidth-saving mechanism for those cases when Voice Activity Detection (VAD) is not desired.
Note
Congestion Monitoring and Management Features
Congestion monitoring of permanent and switched calls is performed with the following features:
•
•
•
These features provides the following capabilities:
•
•
•
•
•
An OOS condition can be signaled using an ABCD bit pattern that is different from the busy or seized state. The difference enables the PBX to differentiate between OOS and congestion.
T1/E1 Alarm Conditioning Feature
The T1/E1 Alarm Conditioning feature provides status monitoring on T1/E1 PBX voice interfaces for simulated lines and trunks that you create using the connection command. It supports operation with CAS but not with CCS.
A T1/E1 alarm can be triggered by events detected through the monitoring of a specified set of voice ports within a T1/E1 trunk. A monitored set includes a defined voice port that has a specified DS0 group or groups and configured for one of the following:
•
•
When all monitored voice ports on a T1/E1 trunk are OOS (PVCs are OOS and SVCs are busied out), a T1/E1 alarm indication signal (AIS) is generated on the T1/E1 trunk that connects to the PBX or PSTN.
Note
PSTN Fallback Feature
The PSTN Fallback feature monitors congestion in the IP network and redirects calls to the PSTN or rejects calls based on network congestion. You define congestion thresholds based on your configured network. This feature can reroute calls to an alternate IP destination or, if the IP network is found unsuitable for voice traffic during periods of network congestion, to the PSTN. This enables a service provider to give a reasonable guarantee about conversation quality to its VoIP users at the time of call admission.
Note
Note
PSTN fallback includes the following capabilities:
•
–
–
•
•
The fallback subsystem has a network-traffic cache that maintains the ICPIF or delay/loss values for various destinations. The subsystem helps performance, because new calls to a well-known destination do not have to wait on a probe. The value is usually cached from a previous call.
Once the ICPIF or delay/loss values are calculated and stored, they remain until the cache ages out or overflows. Until a value ages out, probes are sent periodically for that destination. The time interval is user configurable.
The following is an example of the PSTN fallback sequence. In the example, call fallback active is enabled and an ICPIF threshold is defined. Call control would be similar if loss and delay thresholds were defined.
1.
Note
2.
Note
3.
If the timeout threshold is set and the router has not received calls for a particular destination after the threshold expires, the router removes that destination's traffic information from the cache.
Caution
Calculated Impairment Planning Factor
ICPIF calculates an impairment factor for every piece of equipment along the voice path and adds the values to get the total impairment. The ITU assigns the different types of impairments, such as noise, delay, and echo. The threshold is based on ICPIF, which is derived as part of ITU G.113 including the following: G.729, G.711, G.723, G.726, GSM, and G.728.
The ICPIF handling has been introduced for compatibility with H.323. Part of ICPIF includes a concept of Total Impairment Value that is a function of loss of packets, delay of packets, and codecs used based on the round-trip reports from SAA.
Service Assurance Agent
SAA is a network-congestion analysis mechanism. SAA provides delay, jitter, and packet-loss information for configured IP addresses. SAA is based on a client-server protocol defined on UDP. It has an Message Digest 5 (MD5), which is a message authentication algorithm in SNMP v.2. MD5 verifies the integrity of the communication, authenticates the origin, and checks for timeliness.
SAA uses the UDP port (port 1976) for sending the SAA control message to the terminating gateway. SAA probe packets go out on randomly selected ports from the top end of the audio UDP port range (16384 to 32767).
The port pair (RTP and Real-Time Transport Control Protocol [RTCP] port) is selected, and by default SAA for call fallback uses the RTCP port (odd number) to avoid going into the priority queue, if enabled. If fallback is configured to use the priority queue, the RTP port (even number) is selected. The audio UDP port range must be included in the priority queue for fallback priority queueing to work.
Busyout Features
This section describes the following busyout features:
•
Local Voice Busyout Feature
The Local Voice Busyout feature busies out trunks that are assigned to PVCs so that the PBX does not seize the circuit. It enables the PBX to route a call based on the actual availability of trunks. Local voice busyout enables the following:
•
•
When ports are marked busy, a call is forced back to the originating equipment (typically a PBX) that reroutes the call over an alternate path. This action ensures that a caller does not experience "dead air" resulting from a connection that never terminates.
The feature provides a way to busy out a voice port if a monitored network interface changes state. When a monitored interface changes to a specified state—to OOS or in-service—the voice port presents a seized/busyout condition to the attached PBX or other customer premises equipment (CPE). The PBX or other CPE can then attempt to select an alternate route.
This feature differs from busy-back. Busy-back refers to the signal sent from within the network to the calling party that indicates a busy (or congested) state anywhere along the route, up to and including the condition of the called party.
Note
Advanced Voice Busyout Feature
The Advanced Voice Busyout feature adds the following functionality to the local voice busyout feature:
•
•
This feature enables you to do the following:
•
•
SAA-probe monitoring of remote interfaces is intended for use with VoIP networks, although it can also be used with Voice over Frame Relay (VoFR) and Voice over ATM (VoATM) networks.
Busyout Monitor Feature
The Busyout Monitor feature is one aspect of call admission control that uses a data network and the PSTN to provide the best possible quality and cost savings for VoIP calls. It also provides the following:
•
•
•
Call Admission Control Features
This section describes the following CAC features:
•
•
Call Admission Control for H.323 VoIP Gateways Feature
This feature provides the ability to support resource-based CAC processes. These resources include system resources such as CPU, memory, and call volume, and interface resources such as call volume.
If system resources are not available to admit the call, the result is either a system denial (which busies out all T1 or E1) or per-call denial (which disconnects, hairpins, or plays, a message or tone). If the interface-based resource is not available to admit the call, the call is dropped from the session protocol (such as H.323).
PSTN Fallback offers CAC based on congestion thresholds in H.323 networks.
Note
User-Selected CAC Commands
The feature allows you to configure thresholds for local resources and memory and CPU resources.
Note
With the call threshold command, you can configure two thresholds, high and low, for each resource. Call treatment is triggered when the current value of a resource exceeds the configured high. The call treatment remains in effect until the current resource value falls below the configured low. Having high and low thresholds prevents call admission flapping and provides hysteresis in call admission decision making.
With the call spike command, you can configure the limit for incoming calls during a specified time period. A call spike is the term for when a large number of incoming calls arrive from the PSTN in a very short period of time (for example, 100 incoming calls in 10 ms).
With the call treatment command, you can select how the call should be treated when local resources are not available to handle the call. For example, when the current resource value for any one of the configured triggers for call threshold has exceeded the configured threshold, the call treatment choices are as follows:
•
•
•
Resource-Unavailable Signaling
The Resource Unavailable Signaling feature supports the autobusyout feature where channels are busied out when local resources are not available to handle the call. Autobusyout is supported on both CAS and PRI channels:
•
•
MGCP VoIP Call Admission Control Feature
The MGCP VoIP Call Admission Control feature enables certain Cisco CAC capabilities on VoIP networks that are managed by Media Gateway Control Protocol (MGCP) call agents. These capabilities permit the gateway to identify and gracefully refuse calls that are susceptible to poor voice quality.
Poor voice quality on an MGCP voice network can result from transmission artifacts such as echo, from the use of low quality codecs, from network congestion and delay, or from overloaded gateways. The first two causes can be overcome by using echo cancellation and better codec selection. The last two causes are addressed by MGCP VoIP CAC.
Before the release of MGCP VoIP CAC, MGCP voice calls were often established regardless of the availability of resources for those calls in the gateway and the network. MGCP VoIP CAC ensures resource availability by disallowing calls when gateway and network resources are below configured thresholds and by reserving guaranteed bandwidth throughout the network for each completed call.
MGCP VoIP CAC has three components for improving voice quality and reliability (see Table 48).
Table 48 MGCP VoIP CAC Components
System Resource Check (SRC) CAC
Evaluates memory and call resources local to the gateway
•
•
Resource Reservation Protocol (RSVP) CAC
Surveys bandwidth availability on the network
•
•
Cisco Service Assurance Agent (SA Agent)1 CAC
Appraises network congestion conditions on the network
•
1 SA Agent was called Response Time Reporter (RTR) in earlier Cisco IOS software releases.
If all three CAC types are configured on a gateway, the gateway checks resources in this order: SRC CAC, then RSVP CAC, then SA Agent CAC. If any resource check fails, the call fails and no further checks are performed. When the call fails, the gateway refuses to accept it.
MGCP VoIP CAC supports several types of calls, depending on platform (Table 49).
Fax/modem pass-through and fax/modem relay are not supported.
Note
•
SRC CAC
When a call agent attempts to set up or modify a call, MGCP SRC CAC measures available local resources on the gateway and compares them to the configured thresholds for those resources. If one or more resources are beyond their thresholds, SRC CAC notifies the call agent of the results and refuses the call. If resources are within bounds and a call is subsequently established, local resources are guaranteed for the duration of the call.
SRC CAC checks these gateway thresholds, as configured by the user:
•
•
•
If several types of thresholds are configured on the gateway, the gateway checks them in sequence to determine if sufficient resources are available to continue setting up the call.
Note
When the gateway sends an unavailable condition to the call agent, the call agent takes responsibility for the type of treatment to attach to the call attempt. The call agent may choose to handle such situations by rerouting the call, playing an announcement that the call cannot be completed, playing special tones, or sending the call back to take a different path. Once resources become available again, the gateway resumes the acceptance of new calls.
RSVP CAC
MGCP RSVP CAC determines if sufficient bandwidth exists across the IP network to accept a call and refuses the call if end-to-end bandwidth is not available.
To accept a call, MGCP RSVP CAC checks for and reserves the network bandwidth between the originating gateway and the terminating gateway before attempting to complete the call. If sufficient bandwidth is not available or cannot be reserved, the gateway alerts the call agent to this condition and the call agent applies a previously configured treatment to the refused call (plays an announcement or special tones, or sends the call back to take a different path).
RSVP is an out-of-band, end-to-end signaling protocol that requests a certain amount of bandwidth and latency with each network hop that supports RSVP. If a network node (router) does not support RSVP, RSVP moves on to the next hop. A network node has the option to approve or deny the reservation on the basis of the load of the interface to which the service is requested.
A voice call triggers two RSVP reservations because the reservation and admission control mechanisms provided by RSVP are unidirectional. Each voice gateway is responsible for initiating and maintaining one reservation toward the other voice gateway. RSVP CAC for a VoIP call fails if at least one of the reservations fails.
Cisco VoIP CAC applications use RSVP to limit the accepted voice load on the IP network and guarantee the QoS levels of calls. RSVP CAC synchronizes RSVP signaling with the call setup signaling protocol (MGCP, in this case) to ensure that the bandwidth reservation is established in both directions before a call moves to the alerting phase (ringing). This synchronization ensures that the called-party phone rings only after the resources for the call have been reserved. Using RSVP-based admission control, VoIP applications can reserve network bandwidth and react appropriately if bandwidth reservation fails.
SA Agent CAC
Cisco SAA is a Cisco IOS feature that allows users to monitor network performance and congestion between a Cisco router and a remote device, which can be another Cisco router, an IP host, or a multiple virtual storage (MVS) host. Performance can be measured for real-world scenarios through the configuration of SA Agent operations that are executed periodically. Performance metrics include round-trip response time, connect time, packet loss, application performance, and interpacket delay variance (jitter). The SA Agent feature allows users to receive notifications and perform troubleshooting and problem analysis on the basis of the statistics collected by the SA Agent.
SA Agent probes traverse the network to a given IP destination and measure the loss and delay characteristics of the network along the path traveled. These values are returned to the outgoing gateway to use in making a decision on the condition of the network and its ability to carry a voice call. SA Agent probes do not provide any bandwidth information, either configured or available. However, if bandwidth across a link anywhere in the path that the voice call will follow is oversubscribed, it is reasonable to assume that the packet delay and loss values returned by the probe will indeed reflect this condition, even if indirectly. The SA Agent protocol is a client/server protocol defined in User Datagram Protocol (UDP). The client builds and sends the probe, and the server (previously the RTR Responder) returns the probe to the sender.
SA Agent probe delay and loss information is used in calculating a single value that can be used as a gauge of network impairment and as a threshold for CAC decisions.
Analog DID Feature
The Analog Direct Inward Dialing (DID) feature is a service offered by telephone companies that enables callers to dial directly to an extension on a PBX without the assistance of an operator or automated call attendant. It makes use of DID trunks, which forward only the last three to five digits of a phone number to the PBX. If, for example, a company has a PBX with extensions 555-1000 to 555-1999, and a caller dials 555-1234, the local CO would forward 234 to the PBX. The PBX would then ring extension 234. This entire process is transparent to the caller.
When this feature is configured, a voice-enabled router equipped with an analog DID interface can receive calls from a DID trunk and connect them to the appropriate extensions. The DID state machine is identical to the E&M state machine and uses one of the following signaling types:
•
•
•
Figure 4 shows a hypothetical topology where a user connected to the PSTN (Caller A) dials various numbers and is connected to the appropriate extensions on a PBX.
Figure 4 DID Support
555-1234
234
User C
555-1345
345
User D
555-1456
456
User B
555-1678
678
No dial-peer match found; fast busy tone is played.
Note
Analog Centralized Automatic Message Accounting E911 Trunk Feature
Because E911 calls require special routing, the North American emergency E911 phone system is built largely outside of the normal PSTN on which common voice traffic rides. Calls to emergency services are routed based on the calling number, not the called number. The calling number is checked against a database of emergency service providers that cross-references the providers for the caller's particular location. The call is then routed to the proper public-service answering point (PSAP), which, in turn, dispatches those services for the caller's location.
During setup of a call to E911, before the audio channel is connected, the calling number is sent to each switching point (known as a Selective Router [SR]) via an old telephony protocol known as CAMA. CAMA was originally designed as a protocol for long-distance billing, because it provides for carrying both calling and called number using in-band signaling. CAMA allows the telephone system to send a station identification number to the PSAP via multifrequency (MF) signaling through the telephone company's E911 equipment. CAMA trunks are used in 80 percent of E911 networks.
The calling number is needed at the PSAP for two reasons:
•
•
Figure 5 illustrates the topography in existing E911 networks. Figure 6 illustrates an E911 network using the VIC-2CAMA card with Cisco 2600 series or Cisco 3600 series routers.
Figure 5 Existing E911 Networks
Figure 6 Analog CAMA E911 Networks
How to Configure Trunk Conditioning and Connections
This section contains the following procedures:
•
•
•
•
Prerequisites for Configuring Trunk Conditioning and Connections
Note
•
–
–
–
–
Configuring Trunk Conditioning
This section contains the following procedures:
•
•
•
•
Configuring Trunk-Conditioning Signaling Attributes
Different trunk-conditioning signaling attributes may be required to match the characteristics of the different PBXs to which the router connects. For this reason, you configure these attributes by creating a voice class for each set of attributes required. You then configure trunk-conditioning attributes for each voice class and assign the voice class to one or more dial peers. You must configure a voice class and assign it to at least one dial peer before trunk-conditioning signaling attributes take effect.
Note
To configure trunk-conditioning signaling attributes, use the following commands.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Assigning Trunk-Conditioning Attributes to Network Dial Peers
After you create a voice class, you must apply it to the dial-peer configuration. You can assign trunk-conditioning attributes to VoIP, VoFR, or VoATM dial peers, but not to POTS dial peers.
Note
To apply trunk-conditioning signaling attributes to a network dial peer, use the following commands.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Assigning Voice Classes to Voice Ports
To assign a voice class to a voice port, use the following commands.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying Signaling Attributes and Trunk Conditioning
Step 1
Use this command to verify signaling attributes (timing parameters).
The following is sample output for voice-port 1/5 on a Cisco MC3810.
Router# show voice trunk-conditioning signaling 1/51/5 :TX INFO :slow-mode seq#= 25, sig pkt cnt= 42, last-ABCD=0000hardware-state ACTIVE signal type is NorthamericanCASsignal path is OPEN0000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 0000 0000 0000 0000 0000 0000 0000 0000RX INFO :slow-mode, sig pkt cnt= 37missing = 0, out of seq = 0, very late = 0playout depth = 0 (ms), refill count = 1prev-seq#= 25, last-ABCD=0000trunk_down_timer = 4212 (ms), idle timer = 0 (sec),tx_oos_timer = 0 (sec), rx_ais_duration = 0 (ms)forced playout signal pattern = NONEsignaling playout history0000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 0000 0000 0000 0000 0000 0000 0000 0000The following is sample summary output for voice ports on a Cisco MC3810:
Router# show voice trunk-conditioning signaling summary1/1 is shutdown1/4 is shutdown1/5 :TX INFO :slow-mode seq#= 25, sig pkt cnt= 40, last-ABCD=0000hardware-state ACTIVE signal type is NorthamericanCAS signal path is OPENRX INFO :slow-mode, sig pkt cnt= 36, prev-seq#= 25, last-ABCD=0000Step 2
Use this command to determine the status of trunk supervision and configuration parameters.
The following is sample output for a Cisco MC3810 multiservice concentrator.
Router# show voice trunk-conditioning supervisory 1/51/5 : state : TRUNK_SC_CONNECT, voice : on, signal : on, slavestatus: trunk connectedsequence oos : idle and oospattern :rx_idle = 0x0 rx_oos = 0xF tx_oos = 0xFtiming : idle = 0, restart = 0, standby = 0, timeout = 40supp_all = 50, supp_voice = 0, keep_alive = 5timer: oos_ais_timer = 0, timer = 0Step 3
Use this command to show summary call data.
The following is sample output sample is for voice port 1/5 on a Cisco MC3810:
Router# show voice call summaryPORT CODEC VAD VTSP STATE VPM STATE========= ======== === ===================== ========================1/1 *shutdown*1/2 - - - FXSLS_ONHOOK1/3 - - - FXSLS_ONHOOK1/4 *shutdown*1/5 g729r8 n S_CONNECT S_TRUNKED1/6 - - - EM_ONHOOKStep 4
Use this command to verify signaling and timing parameters. The trunks do not have to be connected and active.
The following is sample output for voice-ports 0:0, 0:1, and 0:2 on a Cisco MC3810.
Router# show running-configurationBuilding configuration...Current configuration:...voice class permanent 100signal timing idle suppress-voice 2000signal timing oos restart 1000...voice-port 0:0voice-class permanent 100compand-type a-law!voice-port 0:1voice-class permanent 100compand-type a-law!voice-port 0:2voice-class permanent 100compand-type a-law...
Configuring T1/E1 Alarm Conditioning
This section contains the following procedures:
•
•
You can configure a network to monitor any combination of DS0 groups on a T1 or E1 trunk. An alarm is triggered only if all of the monitored DS0 groups on a T1 or E1 trunk are OOS. If one monitored DS0 group is in service, no alarm is triggered. DS0 groups can be either of the following types:
•
