DSP Voice Quality Metrics Guide
Available Languages
Table Of Contents
DSP Voice Quality Metrics for MGCP
Prerequisites for DSP Voice Quality Metrics for MGCP
Restrictions for DSP Voice Quality Metrics for MGCP
Information About DSP Voice Quality Metrics for MGCP
Voice-Quality Statistics in DLCX Messages
Troubleshooting Using DSP Voice Quality Metrics
DSP Voice Quality Metrics Descriptions
DSP Voice Quality Metrics Summary
DSP Voice Quality Metrics Details
DSP/TX: Transmission Statistics
DSP/PD: Playout Delay (Jitter Buffer)
DSP/PE: Playout Error Statistics
DSP/EC : Endpoint Configuration
DDSP/KF : MOS/K-Factor Statistics
DSP/CS: Concealment Statistics
DSP/UC: User Concealment Statistics
Statistics Measured by the IP SLAs RTP-Based VoIP Operation
How to Configure DSP Voice-Quality Statistics in DLCX Messages
Configuring DSP Voice-Quality Statistics in DLCX Messages
Verifying DSP Voice-Quality Statistics in DLCX Messages
Troubleshooting DSP Voice-Quality Statistics in DLCX Messages
Feature Information for DSP Voice Quality Metrics for MGCP
DSP Voice Quality Metrics for MGCP
First Published: October 6, 2003Last Updated: May 7, 2007Digital signal processor (DSP) voice quality metrics improve your ability to monitor, analyze, and ultimately meet your quality of service (QoS) objectives for your network.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for DSP Voice Quality Metrics for MGCP" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for DSP Voice Quality Metrics for MGCP
•
•
•
•
•
Prerequisites for DSP Voice Quality Metrics for MGCP
•
•
Restrictions for DSP Voice Quality Metrics for MGCP
Note
Information About DSP Voice Quality Metrics for MGCP
Metrics for DSP performance on Media Gateway Control Protocol (MGCP) networks are useful for maintaining service, tracking quality issues, and troubleshooting problems. Voice quality metrics on the DSP can help you to evaluate the performance of your VoIP network.DSP metrics can be used to do the following:
•
•
•
Voice quality metrics for DSPs on MGCP networks can be gathered through the following methods:
•
Voice-Quality Statistics in DLCX Messages
The DSP statistics gathering function on Cisco media gateways provides a way to trace an MGCP call between a Cisco gatekeeper and the Cisco IOS gateway by including the MGCP call ID and the DS0 and DSP channel ID in call-active and call-history records. These DSP statistics are sent as part of the MGCP Delete Connection (DLCX) message. By correlating an MGCP call on the Cisco gatekeeper with the call record on the gateway, additional statistics from the DSP can be understood and debugged for problems related to voice quality. This feature also provides a method to limit the amount of statistics sent to the Cisco gatekeeper to control the impact to call processing performance. The Support of DSP Voice Quality Statistics feature gathers the DSP voice quality statistics on the Cisco gatekeeper.
For more information on the DSP voice quality statistics that can be gathered on Cisco media gateways and how to configure the priority settings on the media gateway, see the DSP Voice Quality Statistics in DLCX Messages feature module.
Parameter Priorities
Running voice quality statistics can impact the router performance. To reduce performance issues, the data can be provisioned by priority.
•
•
Call Detail Records
Call Detail Records (CDRs) for voice calls can be output in RADIUS VSAs or system log (syslog) messages. A RADIUS server can be configured to collect accounting data during the accounting process for each call leg created on the Cisco voice gateway. An integration partner can use this information for post-processing activities, such as generating billing records and network analysis.
IP Service Level Agreements
Cisco IOS IP Service Level Agreements (SLAs) allows you to analyze IP service levels for IP applications and services, to increase productivity, to lower operational costs, and to reduce the frequency of network outages. Cisco IOS IP SLAs uses active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance. Using Cisco IOS IP SLAs, service provider customers can measure and provide service level agreements, and enterprise customers can verify service levels, verify outsourced service level agreements, and understand network performance. Cisco IOS IP SLAs can perform network assessments, verify quality of service (QOS), ease the deployment of new services, and assist administrators with network troubleshooting. You can Cisco IOS IP SLAs using the Cisco IOS command-line interface (CLI) or Simple Network Management Protocol (SNMP) through the Cisco Round-Trip Time Monitor (RTTMON) and SYSLOG Management Information Bases (MIBs).
You can find detailed information about Cisco IP SLAs in the following documents:
•
•
•
Syslog
Syslog is a method to collect messages from devices to a server running a syslog daemon. Logging to a central syslog server helps in aggregation of logs and alerts. Cisco devices can send their log messages to a UNIX-style SYSLOG service that simply accepts messages and stores them in files or prints them according to a simple configuration file. This form of logging is very useful for Cisco devices because it can provide protected long-term storage for logs. This is useful both in routine troubleshooting and in incident handling.
Troubleshooting Using DSP Voice Quality Metrics
The Cisco call agent can capture voice quality statistics sent from MGCP-controlled media gateways and can propagate the statistics into call detail records (CDRs) at the end of each call. Cisco gateways send voice quality statistics to the Cisco call agent.
Most voice quality statistics are available from the DSP and are controlled with RTP Control Protocol (RTCP) report interval statistics polling. The mean and maximum values are calculated by Cisco IOS software-based polling. This results in an additional CPU load for each call, which can be controlled by the configured polling interval using the ip rtcp report interval commands.
The playout delay, playout error, and DSP receive and transmit statistics are automatically polled periodically. You can add polling for the voice quality statistics, level, and error parameters. For logging the voice quality statistics using Syslog, the existing VoIP gateway accounting has been extended. Use the ip rtcp report interval command reference for more information about statistics polling.
DSP voice quality metrics can be used to troubleshoot the following problems:
•
For additional DSP troubleshooting information, see the "Checking the Digital Signal Processors" section in the Cisco IOS Voice Troubleshooting and Monitoring Guide.
Troubleshooting One Way Audio
Troubleshoot one-way audio problems by using the following DSP voice quality metrics:
•
•
•
Troubleshooting Echo
Troubleshoot echo problems by using the following DSP voice quality metrics:
•
•
For additional echo troubleshooting information, see the "Troubleshooting Quality of Service for VoIP" section in the Cisco IOS Voice Troubleshooting and Monitoring Guide.
Troubleshooting Voice Levels
Use the level (DSP/LE) statistics to check voice levels. As much as possible, try to achieve a uniform input decibel level to the packet voice network. Doing so eliminates or at least reduces any voice distortion because of incorrect input and output decibel levels. Adjustments to levels might be required by the type of equipment connected to the network or by local country-specific conditions.
For additional voice level troubleshooting information, see the "Troubleshooting Quality of Service for VoIP" section in the Cisco IOS Voice Troubleshooting and Monitoring Guide.
DSP Voice Quality Metrics Descriptions
DSP voice quality metrics are described in the following sections:
•
•
DSP Support
DSP voice quality metrics vary by DSP technology. Use Table 1 to determine which DSP metrics your platform supports.
DSP Voice Quality Metrics Summary
Table 2 contains a summary of all supported DSP voice quality metrics:
DSP Voice Quality Metrics Details
This section contains detailed descriptions of the DSP voice quality metrics parameters:
•
•
•
•
•
•
•
DSP/TX: Transmission Statistics
Transmission statistics can show if a router is effectively transmitting packets. The statistics show transmissions of outgoing voice, signaling, and comfort noise packets. In addition, the lengths of both the overall transmission and the voice call are tracked.
The following example shows the parameters for transmission statistics on the DSP.
DSP/TX: PK=65, SG=65, NS=65, DU=95, VO=80
PK
Transmission (TX) packets
SG
Signaling packets
NS
Noise packets
DU
Transmission duration
VO
Voice transmission duration
DSP/RX: Receive Statistics
Receive statistics can show if a router is receiving packets properly. The statistics show the receipt of incoming voice, signaling, and comfort noise packets. In addition, the lengths of both the overall call and the voice portion are tracked. Errors such as bad sequence or protocol, or late packets are also shown.
The following example shows the parameters for receive statistics on the DSP.
DSP/RX: PK=65, SG=65, NS=65, RX=95, VO=80, BS=0, BP=0, LP=0
PK
Transmission (TX) packets
SG
Signaling packets
NS
Noise packets
RX
Receive duration
VO
Voice receive duration
BS
Bad sequence
BP
Bad protocol
LP
Late packets
DSP/PD: Playout Delay (Jitter Buffer)
Variable-length delays (also known as jitter) can cause a conversation to break and become unintelligible. Jitter is not usually a problem with PSTN calls because the bandwidth of calls is fixed and each call has a dedicated circuit for the duration of the call. However, in VoIP networks, data traffic might be bursty, and jitter from the packet network can become an issue. Packets from the same conversation can arrive at different interpacket intervals, especially during times of network congestion, which can disrupt the steady, even delivery needed for voice calls.
The adaptive jitter buffer adjusts the jitter buffer size and amount of playout delay during a call based on current network conditions An adaptive jitter buffer is a mechanism that seeks to make an intelligent trade-off between effective frame loss (leading to audible distortions or interruptions in speech) and overall delay (leading to difficulty in maintaining a smooth conversational rhythm).
The imposition of a small delay at the receiver (playout delay) can be used to `soak up' jitter in the received packet stream. You must impose a delay sufficient to compensate for the jitter, minimizing the chance of an audible frame drop, but still short enough to minimize the adverse effects of delay on the conversation.
In fixed mode, the playout delay of the de-jitter buffer is a fixed or constant quantity regardless of the jitter observed on the connection.
The following example shows the parameters for playout delay statistics on the DSP.
DSP/PD: CU=65, MI=65, MA=65, CO=-1825458605, IJ=0
DSP/PE: Playout Error Statistics
Playout error statistics can track concealment based on predictive or interpolative algorithms. Silence concealment is shown. Additional error statistics, such as retroactive memory updates, buffer overflow, and endpoint errors are also provided.
The following example shows the parameters for playout error statistics on the DSP.
DSP/PE: PC=65, IC=65, SC=65, RM=95, BO=80, EE=0
DSP/LE: Level Statistics
Level statistics show various volume, pulse, noise, and echo measurements for incoming and outgoing calls. Tranmit and receive activity are also tracked.
The following example shows the parameters for level statistics on the DSP.
DSP/LE: TP=65, TX=65, RP=65, RM=95, BN=80, ER=0, AC=0, TA=0, RA=0
DSP/ER: Error Statistics
DSP error statistics track errors in dropped and control packets for both incoming and outgoing calls.
The following example shows the parameters for receive statistics on the DSP.
DSP/ER: RD=65, TD=65, RC=65, TC=95
RD
Receive dropped
TD
Transmission dropped
RC
Receive control
TC
Transmission control
DSP/IC: ICPIF
The ICPIF statistic tracks the calculated planning impairment factor. This measure is for predicting a user's perceptions of voice quality. This measure has mostly been superceded by the R-factor measurement.
The following example shows the parameters for ICPIF statistics on the DSP.
DSP/IC: IC=65
DSP/EC : Endpoint Configuration
Endpoint configuration and provisioning statistics are settings controlled by the user rather than performance metrics. These statistics represent the effective settings of the endpoint as reported by the DSP, they are useful for debug and logging purposes because they capture the state of the endpoint.
The following example shows the parameters for the configuration of the VoIP endpoint:
DSP/EC: CI=1, FM=640, FP=2, VS=0, GT=1.0000, GR=1.0000, JD=2, JN=60, JM=40, JX=200
DDSP/KF : MOS/K-Factor Statistics
K-factor is an endpoint mean opinion score (MOS) estimation algorithm defined in ITU standard P.VTQ. This alogrithm is a general estimator and is used to estimate the mean value of a perceptual evaluation of speech quality (PESQ) population for a specific impairment pattern.
ITU standard P.862 defines and describes the PESQ as an objective method for end-to-end speech quality assessment of narrow band telephone networks and speech codecs.
MOS is a term that relates to the output of a well designed listening experiment. All MOS experiments use a five point PESQ scale as defined in ITU standard P.862.1. The MOS estimate is a number that is inversely proportional to frame loss density. Clarity decreases as more frames are lost or discarded at the receiving end.
K-factor represents the following:
•
•
•
•
K-factor and other MOS estimators are considered to be secondary or derived statistics because they warn a network operator of frame loss only after the problem becomes significant. Packet counts, concealment ratios, and concealment second counters are primary statistics because they alert the network operator before network impairment has an audible impact or is visible through MOS.
The following example shows the parameters for the k-factor configuration:
DSP/KF: KF=4.4001, AV=4.4001, MI=4.4001, BS=4.4001, NB=0, FL=0, NW=15, VR=99.88
DSP/CS: Concealment Statistics
The concealment statistics metrics are measures of effective packet/frame loss or concealment events. Concealment measures the overall impact of network impairments of voice quality. Packets can be late, lost, or corrupted for many reasons. Even without packet loss, a small difference in the clock frequency of the sending and terminating devices can lead to jitter buffer over- or underflows at the receiver. The result of this loss is the same: the audio decoder asks the jitter buffer for a new frame, and the jitter buffer is unable to oblige. The codec is momentarily `starved,' and it must generate a fake or `spoofed' or `concealment' frame of output audio. This potentially audible occurance is the result of these various network- and device-related impairments.
The following example shows the parameters for concealment:
DSP/CS: CR=0.0000, AV=0.0000, MX=0.0000, CT=0l, TT=123000l, CS=0, SC=0, TS=50, DC=0
DSP/RF: R-Factor Statistics
The R-factor helps in planning voice transmission. In ITU standards G.107 and G.113, the R-factor is defined as:
R = Ro - Is - Id - Ie-eff + A
–
–
–
–
–
The following example shows the parameters for the R-factor:
DSP/RF: ML=0.0000, MC=0, R1=0, R2=0, IF=0, ID=1, IE=0, BL=5, R0=94
DSP/UC: User Concealment Statistics
The user concealment statistics show the length and threshold level of the concealment.
The following example shows the parameters for user concealment
DSP/UC: U1=0, U2=0, T1=32, T2=46:
U1
User concealment seconds 1 count (UCS1)
U2
User concealment seconds 2 count (UCS2)
T1
UCS1 threshold in ms
T2
UCS2 threshold in ms
DSP/DL: Delay Statistics
The delay statistics show the length of the delay for round trip and end system measurements.
The following example shows the parameters for delay statistics
DSP/DL: RT=45, ED=5
Statistics Measured by the IP SLAs RTP-Based VoIP Operation
The IP Service Level Agreements (SLAs) Real-Time Transport Protocol (RTP)-based Voice over IP (VoIP) Operation feature provides the capability to set up and schedule a test call and use Voice gateway digital signal processors (DSPs) to gather network performance-related statistics for the call. Available statistical measurements for VoIP networks include jitter, frame loss, Mean Opinion Score for Conversational Quality (MOS-CQ), and Mean Opinion Score for Listening Quality (MOS-LQ).
The IP SLAs RTP-based VoIP operation provides an enhanced capability to measure voice quality by using DSP-based calculations to determine MOS scores. For customer scenarios where the destination gateway does not have DSP hardware, statistical information is gathered only from the DSP of the source gateway. In this case, the RTP data stream is looped back from the destination to the source gateway.
For detailed information about IP SLAs RTP-based VoIP operation, see the IP SLAs RTP-Based VoIP Operation feature document.
The statistics gathered by the IP SLAs RTP-based VoIP operation vary depending on the type of DSP module (see Table 3 and Table 4).
Table 3 Statistics Gathered by the RTP-Based VoIP Operation for c549 DSPs
Interarrival jitter (destination-to-source and source-to-destination)
Interarrival jitter is the mean deviation (smoothed absolute value) of the difference in packet spacing for a pair of packets.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
For more information about interarrival jitter, see RFC 3550 (RTP: A Transport Protocol for Real-Time Applications).
Estimated R factor (destination-to-source and source-to-destination)
Estimated transmission rating factor R.
This value is based on one-way transmission delay and standard default values. No values are obtained from the DSP to calculate the estimated transmission rating factor R.
For more information about the estimated R factor, see International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation G.107 (The E-model, a computational model for use in transmission planning).
MOS-CQ (destination-to-source and source-to-destination)
Mean Opinion Score for Conversational Quality.
This value is obtained by converting the estimated R factor to Mean Opinion Score (MOS) using ITU-T Recommendation G.107 conversion tables.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
Round-trip time (RTT) latency
Round-trip time latency for an RTP packet to travel from the source to the destination and back to the source.
Packet loss (destination-to-source and source-to-destination)
Number of packets lost.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
Packets missing in action (source-to-destination)
Number of missing packets.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
One-way latency (destination-to-source and source-to-destination)
Average, minimum, and maximum latency values.
These values are measured by sending RTP packets to IP SLAs Responder. The RTP data stream is then looped back from the destination to the source gateway.
Table 4 Statistics Gathered by the RTP-Based VoIP Operation for c5510 DSPs
Interarrival jitter (destination-to-source and source-to-destination)
Interarrival jitter is the mean deviation (smoothed absolute value) of the difference in packet spacing for a pair of packets.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
For more information about interarrival jitter, see RFC 3550 (RTP: A Transport Protocol for Real-Time Applications).
Estimated R factor (destination-to-source and source-to-destination)
Estimated transmission rating factor R.
This value is based on one-way transmission delay and standard default values, as well as values obtained from the DSP.
For more information about the estimated R factor, see International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation G.107 (The E-model, a computational model for use in transmission planning).
MOS-CQ (destination-to-source and source-to-destination)
Mean Opinion Score for Conversational Quality.
This value is obtained by conversion of the estimated R factor to Mean Opinion Score (MOS) using ITU-T Recommendation G.107 conversion tables.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
Round-trip time (RTT) latency
Round-trip time latency for an RTP packet to travel from the source to the destination and back to the source.
Packet loss (destination-to-source and source-to-destination)
Number of packets lost.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
Packets missing in action (source-to-destination)
Number of missing packets.
The source-to-destination value is measured by sending RTP packets to the IP SLAs Responder. No values are obtained from the DSP for this measurement.
One-way latency (destination-to-source and source-to-destination)
Average, minimum, and maximum latency values.
These values are measured by sending RTP packets to IP SLAs Responder. The RTP data stream is then looped back from the destination to the source gateway.
Frame loss (destination-to-source)
Number of DSP frame loss events.
A frame loss can occur due to such events as packet loss, late packets, or a jitter buffer error.
MOS-LQ (destination-to-source)
Mean Opinion Score for Listening Quality.
Vendor Specific Attributes
For information about VSAs Supported by Cisco voice products, see "VSAs Supported by Cisco Voice Products."
Call Agent Support
DSP voice quality metrics can be used with Cisco MGCP call agents. A call agent (or media gateway controller) and softswitch are industry standard terms used to describe the network element that provides call control functionality to telephony and packet networks. The DSP voice quality metrics can report statistics for the following call agents:
Cisco PGW 2200
The Cisco PGW 2200 in "call control mode" functions as a call agent or softswitch.
A PSTN gateway provides the interface between traditional SS7 networks or non-SS7 networks and networks based on Media Gateway Control Protocol (MGCP), H.323, and Session Initiation Protocol (SIP), including signaling, call control, and time-division multiplexing/IP (TDM/IP) gateway functions. The Cisco PGW 2200, coupled with Cisco media gateways, functions as a PSTN gateway.
Caution
Enabling voice quality statistics on the gateway should only be performed by Cisco personnel.
The Cisco PGW 2200, in either signaling mode or call control mode, provides a robust, carrier-class interface between the PSTN and IP-based networks. Interworking with Cisco media gateways, the Cisco PGW 2200 supports a multitude of applications, including the following:
•
•
•
•
•
•
•
•
•
•
Cisco Unified CallManager
Cisco Unified CallManager serves as the software-based call-processing component of the Cisco Unified Communications family of products. A wide range of Cisco Media Convergence Servers provides high-availability server platforms for Cisco Unified CallManager call processing, services, and applications.
The Cisco Unified CallManager system extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications. Additional data, voice, and video services, such as unified messaging, multimedia conferencing, collaborative contact centers, and interactive multimedia response systems, interact through Cisco Unified CallManager open telephony application programming interface (API).
Cisco Unified CallManager provides signaling and call control services to Cisco integrated telephony applications as well as third-party applications. Cisco Unified CallManager performs the following primary functions:
•
•
•
•
•
•
•
How to Configure DSP Voice-Quality Statistics in DLCX Messages
This section contains procedures for configuring the DSP Voice-Quality Statistics in DLCX Messages feature.
•
•
•
Configuring DSP Voice-Quality Statistics in DLCX Messages
To configure voice-quality statistics reporting for MGCP, use the following commands beginning in user EXEC mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Verifying DSP Voice-Quality Statistics in DLCX Messages
Use the following show commands to check your configuration:
SUMMARY STEPS
1.
2.
3.
Step 1
Router# show call active voice compactG<id> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> Total call-legs: 2 G11D6 ORG T187 g729r8 TELE P G11D6 ORG T0 g729r8 VOIP P 10.32.1.21:19324Step 2
Router# show call active voice brief id 11D6<ID>: <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state> dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes> IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> delay:<last>/<min>/<max>ms <codec> MODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected> last <buf event time>s dur:<Min>/<Max>s FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> <codec> (payload size) ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> <codec> (payload size) Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm MODEMRELAY info:<rcvd>/<sent>/<resent> xid:<rcvd>/<sent> total:<rcvd>/<sent>/<drops> speeds(bps): local <rx>/<tx> remote <rx>/<tx> Proxy <ip>:<audio udp>,<video udp>,<tcp0>,<tcp1>,<tcp2>,<tcp3> endpt: <type>/<manf> bw: <req>/<act> codec: <audio>/<video> tx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes> rx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes> Telephony call-legs: 1 SIP call-legs: 0 H323 call-legs: 0 MGCP call-legs: 1 Total call-legs: 2 11D6 : 37530hs.1 +0 pid:0 Originate active dur 00:03:21 tx:1472/29003 rx:1405/27682 Tele 6/4:15 (1): tx:201530/37000/0ms g729r8 noise:-65 acom:90 i/0:-87/-24 dBm 11D6 : 37531hs.1 +-1 pid:0 Originate connecting dur 00:00:00 tx:1403/27642 rx:1472/29003 IP 10.32.1.21:19324 rtt:0ms pl:36000/0ms lost:0/0/0 delay:100/90/110ms g729r8 Telephony call-legs: 1 SIP call-legs: 0 H323 call-legs: 0 MGCP call-legs: 1 Total call-legs: 2Step 3
Router# show call history voice brief<ID>: <start>hs.<index> +<connect> +<disc> pid:<peer_id> <direction> <addr>dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes> <disc-cause>(<text>)IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>delay:<last>/<min>/<max>ms <codec>MODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected>last <buf event time>s dur:<Min>/<Max>sFR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>sig:<on/off> <codec> (payload size)ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>sig:<on/off> <codec> (payload size)Telephony <int>: tx:<tot>/<voice>/<fax>ms <codec> noise:<lvl>dBm acom:<lvl>dBmTroubleshooting DSP Voice-Quality Statistics in DLCX Messages
Use the debug mgcp packets command and keyword to display statistics reported in the DLCX message generated at the end of the call. The following is sample debug output:
Router# debug mgcp packetsDLCX 311216 s6/ds1-4/1@as5400a MGCP 0.1 C: 48A4B I: 2 R: S: X: 4BFAF *May 5 10:20:51.643: send_mgcp_msg, MGCP Packet sent to 10.31.1.200:2427 ---> *May 5 10:20:51.643: 250 311216 OK P: PS=1469, OS=28943, PR=1518, OR=29923, PL=0, JI=100, LA=0 DSP/TX: PK=1448, SG=0, NS=23, DU=206450, VO=39000 DSP/RX: PK=1449, SG=0, CF=23, RX=206450, VO=38000, BS=0, BP=0, LP=0 DSP/PD: CU=100, MI=90, MA=110, CO=69352809, IJ=0 DSP/PE: PC=0, IC=0, SC=0, RM=6, BO=0, EE=0 DSP/LE: TP=-24, TX=-440, RP=-87, RM=-870, BN=0, ER=50, AC=90, TA=-24, RA=-87 DSP/ER: RD=0, TD=0, RC=0, TC=0 DSP/IC: IC=0Additional References
The following sections provide references related to the <<Feature Name>> feature.
Related Documents
How to configure QoS for Cisco features.
Cisco IOS Release 12.4 mainline roadmap
Cisco IOS Release 12.4 Configuration Guides and Command References
How to configure your Cisco router or access server to support voice, video, and fax applications.
How to use Cisco IOS commands to support voice, video, and fax applications.
Cisco MGC documentation index
How to configure MGCP
Configuring Media Gateway Control Protocol and Related Protocols
How to configure the digital signal processor farm
Configuring Enhanced Conferencing and Transcoding for Voice Gateway Routers
How to configure QoS for voice applications.
How to configure voice ports
Configuring Voice Ports, Release 12.3
Enabling basic management protocols on Cisco access platforms
Standards
International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation G.107
The E-model, a computational model for use in transmission planning
MIBs
RFCs
Technical Assistance
Command Reference
This section documents modified commands only.
For voice quality stats, some existing CLI are modified as follows:
The following show commands are modified as follows:
gw-accounting
To enable the accounting method for collecting call detail records, use the gw-accounting command in global configuration mode. To disable the accounting method, use the no form of this command.
Cisco IOS Release 12.4(11)XW and Later Releases
gw-accounting {aaa | syslog [stats] }
no gw-accounting {aaa | syslog [stats]}
Cisco IOS Release 12.2(11)T and Later Releases
gw-accounting {aaa | syslog}
no gw-accounting {aaa | syslog}
Cisco IOS Release 12.2(8)T and Earlier Releases
gw-accounting {h323 [vsa] | syslog | voip}
no gw-accounting {h323 [vsa] | syslog | voip}
Syntax Description
Command Default
No accounting method is enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
This command enables you to output accounting data in one of three ways:
Using RADIUS Vendor-Specific Attributes
The IETF draft standard specifies a method for communicating vendor-specific information between the network access server and the RADIUS server by using the vendor-specific attribute (VSA) attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. The Cisco vendor ID is 9, and the supported option has vendor-type 1, which is named "cisco-avpair." The value is a string of the format:
protocol: attribute sep value *"Protocol" is a value of the Cisco "protocol" attribute for a particular type of authorization. "Attribute" and "value" are an appropriate attribute-value (AV) pair defined in the Cisco TACACS+ specification, and "sep" is "=" for mandatory attributes and "*" for optional attributes. This allows the full set of features available for TACACS+ authorization to also be used for RADIUS. For a list of VSA fields and their ASCII values, see the Cisco IOS Security Configuration Guide for your Cisco IOS release.
Use the gw-accounting aaa command to configure the VSA method of applying H.323 gateway-specific accounting.
Note
Overloading the Acct-Session-ID field
Attributes that cannot be mapped to standard RADIUS are packed into the Acct-Session-ID field as ASCII strings separated by the character "/". The Acct-Session-ID attribute is defined to contain the RADIUS account session ID, which is a unique identifier that links accounting records associated with the same login session for a user. To support additional fields, the following string format is defined for this field:
<session id>/<call leg setup time>/<gateway id>/<connection id>/<call origin>/ <call type>/<connect time>/<disconnect time>/<disconnect cause>/<remote ip address>Table 5 shows the field attributes that are used with the overloaded session-ID method and a brief description of each.
Because of the limited size of the Acct-Session-ID string, it is not possible to include many information elements in it. Therefore, this feature supports only a limited set of accounting information elements.
Use the attribute acct-session-id overloaded command to configure the overloaded session ID method of applying H.323 gateway-specific accounting.
Note
Using syslog Records
The syslog accounting option exports the information elements associated with each call leg through a system log message, which can be captured by a syslog daemon on the network. The syslog output consists of the following:
<server timestamp> <gateway id> <message number> : <message label> : <list of AV pairs>Table 6 lists the syslog message fields.
Use the gw-accounting syslog command to configure the syslog record method of gathering H.323 accounting data.
If you enable both aaa and syslog simultaneously, call detail records are generated in both methods.
Examples
The following example shows accounting using RADIUS VSA attributes:
gw-accounting aaaThe following example shows basic accounting using the syslog method:
gw-accounting syslogRelated Commands
show call active voice
To display call information for voice calls in progress, use the show call active voice command in user EXEC or privileged EXEC mode.
show call active voice [brief [called-number number | calling-number number]] | compact [duration {less seconds | more seconds}] | echo-canceller call-id | id identifier | media-inactive [called-number number | calling-number number] | [long-dur-call] | [redirect {rtpvt | tbct}] | [stats]
Syntax Description
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
Use this command to display the contents of the active call table. This command displays information about call times, dial peers, connections, quality of service, and other status and statistical information for voice calls currently connected through the router.
When the extended EC is present, the show call active voice command displays the contents of the Ditech EC_CHAN_CTRL structure. Table 7 contains names and descriptions of the fields in the EC_CHAN_CTRL structure. Table 7 also provides a listing of the information types associated with this command.
Use the show call active voice redirect command to monitor any active calls that implement RTPvt or TBCT.
When a call is no longer active, its record is stored. You can display the record by using the show call history voice command.
Examples
The following is sample output from the show call active voice command for modem relay traffic:
Router# show call active voiceModem Relay Local Rx Speed=0 bpsModem Relay Local Tx Speed=0 bpsModem Relay Remote Rx Speed=0 bpsModem Relay Remote Tx Speed=0 bpsModem Relay Phy Layer Protocol=v34Modem Relay Ec Layer Protocol=v14SPRTInfoFramesReceived=0SPRTInfoTFramesSent=0SPRTInfoTFramesResent=0SPRTXidFramesReceived=0SPRTXidFramesSent=0SPRTTotalInfoBytesReceived=0SPRTTotalInfoBytesSent=0SPRTPacketDrops=0The following is sample output from the show call active voice command:
Router# show call active voiceTotal call-legs:2GENERIC:SetupTime=7587246 msIndex=1PeerAddress=PeerSubAddress=PeerId=0PeerIfIndex=0LogicalIfIndex=0ConnectTime=7587506CallDuration=00:00:11CallState=4CallOrigin=2ChargedUnits=0InfoType=2TransmitPackets=101TransmitBytes=1991ReceivePackets=550ReceiveBytes=11000VOIP:ConnectionId[0x7F8D82A4 0x928E11D5 0x8094FCFB 0x1C38F0FA]IncomingConnectionId[0x7F8D82A4 0x928E11D5 0x8094FCFB 0x1C38F0FA]RemoteIPAddress=172.29.248.111RemoteUDPPort=17394RoundTripDelay=4 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=TRUEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=FALSESessionProtocol=ciscoSessionTarget=OnTimeRvPlayout=10300GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=70 msLoWaterPlayoutDelay=69 msReceiveDelay=69 msLostPackets=0EarlyPackets=0LatePackets=0VAD = enabledCoderTypeRate=g729r8CodecBytes=20SignalingType=ext-signalCallerName=CallerIDBlocked=FalseGENERIC:SetupTime=7587246 msIndex=2PeerAddress=133001PeerSubAddress=PeerId=133001PeerIfIndex=8LogicalIfIndex=7ConnectTime=7587505CallDuration=00:00:56CallState=4CallOrigin=1ChargedUnits=0InfoType=2TransmitPackets=2801TransmitBytes=56020ReceivePackets=162ReceiveBytes=3192TELE:ConnectionId=[0x7F8D82A4 0x928E11D5 0x8094FCFB 0x1C38F0FA]IncomingConnectionId=[0x7F8D82A4 0x928E11D5 0x8094FCFB 0x1C38F0FA]TxDuration=56030 msVoiceTxDuration=3210 msFaxTxDuration=0 msCoderTypeRate=g729r8NoiseLevel=-44ACOMLevel=-13OutSignalLevel=-45InSignalLevel=-45InfoActivity=2ERLLevel=7EchoCancellerMaxReflector=64SessionTarget=ImgPages=0CallerName=CallerIDBlocked=Fals
Note
The following is sample output from the show call active voice command for voice traffic over call-agent controlled call legs. Note that call legs for SCCP telephony endpoints, that is, phones controlled by STCAPP, are displayed under the "Call agent controlled call-legs." ("SCCP call-legs" displays call legs for devices that are not telephony endpoints, for example, transcoding and conferencing).
Router# show call active voiceTelephony call-legs: 2SIP call-legs: 0H323 call-legs: 0Call agent controlled call-legs: 2SCCP call-legs: 0Multicast call-legs: 0Total call-legs: 4GENERIC:SetupTime=1557650 msIndex=1PeerAddress=PeerSubAddress=PeerId=999100PeerIfIndex=14LogicalIfIndex=10ConnectTime=1562040 msCallDuration=00:01:01 secCallState=4CallOrigin=2ChargedUnits=0InfoType=speechTransmitPackets=3101TransmitBytes=519564ReceivePackets=3094ReceiveBytes=494572TELE:ConnectionId=[0x11B1860C 0x22D711D7 0x8014E4D4 0x8FD15327]IncomingConnectionId=[0x11B1860C 0x22D711D7 0x8014E4D4 0x8FD15327]CallID=25TxDuration=59670 msVoiceTxDuration=59670 msFaxTxDuration=0 msCoderTypeRate=g711ulawNoiseLevel=-12ACOMLevel=22OutSignalLevel=-12InSignalLevel=-11InfoActivity=1ERLLevel=22EchoCancellerMaxReflector=2SessionTarget=ImgPages=0CallerName=CallerIDBlocked=FalseOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x80OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=TranslatedCallingOctet=0x0TranslatedCalledNumber=TranslatedCalledOctet=0x80TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0DSPIdentifier=1/1:1GENERIC:SetupTime=1559430 msIndex=1PeerAddress=7702PeerSubAddress=PeerId=999100PeerIfIndex=14LogicalIfIndex=11ConnectTime=1562020 msCallDuration=00:01:03 secCallState=4CallOrigin=1ChargedUnits=0InfoType=speechTransmitPackets=3151TransmitBytes=528900ReceivePackets=3158ReceiveBytes=503876TELE:ConnectionId=[0x0 0x0 0x0 0x0]IncomingConnectionId=[0x0 0x0 0x0 0x0]CallID=26TxDuration=60815 msVoiceTxDuration=60815 msFaxTxDuration=0 msCoderTypeRate=g711ulawNoiseLevel=-12ACOMLevel=28OutSignalLevel=-12InSignalLevel=-11InfoActivity=1ERLLevel=28EchoCancellerMaxReflector=2SessionTarget=ImgPages=0CallerName=CallerIDBlocked=FalseAlertTimepoint=1559430 msOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x0OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=7701TranslatedCallingOctet=0x0TranslatedCalledNumber=7702TranslatedCalledOctet=0x0TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0GwOutpulsedCalledNumber=7702GwOutpulsedCalledOctet3=0x0GwOutpulsedCallingNumber=7701GwOutpulsedCallingOctet3=0x0GwOutpulsedCallingOctet3a=0x0DSPIdentifier=1/1:2GENERIC:SetupTime=1562040 msIndex=1PeerAddress=PeerSubAddress=PeerId=0PeerIfIndex=0LogicalIfIndex=0ConnectTime=0 msCallDuration=00:00:00 secCallState=2CallOrigin=1ChargedUnits=0InfoType=speechTransmitPackets=3215TransmitBytes=512996ReceivePackets=3208ReceiveBytes=512812VOIP:ConnectionId[0x0 0x0 0x0 0x0]IncomingConnectionId[0x0 0x0 0x0 0x0]CallID=27RemoteIPAddress=10.10.0.0RemoteUDPPort=17718RemoteSignallingIPAddress=10.10.0.0RemoteSignallingPort=0RemoteMediaIPAddress=10.2.6.10RemoteMediaPort=17718RoundTripDelay=0 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=FALSEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=FALSESessionProtocol=otherProtocolCallId=SessionTarget=OnTimeRvPlayout=60640GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=105 msLoWaterPlayoutDelay=105 msTxPakNumber=3040TxSignalPak=0TxComfortNoisePak=0TxDuration=60815TxVoiceDuration=60815RxPakNumber=3035RxSignalPak=0RxDuration=0TxVoiceDuration=60690VoiceRxDuration=60640RxOutOfSeq=0RxLatePak=0RxEarlyPak=0PlayDelayCurrent=105PlayDelayMin=105PlayDelayMax=105PlayDelayClockOffset=-1662143961PlayDelayJitter=0PlayErrPredictive=0PlayErrInterpolative=0PlayErrSilence=0PlayErrBufferOverFlow=0PlayErrRetroactive=0PlayErrTalkspurt=0OutSignalLevel=-12InSignalLevel=-11LevelTxPowerMean=0LevelRxPowerMean=-115LevelBgNoise=0ERLLevel=28ACOMLevel=28ErrRxDrop=0ErrTxDrop=0ErrTxControl=0ErrRxControl=0PlayoutMode = undefinedPlayoutInitialDelay=0 msReceiveDelay=105 msLostPackets=0EarlyPackets=0LatePackets=0SRTP = offVAD = disabledCoderTypeRate=g711ulawCodecBytes=160Media Setting=flow-aroundModem passthrough signaling method is nse:Buffer Fill Events = 0Buffer Drain Events = 0Percent Packet Loss = 0Consecutive-packets-lost Events = 0Corrected packet-loss Events = 0Last Buffer Drain/Fill Event = 0secTime between Buffer Drain/Fills = Min 0sec Max 0secCallerName=CallerIDBlocked=FalseOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x0OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=TranslatedCallingOctet=0x0TranslatedCalledNumber=TranslatedCalledOctet=0x0TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0MediaInactiveDetected=noMediaInactiveTimestamp=MediaControlReceived=Username=GENERIC:SetupTime=1562040 msIndex=2PeerAddress=PeerSubAddress=PeerId=0PeerIfIndex=0LogicalIfIndex=0ConnectTime=0 msCallDuration=00:00:00 secCallState=2CallOrigin=1ChargedUnits=0InfoType=speechTransmitPackets=3380TransmitBytes=540332ReceivePackets=3386ReceiveBytes=540356VOIP:ConnectionId[0x0 0x0 0x0 0x0]IncomingConnectionId[0x0 0x0 0x0 0x0]CallID=28RemoteIPAddress=10.0.0.0RemoteUDPPort=18630RemoteSignallingIPAddress=10.10.0.0RemoteSignallingPort=0RemoteMediaIPAddress=10.2.6.10RemoteMediaPort=18630RoundTripDelay=0 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=FALSEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=FALSESessionProtocol=otherProtocolCallId=SessionTarget=OnTimeRvPlayout=63120GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=105 msLoWaterPlayoutDelay=105 msTxPakNumber=3158TxSignalPak=0TxComfortNoisePak=0TxDuration=63165TxVoiceDuration=63165RxPakNumber=3164RxSignalPak=0RxDuration=0TxVoiceDuration=63165VoiceRxDuration=63120RxOutOfSeq=0RxLatePak=0RxEarlyPak=0PlayDelayCurrent=105PlayDelayMin=105PlayDelayMax=105PlayDelayClockOffset=957554296PlayDelayJitter=0PlayErrPredictive=0PlayErrInterpolative=0PlayErrSilence=0PlayErrBufferOverFlow=0PlayErrRetroactive=0PlayErrTalkspurt=0OutSignalLevel=-12InSignalLevel=-11LevelTxPowerMean=0LevelRxPowerMean=-114LevelBgNoise=0ERLLevel=22ACOMLevel=22ErrRxDrop=0ErrTxDrop=0ErrTxControl=0ErrRxControl=0PlayoutMode = undefinedPlayoutInitialDelay=0 msReceiveDelay=105 msLostPackets=0EarlyPackets=0LatePackets=0SRTP = offVAD = disabledCoderTypeRate=g711ulawCodecBytes=160Media Setting=flow-aroundModem passthrough signaling method is nse:Buffer Fill Events = 0Buffer Drain Events = 0Percent Packet Loss = 0Consecutive-packets-lost Events = 0Corrected packet-loss Events = 0Last Buffer Drain/Fill Event = 0secTime between Buffer Drain/Fills = Min 0sec Max 0secCallerName=CallerIDBlocked=FalseOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x0OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=TranslatedCallingOctet=0x0TranslatedCalledNumber=TranslatedCalledOctet=0x0TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0MediaInactiveDetected=noMediaInactiveTimestamp=MediaControlReceived=Username=Telephony call-legs: 2SIP call-legs: 0H323 call-legs: 0Call agent controlled call-legs: 2SCCP call-legs: 0Multicast call-legs: 0Total call-legs: 4The following is sample output from the show call active voice command for fax-relay traffic:
Router# show call active voiceTelephony call-legs: 0SIP call-legs: 0H323 call-legs: 1MGCP call-legs: 0Multicast call-legs: 0Total call-legs: 1GENERIC:SetupTime=1049400 msIndex=2PeerAddress=52930PeerSubAddress=PeerId=82PeerIfIndex=222LogicalIfIndex=0ConnectTime=105105CallDuration=00:00:59CallState=4CallOrigin=1ChargedUnits=0InfoType=10TransmitPackets=1837TransmitBytes=29764ReceivePackets=261ReceiveBytes=4079VOIP:ConnectionId[0xEB630F4B 0x9F5E11D7 0x8008CF18 0xB9C3632]IncomingConnectionId[0xEB630F4B 0x9F5E11D7 0x8008CF18 0xB9C3632]RemoteIPAddress=10.7.95.3RemoteUDPPort=16610RemoteSignallingIPAddress=10.7.95.3RemoteSignallingPort=1720RemoteMediaIPAddress=10.7.95.3RemoteMediaPort=16610RoundTripDelay=13 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=TRUEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=TRUESessionProtocol=ciscoProtocolCallId=SessionTarget=ipv4:10.7.95.3OnTimeRvPlayout=1000GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=110 msLoWaterPlayoutDelay=70 msReceiveDelay=70 msLostPackets=0EarlyPackets=1LatePackets=0VAD = enabledCoderTypeRate=t38CodecBytes=40Media Setting=flow-throughAlertTimepoint=104972CallerName=CallerIDBlocked=FalseOriginalCallingNumber=4085550130OriginalCallingOctet=0x0OriginalCalledNumber=52930OriginalCalledOctet=0xE9OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x7FTranslatedCallingNumber=4085550130TranslatedCallingOctet=0x0TranslatedCalledNumber=52930TranslatedCalledOctet=0xE9TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0xFFGwReceivedCalledNumber=52930GwReceivedCalledOctet3=0xE9GwOutpulsedCalledNumber=52930GwOutpulsedCalledOctet3=0xE9GwReceivedCallingNumber=4085452930GwReceivedCallingOctet3=0x0GwReceivedCallingOctet3a=0x80GwOutpulsedCallingNumber=4085550130GwOutpulsedCallingOctet3=0x0GwOutpulsedCallingOctet3a=0x80Username=FaxRelayMaxJitterBufDepth = 0 msFaxRelayJitterBufOverFlow = 0FaxRelayHSmodulation = 0FaxRelayNumberOfPages = 0Telephony call-legs: 0SIP call-legs: 0H323 call-legs: 1MGCP call-legs: 0Multicast call-legs: 0Total call-legs: 1
Note
The following is sample output from the show call active voice brief command:
Router# show call active voice brief<ID>: <CallID> <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state>dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes>IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>delay:<last>/<min>/<max>ms <codec>media inactive detected:<y/n> media cntrl rcvd:<y/n> timestamp:<time>long_duration_call_detected:<y/n> long duration call duration:n/a timestamp:n/aMODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected>last <buf event time>s dur:<Min>/<Max>sFR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n><codec> (payload size)ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n><codec> (payload size)Tele <int> (callID) [channel_id] tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBmMODEMRELAY info:<rcvd>/<sent>/<resent> xid:<rcvd>/<sent> total:<rcvd>/<sent>/<drops>speeds(bps): local <rx>/<tx> remote <rx>/<tx>Proxy <ip>:<audio udp>,<video udp>,<tcp0>,<tcp1>,<tcp2>,<tcp3> endpt: <type>/<manf>bw: <req>/<act> codec: <audio>/<video>tx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>rx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>Total call-legs:21269 :7587246hs.1 +260 pid:0 Answer activedur 00:07:14 tx:590/11550 rx:21721/434420IP 172.29.248.111:17394 rtt:3ms pl:431850/0ms lost:0/0/0 delay:69/69/70ms g729r81269 :7587246hs.2 +259 pid:133001 Originate 133001 activedur 00:07:14 tx:21717/434340 rx:590/11550Tele 1/0:1 (2):tx:434350/11640/0ms g729r8 noise:-44 acom:-19i/0:-45/-45 dBmThe following is an example of the show call active voice command using the echo-canceller keyword. The number 9 represents the hexadecimal ID of an active voice call.
Router# show call active voice echo-canceller 9ACOM=-65 ERL=45Echo canceller control words=6C 0Bypass=OFF Tail=64 Residual ecan=Comfort noiseFreeze=OFF Modem tone disable=Ignore 2100Hz toneWorst ERL=6 High level compensation=OFFMax amplitude reflector (in msec)=5Ecan version = 8180The following is sample output from the show call active voice echo-canceller command for a call with a hexadecimal ID of 10:
Router# show call active voice echo-canceller 10ACOM=-15 ERL=7Echo canceller control words=6C 0Bypass=OFF Tail=64 Residual ecan=Comfort noiseFreeze=OFF Modem tone disable=Ignore 2100Hz toneWorst ERL=6 High level compensation=OFFMax amplitude reflector (in msec)=64The call ID number (which is 10 in the previous example) changes with every new active call. When an active call is up, you must enter the show call active voice brief command to obtain the call ID number. The call ID must be converted to hex if you want to use the show call active voice echo-canceller x command (x = call ID converted to hex).
The following are call ID examples converted to hex (generally incremented by 2):
Alternatively, you can use the show voice call status command to obtain the call ID. The call ID output is already in hex form when you use this command:
Router# show voice call statusCallID CID ccVdb Port DSP/Ch Called # Codec Dial-peers0x1 11CE 0x02407B20 1:0.1 1/1 1000 g711ulaw 2000/1000The following is sample output from the show call active voice redirect command using the tbct keyword:
Router# show call active voice redirect tbctTBCT:Maximum no. of TBCT calls allowed:No limitMaximum TBCT call duration:No limitTotal number TBCT calls currently being monitored = 1ctrl name=T1-2/0, tag=13, call-ids=(7, 8), start_time=*00:12:25.985 UTC Mon Mar 1 1993Table 8 describes the significant fields shown in the show call active voice redirect display.
Related Commands
show call history voice
To display the call history table for voice calls, use the show call history voice command in user EXEC or privileged EXEC mode.
show call history voice [brief [id identifier] | compact [duration {less seconds | more seconds }]
| id identifier | last number | redirect {rtpvt | tbct}] | [stats]Syntax Description
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
This command displays a call-history table that contains a list of voice calls connected through the router in descending time order. The maximum number of calls contained in the table can be set to a number from 0 to 500 using the dial-control-mib command in global configuration mode. The default maximum number of table entries is 50. Each call record is aged out of the table after a configurable number of minutes has elapsed. The timer value is also specified by the dial-control-mib command. The default timer value is 15 minutes.
You can display subsets of the call history table by using specific keywords. To display the last calls connected through this router, use the last keyword, and define the number of calls to be displayed with the number argument.
To display a truncated version of the call history table, use the brief keyword.
Use the show call active voice redirect command to review records for calls that implemented RTPvt or TBCT.
When a call is active, you can display its statistics by using the show call active voice command.
Examples
The following is sample output from the show call history voice command:
Router# show call history voiceGENERIC:SetupTime=104648 msIndex=1PeerAddress=55240PeerSubAddress=PeerId=2PeerIfIndex=105LogicalIfIndex=0DisconnectCause=10DisconnectText=normal call clearing.ConnectTime=104964DisconectTime=143329CallDuration=00:06:23CallOrigin=1ChargedUnits=0InfoType=speechTransmitPackets=37668TransmitBytes=6157536ReceivePackets=37717ReceiveBytes=6158452VOIP:ConnectionId[0x4B091A27 0x3EDD0003 0x0 0xFEFD4]RemoteIPAddress=1.14.82.14RemoteUDPPort=18202RoundTripDelay=2 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=TRUESessionProtocol=ciscoSessionTarget=ipv4:1.14.82.14OnTimeRvPlayout=40GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=67 msLoWaterPlayoutDelay=67 msReceiveDelay=67 msLostPackets=0 msEarlyPackets=0 msLatePackets=0 msVAD = enabledCoderTypeRate=g729r8CodecBytes=20cvVoIPCallHistoryIcpif=0SignalingType=casModem passthrough signaling method is nseBuffer Fill Events = 0Buffer Drain Events = 0Percent Packet Loss = 0Consecutive-packets-lost Events = 0Corrected packet-loss Events = 0Last Buffer Drain/Fill Event = 373secTime between Buffer Drain/Fills = Min 0sec Max 0secGENERIC:SetupTime=104443 msIndex=2PeerAddress=50110PeerSubAddress=PeerId=100PeerIfIndex=104LogicalIfIndex=10DisconnectCause=10DisconnectText=normal call clearing.ConnectTime=104964DisconectTime=143330CallDuration=00:06:23CallOrigin=2ChargedUnits=0InfoType=speechTransmitPackets=37717TransmitBytes=5706436ReceivePackets=37668ReceiveBytes=6609552TELE:ConnectionId=[0x4B091A27 0x3EDD0003 0x0 0xFEFD4]TxDuration=375300 msVoiceTxDuration=375300 msFaxTxDuration=0 msCoderTypeRate=g711ulawNoiseLevel=-75ACOMLevel=11SessionTarget=ImgPages=0The following example from a Cisco AS5350 router displays a sample of voice call history records showing release source information:
Router# show call history voiceTelephony call-legs: 1SIP call-legs: 0H323 call-legs: 1Total call-legs: 2GENERIC:SetupTime=85975291 ms...DisconnectCause=10DisconnectText=normal call clearing (16)ConnectTime=85975335DisconnectTime=85979339CallDuration=00:00:40CallOrigin=1ReleaseSource=1...DisconnectCause=10DisconnectText=normal call clearing (16)ConnectTime=85975335DisconnectTime=85979339CallDuration=00:00:40CallOrigin=1ReleaseSource=1...VOIP:ConnectionId[0x2868AD84 0x375B11D4 0x8012F7A5 0x74DE971E]...GENERIC:SetupTime=85975290 ms...DisconnectCause=10DisconnectText=normal call clearing (16)ConnectTime=85975336DisconnectTime=85979340CallDuration=00:00:40CallOrigin=2ReleaseSource=1...TELE:ConnectionId=[0x2868AD84 0x375B11D4 0x8012F7A5 0x74DE971E]The following is sample output from the show call history voice brief command:
Router# show call history voice brief<ID>: <CallID> <start>hs.<index> +<connect> +<disc> pid:<peer_id> <direction> <addr>dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes> <disc-cause>(<text>)IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>delay:<last>/<min>/<max>ms <codec>media inactive detected:<y/n> media cntrl rcvd:<y/n> timestamp:<time>MODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected>last <buf event time>s dur:<Min>/<Max>sFR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n><codec> (payload size)ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n><codec> (payload size)Telephony <int> (callID) [channel_id] tx:<tot>/<voice>/<fax>ms <codec> noise:<lvl>dBm acom:<lvl>dBmMODEMRELAY info:<rcvd>/<sent>/<resent> xid:<rcvd>/<sent> total:<rcvd>/<sent>/<drops> disc:<cause code>speeds(bps): local <rx>/<tx> remote <rx>/<tx>Proxy <ip>:<audio udp>,<video udp>,<tcp0>,<tcp1>,<tcp2>,<tcp3> endpt: <type>/<manf>bw: <req>/<act> codec: <audio>/<video>tx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>rx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>The following is sample output from the show call history voice redirect command:
Router# show call history voice redirect tbctindex=2, xfr=tbct-notify, status=redirect_success, start_time=*00:12:25.981 UTC Mon Mar 1 1993, ctrl name=T1-2/0, tag=13index=3, xfr=tbct-notify, status=redirect_success, start_time=*00:12:25.981 UTC Mon Mar 1 1993, ctrl name=T1-2/0, tag=13index=4, xfr=tbct-notify, status=redirect_success, start_time=*00:13:07.091 UTC Mon Mar 1 1993, ctrl name=T1-2/0, tag=12index=5, xfr=tbct-notify, status=redirect_success, start_time=*00:13:07.091 UTC Mon Mar 1 1993, ctrl name=T1-2/0, tag=12Number of call-legs redirected using tbct with notify:4Table 9 describes the significant fields shown in the show call history voice redirect tbct display.
Related Commands
Feature Information for DSP Voice Quality Metrics for MGCP
Table 10 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Glossary
AAL2—ATM adaptation layer 2.
ASP—application service provider.
CA—call agent.
CAC—call admission control.
CAS—channel-associated signaling.
CDR—call detail record.
CLI—command-line-interface.
DCLX—MGCP Delete Connection message.
DSP—digital signal processor.
FTP—File Transfer Protocol.
NAS—network access server.
PVC—permanent virtual circuit.
RSVP—Resource Reservation Protocol.
RTCP—RTP Control Protocol. Protocol that monitors the QoS of an IPv6 RTP connection and conveys information about the ongoing session.
RTP—Real-Time Transport Protocol.
SRC—system resource check.
TDM—time-division multiplexing.
VPN—virtual private network.
WFQ—weighted fair queueing.
Note
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)