AOS Voice Quality Monitoring (VQM)

61200796L1-29.2DJuly 2008

Configuration Guide

Voice Quality Monitoring

This configuration guide will aid in the setup and navigation of the voice quality monitoring (VQM) feature for ADTRAN Operating System (AOS) products. An overview of VQM general features, combined with detailed descriptions of Web-based graphical user interface (GUI) menus, provides step-by-step assistance for configuring VQM. The troubleshooting section outlines proper use and interpretation of collected data (to ensure the most benefit from using VQM on the AOS product(s)).

This document also covers how to enable VQM using the command line interface (CLI). For detailed CLI VQM commands, refer to the AOS Command Reference Guide (CRG) available on the AOS Documentation CD shipped with your unit or on the Web at www.adtran.com. A basic understanding of Voice over IP (VoIP), VoIP quality of service (QoS), and Session Initiation Protocol (SIP) are prerequisites to fully understand the information covered in this document.

This guide consists of the following sections:

• VQM Overview on page 2• Hardware and Software Requirements and Limitations on page 4• Configuring VQM on page 6• Troubleshooting on page 38• Loopback Account Troubleshooting on page 40• Appendix A. AOS VQM Statistics Descriptions on page 47• Appendix B. ADTRAN Supported CODECs on page 57

VQM Overview Voice Quality Monitoring

2 Copyright © 2008 ADTRAN, Inc. 61200796L1-29.2D

VQM Overview

VQM allows real time passive Voice over IP (VoIP) quality measurements to be taken on all Realtime Transport Protocol (RTP) voice streams transmitted through an AOS device. Issues such as network congestion and improper provisioning can cause problems such as packet loss, jitter, and echo and can take a severe toll on voice streams over IP networks. VQM provides statistics and measurements vital for determining the quality of voice calls and the source of voice quality problems. VQM statistics can be sorted by call, interface, source IP address, RTP flows, and by date and time. Other statistics sorting and searches are available in the RTP Quality Metrics GUI menus.

Voice Quality Statistics

Although ADTRAN’s VQM feature provides detailed statistics and metrics on the perceived quality of VoIP phone calls, the voice user’s perception of call quality is also extremely important in detecting the severity of voice quality issues. In this section, some common issues will be examined that occur on IP networks that can cause voice quality problems.

The Mean Opinion Score (MOS) is a calculated number of the perceived voice quality on a network. MOS scores are determined by tests on the network specified by ITU-T recommendation P.800. The MOS scores are commonly on a scale of 1 (bad) to 5 (excellent). However, ADTRAN’s MOS scale range is 0 (poor) to 4.4 (excellent) (see Table 1 below).

The term delay (sometimes referred to as latency) is used to describe the time it takes information to travel from source to destination (distance between hops, or data-to-voice conversions). There are a number of sources of delay. Voice encoding/decoding, link bandwidth, and jitter buffer depth all impact the overall delay that voice users experience. The effects of delay are most noticeable if the delay is greater than 150 milliseconds (ms).

Jitter occurs when the delay between received packets varies. Ideally, voice packets are evenly spaced and received in a continuous stream, allowing smooth playback at the receiver. However, network congestion can cause variations in delay (longer delays with more congestion and shorter delays with less congestion). When the space between the packets differ in the RTP stream, the resulting jitter affects audio quality. IP phones, private branch exchanges (PBXs), and Integrated Access Devices (IADs) incorporate jitter buffers to counteract jitter. Jitter buffers add a small amount of delay between receiving a VoIP packet and playing

ADTRAN’s MOS scale is for typical CODECs. However, wideband CODECs can scale differently and a call with a MOS of 3.8 may have excellent quality. Therefore, the R factor measurements should also be used with wideband CODECs.

Table 1. ADTRAN MOS Voice Quality Ranges

Quality MOS Range

Excellent 4.40 to 4.00

Good 3.99 to 3.60

Fair 3.59 to 2.60

Poor 2.59 to 0.00

Voice Quality Monitoring VQM Overview

61200796L1-29.2D Copyright © 2008 ADTRAN, Inc. 3

it back. VQM is designed to estimate the effects of this jitter buffer delay. The average and maximum delay indicate the size of the jitter buffer. By default, the jitter buffer on AOS products is set to adaptive with a nominal depth of 50 ms. Prioritizing traffic and managing delays are keys to improving latency and jitter.

Lost packets (or loss) occur when the network is congested with large amounts of traffic. When congested, the network can drop packets, resulting in dropped calls or choppy voice transmissions. Lost packets are defined as RTP packets that were never received by the voice endpoint for processing. When an inbound RTP packet is sent to VQM’s jitter buffer, the timestamp in the RTP header is checked. Each sequential packet should be one packetization period greater than the timestamp on the previous packet. For example, suppose 80 timestamp units represent 10 ms of audio. If the packetization period of an RTP stream is 20 ms, each sequential RTP timestamp unit should increment by 160 units. If the AOS device receives an RTP packet with a timestamp of 1084455193, the next expected timestamp would be 1084455353 (160 units difference). However, if the next received packet had a timestamp of 1084455513 (320 units difference), then a lost packet would be logged. If the packet is delayed and arrives beyond the window of the jitter buffer, a late or early arrival will be logged. All late and early arriving packets will be subtracted from the total of lost packets.

Discarded packets are packets that arrive before or after the window of the jitter buffer (based on the timestamp, they will be considered early or late arrivals). All early and late arrivals are logged as discarded packets and will not be played out. If the jitter buffer is set to adaptive and the AOS product continues to log packets outside of the jitter window, the jitter buffer will increase the window size in 5 ms increments.

VQM Functionality on the Router

VQM metrics can be measured on the router’s interfaces for inbound RTP voice streams. These VQM metrics can detect network issues affecting the quality of voice on the wide area network (WAN) or local area network (LAN). Issues detected on the WAN are typically the service provider’s responsibility, and issues detected on the LAN are typically the customer’s responsibility. The VQM metrics and statistics can be obtained for the private and public areas of the network to determine the portion of the network responsible for the perceived voice quality issues. In the example below (Figure 1), WAN RTP quality metrics can be taken on the T1 interface (T1 3/1), and LAN metrics can be taken on the private interface (eth 0/2).

Figure 1. Example of Basic Router Monitoring of RTP Streams

The jitter buffer in the AOS data products is simulated and does not change packet playout. The simulated jitter buffer is only used to determine the quality of the RTP streams in the AOS data products.

Internet Service Provider

VoIP Traffic Flow over RTP Stream

Monitoring public to private RTP streams todetect possible WAN issues affecting voicequality.

Monitoring private to public RTP streams todetect possible LAN issues affecting voicequality.

Private Network (LAN)IP Address: 10.1.1.20LAN Interface: eth 0/2

Public Network (WAN)IP Address: 208.61.209.294WAN Interface: T1 3/1

IP PhonesAnalog Phones, IP Phones,

and Data Network

10/100BaseT

SwitchNetVanta 4305

Hardware and Software Requirements and Limitations Voice Quality Monitoring


Hardware and Software Requirements and Limitations

VQM was introduced in firmware AOS 17.1.1 for the following AOS Data Products:

• NetVanta 1335 • NetVanta 3100 Series• NetVanta 3200 Series• NetVanta 3400 Series (Enhanced Feature Pack required)• NetVanta 4305 (Enhanced Feature Pack required)• NetVanta 5305 (Enhanced Feature Pack required)

VQM was introduced in firmware AOS A.1 for the following AOS voice products:

• NetVanta 6355• NetVanta 7000 Series • Total Access 900(e) Series

The following caveats exist with the current version(s) of VQM:

• VQM works with the SIP ALG, SIP transparent proxy, and the SIP stack. The SIP proxy and SIP ALG manage the firewall to allow the RTP traffic to pass through; therefore, the firewall must be enabled when using VQM. When using network address translation (NAT) with Internet connection sharing, a NAT source policy is required on the private-side policy class. If NAT is not desirable, an allow entry can be used in the ip policy-class. The allow policy-class entry must not be stateless.

• By default, VQM is disabled globally, but enabled on each interface. This feature is globally configured to be either enabled or disabled. Although each IP interface can be individually configured for VQM (on/off), VQM must be globally enabled first. To change the default MOS scoring adjustment region setting, disable VQM, then enable VQM with the scoring adjustment region of your choice. All active call statistics and interface statistics will be lost when VQM is disabled. However, the default call history stores the statistics of up to 1000 previously completed calls (the default is 50 calls, 100 streams). The NetVanta 3200 series VQM support is limited to up to 10 calls (20 RTP streams). The default settings for the call history are usually sufficient, but these settings can also be configured by the user, and are covered in detail in the next section of this document.

• In order for VQM subsystems to gather statistics on the RTP traffic, the traffic must be routed through the AOS product running VQM. The physical interfaces can be used to filter certain traffic to be monitored. RTP must be IP routed through the unit for the VQM subsystem to gather statistics. Calls can be filtered by using separate interfaces to route specific calls and then gather statistics on

Enabling the firewall only for the purpose of using VQM in your application can affect your network performance.

Voice Quality Monitoring Hardware and Software Requirements and Limitations


that specific interface by disabling VQM on other interfaces. VQM will not work on switched RTP traffic, RTP traffic over a VPN or GRE tunnel that is not terminated by the AOS device, L3 switched interfaces, bridged traffic, or secure RTP packets. VQM will also disable RapidRoute for RTP traffic.

• VQM will not gather information on RTP traffic received on unsupported CODECs. VQM works with the list of supported CODECs outlined in Appendix B. ADTRAN Supported CODECs on page 57.

Using VQM will degrade the router’s performance to some degree. Since the RTP stream bypasses RapidRoute and is sent through an ALG for processing, the performance load is greater (degrading performance).

Configuring VQM Voice Quality Monitoring


Configuring VQM

The following steps are required to implement VQM in AOS:

Step 1: Enable VQM on page 7

Selecting RTP Monitoring of the Interfaces in the GUI on page 7

Selecting the Interface to Monitor (CLI) on page 12

Step 2: Evaluate the VQM Metrics on page 18

Enabling VQM Using the GUI

Access the GUI from any Web browser on your network by following these steps:

1. Connect the unit to your PC using the first Ethernet port on the unit with a 10/100BaseT Ethernet cable.2. Set your PC to obtain an IP address automatically via Dynamic Host Configuration Protocol (DHCP),

or change your PC to a fixed IP address of 10.10.10.2. If you cannot change the PC’s IP address, you will need to change the unit’s IP address using the CLI.

3. Enter the unit’s IP address in your browser’s address line. The default IP address is 10.10.10.1. You will then be prompted for the user name and password (the default settings are admin and password). After entering the correct user name and password, the initial GUI menu will appear.

Figure 2. GUI Login Screen

While navigating the GUI, you will notice question mark symbols that indicate additional information is available. Simply place your cursor over the symbol to view the additional information.

Updated configurations must be saved to nonvolatile memory (NVRAM) to retain new changes after a loss of power or a reboot. To quickly save your configuration at any time while in the GUI, select Save at the top right of your current menu.

Voice Quality Monitoring Enabling VQM Using the GUI


Step 1: Enable VQM

Selecting RTP Monitoring of the Interfaces in the GUI

The SIP proxy and SIP ALG manage the firewall to allow the RTP traffic to pass through; therefore, the firewall must be enabled when using VQM.

1. Navigate to the Monitoring > Voice Quality > RTP Monitoring menu. At the bottom of the menu, under RTP Monitoring Settings, select the Monitor Settings tab. Then select the Enabled check box next to SIP RTP Monitoring or Any RTP Monitoring or SIP RTP Monitoring and Any RTP Monitoring.

Figure 3. RTP Monitoring Menu

If available, RTCP SR and XR reports can also be used to calculate round trip delay. RTCP will be monitored automatically and require no additional configuration.

The Extensions tab is only present in the AOS voice products. Refer to Extensions Metrics on page 27 for descriptions of Extensions tab menus.

Enabling VQM Using the GUI Voice Quality Monitoring


Settings and DescriptionsSee Figure 4 below for a full view of the Basic Settings on the Monitor Settings tab.SIP RTP Monitoring monitors streams detected by the SIP ALG, SIP proxy, or B2BUA.Any RTP Monitoring monitors all RTP streams, except those that are affected by local SIP services or streams that are being handled by the SIP ALG.Locale sets the country location used to determine the logic for RTP monitoring scoring adjustment region. Scoring adjustments are different for Japan than for other parts of the world.Past Calls History Size specifies the maximum number of RTP streams held in the call history. The range is 0 to 2000. The default is 100.Sampling Rate (AOS voice products only) specifies the fraction of calls to monitor. A denominator of 1 indicates all calls will be monitored and a denominator of 100 indicates that only 1 percent of calls will be monitored. The default is 1.

2. Optional. On the same Monitor Settings tab, adjust the advanced Simulated Jitter Buffer Settings and Round Trip Delay Calculation Settings. The default settings are recommended for most users.

Figure 4. Monitor Settings Tab

VQM uses a jitter buffer for quality measurements. For the most accurate results, users should select settings that are consistent with the VoIP endpoints in their network. However, the defaults will still help users detect excess jitter in their network.



Settings and DescriptionsSimulated Jitter Buffer Type sets the simulated jitter buffer type to adaptive or fixed. An adaptive simulated jitter buffer automatically increases or decreases playout delay to adjust for varying packetization length, and CODEC types. This is most useful for compensating for varied jitter in the network. A fixed simulated jitter buffer uses a fixed playout delay for all packets.Jitter Adaptive Minimum (ms) sets the smallest allowed delay for the adaptive simulated jitter buffer.Jitter Adaptive Nominal (ms) sets the beginning delay of the adaptive simulated jitter buffer.Jitter Adaptive Maximum (ms) sets the maximum delay of the adaptive simulated jitter buffer. Any RTP packets received after this delay will not be analyzed.Jitter Buffer Early Threshold (ms) sets an additional threshold for discarding RTP packets arriving earlier than the specified delay. Packets arriving earlier than this threshold will be considered discards regardless of the current jitter buffer size.Jitter Buffer Late Threshold (ms) sets an additional threshold for discarding RTP packets arriving later than the specified delay. Packets arriving later than this threshold will be considered discards regardless of the current jitter buffer size.Round Trip Delay Calculation Enabled specifies a round trip delay calculation that takes place at the beginning of a call. Select the check box to enable or uncheck to disable a round trip delay calculation.Round Trip Delay Calculation Type specifies the type of round trip testing. Select Ping to use ICMP echo requests for calculating round trip delay, or select Timestamp to use ICMP timestamp echo request messages for more accurate results. Note that both endpoints and the local units must be synchronized (time and date) for the Timestamp method to be accurate, and any firewalls between the endpoints must be configured to allow ICMP traffic to pass.

If available, RTCP SR and XR reports can also be used to calculate round trip delay. RTCP will be monitored automatically and require no additional configuration.

Enabling VQM Using the GUI Voice Quality Monitoring


3. Optional. From the RTP Monitoring Settings menu, select the Thresholds tab to adjust the Past Calls Thresholds and Event Logging Thresholds settings.

Figure 5. Thresholds Tab

Settings and DescriptionsMOS-LQ Past Calls Threshold defines the threshold for recording statistics for RTP streams based on the listening quality (LQ) MOS. Calls with quality worse than the specified threshold will be logged in the Past Calls record.MOS-CQ Past Calls Threshold defines the threshold for recording statistics for RTP streams based on the conversational quality (CQ) MOS. Calls with quality worse than the specified threshold will be logged in the Past Calls record.MOS-PQ Past Calls Threshold defines the threshold determined for recording statistics for RTP streams based on the listening quality MOS normalized to the PESQ (PQ) scale. Calls with quality worse than the specified threshold will be logged in the Past Calls record. Lost Packet Past Calls Threshold defines thresholds for recording statistics for RTP streams based on the amount of lost packet errors during the call. Calls with quality worse than the specified threshold will be logged in the Past Calls record. Out of Order Packet Past Calls Threshold defines thresholds for recording statistics for RTP streams based on the amount of out-of-order packet errors during the call. Calls with quality worse than the specified threshold will be logged in the Past Calls record. Jitter Past Calls Threshold defines thresholds for recording statistics for RTP streams based on the amount of jitter during the call. Calls with quality worse than the specified threshold will be logged in the Past Calls record.



MOS-LQ Thresholds defines thresholds to generate events (to log via SYSLOG, etc.) for RTP streams with LQ MOS poorer than the configured threshold. Calls with quality lower than the specified thresholds will be logged at the defined severity (Info, Notice, Warning, or Error). Uncheck any setting to disable the logging event messages. The range is 0 to 4.4.MOS-PQ Thresholds defines thresholds to generate events for listening quality PQ MOS. Calls with quality lower than the specified thresholds will be logged as the defined severity (Info, Notice, Warning, or Error). Uncheck any setting to disable the logging event messages. The range is 0 to 4.4.Out-of-Order Packets Thresholds defines thresholds to generate events for RTP streams with out-of-order packets. Calls with quality lower than the specified thresholds will be logged as the defined severity (Info, Notice, Warning, or Error). Uncheck any setting to disable the logging event messages. The range is 0 to 30000.Lost Packets Thresholds defines thresholds to generate events for RTP streams with lost packets. Calls with quality lower than the specified thresholds will be logged as the defined severity (Info, Notice, Warning, or Error). Uncheck any setting to disable the logging event messages. The range is0 to 30000.

Jitter Calls Thresholds defines thresholds to generate events for RTP streams with jitter. Calls with quality lower than the specified thresholds will be logged as the defined severity (Info, Notice, Warning, or Error). Uncheck any setting to disable the logging event messages. The range is 0 to 30000.

4. Optional (AOS voice products only). From the RTP Monitoring Settings menu, select the Filters tab to assign filters for VQM.

Figure 6. Filters Tab

Calls with To and From fields that match the User Filters will be monitored. If no User Filters are defined, all calls will be monitored unless they are limited by ACL(s) or sampling rate(s).

Calls that match at least one of the ACL filters will be monitored. If no ACL filter(s) is defined, then all calls will be monitored (except where limited by a user filter or the sampling rate).

Enabling VQM Using the CLI Voice Quality Monitoring


Enabling VQM Using the CLI

The SIP proxy and SIP ALG manage the firewall to allow the RTP traffic to pass through; therefore, the firewall must be enabled when using VQM. To globally enable (or disable using the no version of this command) VQM and also optionally change the scoring adjustment region in the CLI, issue the following command(s) from the Global command prompt:

(config)#ip rtp quality-monitoring

Optional. The following command with the scoring-adjustment japan argument specifies the regional scoring adjustment. In Japan, MOS scores are calculated differently than in other regions. VQM must be disabled and then enabled again for this setting to take effect. When VQM is enabled, no scoring adjustment is performed by default.

(config)#ip rtp quality-monitoring [scoring-adjustment japan]

Optional. The following command enables the SIP ALG to mark firewall holes created for RTP to be monitored by VQM. The default is disabled. If ip rtp quality-monitoring is not enabled, issuing this command will enable VQM without a scoring adjustment region.

(config)#ip rtp quality-monitoring sip

Optional. The following command enables UDP packet inspection to determine if VQM should monitor RTP traffic. The first packet of each UDP flow is inspected. The default is disabled. If ip rtp quality-monitoring is not enabled, issuing this command will enable VQM without a scoring adjustment region.

(config)#ip rtp quality-monitoring udp

Selecting the Interface to Monitor (CLI)

To monitor RTP inbound to an interface, VQM must be enabled on the interface and it must be assigned an IP address (or a method for getting an IP address assigned, such as DHCP). If voice quality degradation is detected on an interface, the statistics and metrics gathered by VQM help the user and their provider resolve the problem. By default, rtp quality-monitoring is enabled on all interfaces.

When issued from the desired interface configuration prompt, the following command enables or disables VQM on the specified interface (refer to Example Configurations on page 14):

(config-eth 0/1)#rtp quality-monitoring

Optional. Set the jitter buffer type and configuration for the jitter buffer emulator (JBE) that will generate the statistics for VQM (in Global configuration). The default setting is adaptive min 10 nominal 50 max 200.

(config)#ip rtp quality-monitoring jitter-buffer [adaptive min <minimum> | nominal <nominal> | max <maximum>] | [fixed nominal <nominal> | jitter-buffer-size <jitter-buffer-size>]

adaptive min <minimum> specifies the minimum acceptable jitter buffer delay to be used by the jitter buffer. The range is 10 to 240 ms.

Voice Quality Monitoring Enabling VQM Using the CLI


nominal <nominal> specifies the starting delay to apply to packets of the jitter buffer. The range is 10to 240 ms.

max <maximum> specifies the maximum delay to which the adaptive jitter buffer is allowed to grow. The range is 40 to 320 ms.

fixed nominal <nominal> specifies the actual fixed delay to apply to the packets of the jitter buffer. The range is 4 to 250 ms. There is no default.jitter-buffer-size <size> specifies the number of packets that the jitter buffer can hold if this were a real, nonemulated jitter buffer. The range is 10 to 500 packets. There is no default.

Optional. Set the early and late jitter thresholds in milliseconds (ms). This specifies how many packets are deemed early or late. Changing the jitter threshold will not impact currently active calls, only the calls placed after the configuration change has taken place. Use the no form of this command to disable the jitter threshold. The default settings for the jitter threshold are early 10 (ms) and late 50 (ms). The range is 0 to 1000 ms.

(config)#ip rtp quality-monitoring jitter-threshold [early <ms> | late <ms>]

early <ms> specifies the time limit to declare the packets early if they are received before this time.

late <ms> specifies the time limit to declare the packets late if they are received after this time.

Refer to the Configuration Command Summary on page 15 for additional VQM commands. Refer to the AOS Command Reference Guide located on your AOS Documentation CD or on the Web at www.adtran.com for a complete list of VQM commands.



Example Configurations

The following example is designed to enhance the understanding of VQM on AOS products. In this example, RTP quality monitoring is globally enabled, enabled on interface eth 0/2, and then disabled on interface eth 0/1, and the jitter buffer is also tweaked.

Example Configuration

>enable#configure terminal(config)#ip rtp quality-monitoring(config)#ip rtp quality-monitoring sip(config)#ip rtp quality-monitoring jitter-buffer adaptive min 10 nominal 75 max 220(config)#ip rtp quality-monitoring jitter-threshold early 15(config)#ip rtp quality-monitoring jitter-threshold late 75(config)#interface eth 0/2(config-eth 0/2)#rtp quality-monitoring (config-eth 0/2)#exit(config)#interface eth 0/1(config-eth 0/1)#no rtp quality-monitoring



Configuration Command SummaryTable 2. Command Summary Table

Step Command Explanation

Step 1 (config)#ip rtp quality-monitoring [scoring-adjustment japan]

Enables VQM globally and sets the scoring adjustment region. When VQM is disabled, the call history will remain available; you must issue a clear ip rtp quality-monitoring to free the resources allocated for the call history. The per interface VQM configuration will remain. Use the no form of this command to disable VQM. By default, VQM is disabled. When enabled, no scoring adjustment is set unless specified.

Optional (At the minimum, one of these commands have to be enabled for VQM to work.)

(config)#ip rtp quality-monitoring sip Enables the SIP ALG, SIP proxy, or B2BUA (as available) to mark firewall holes created for RTP streams for monitoring of voice quality on these streams. Use the no form of this command to disable monitoring. By default, VQM is disabled. Note: If ip rtp quality-monitoring is not enabled, issuing this command will enable VQM without a scoring adjustment region.

(config)#ip rtp quality-monitoring udp Enables UDP packet inspection to determine if VQM should monitor RTP traffic. Use the no form of this command to disable monitoring. By default, VQM is disabled. Note: If ip rtp quality-monitoring is not enabled, issuing this command will enable VQM without a scoring adjustment region.

Optional (config)#ip rtp quality-monitoring jitter-threshold [early <ms> | late <ms>]

Sets the early and late jitter thresholds in milliseconds. This will indicate how many packets are deemed early or late. Changing the jitter threshold will not impact currently active calls, only the calls placed after the configuration change has taken place. Use the no form of this command to disable the jitter threshold. The default settings for the jitter threshold are early 10 and late 50. The range is 0 to 1000 ms.

Step 2 (config-eth 0/1)#rtp quality-monitoring Enables VQM on the selected interface. If the global command is disabled when this is enabled, the system will issue the following warning: “Applied but not used, you must globally enable ip rtp quality-monitoring to use VQM.” By default, VQM is enabled on all WAN and LAN interfaces.



Optional (config)#ip rtp quality-monitoring jitter-buffer [adaptive min <minimum> | nominal <nominal> | max <maximum>] | [fixed nominal <nominal> | jitter-buffer-size <size>]

Sets the jitter buffer type and configuration for the JBE that will generate the observable jitter statistics in RTP quality monitoring. The default is adaptive min 10 nominal 50 max 200.

adaptive min <minimum> Specifies the minimum accepted jitter buffer delay to be used by the jitter buffer. The range is 10 to 240 ms.nominal <nominal> Specifies the starting delay applied to packets in the jitter buffer. The range is 10 to 240 ms.max <maximum> Specifies the maximum delay that the adaptive jitter buffer will be allowed to use. The range is 40 to 320 ms.

fixed nominal <nominal> Specifies the actual fixed delay applied to the packet in the jitter buffer. The range is 4 to 250 ms. There is no default setting.jitter-buffer-size <size> Specifies the number of packets that the jitter buffer can hold. The range is 10 to 500 packets. There is no default setting.

Optional (config)#ip rtp quality-monitoring history [max-streams <history count> | lq-mos <value> | cq-mos <value> | pq-mos <value> | loss <value> | out-of-order <value> | jitter <value>]

As calls complete, settings configured using this command are examined to determine whether the call should be stored in the call history. The maximum number of streams to store may be configured; newer calls will replace the oldest calls when the call history is full. The MOS score, loss, out-of-order packets, and jitter can also be examined when a call completes. By default, all calls are stored in the call-history, however, if threshold values are changed from their defaults, only calls with poorer quality than the default thresholds will be stored. Use the no version of this command to reset the history count and thresholds. If entries exist over the history count, for example, if the limit was changed from 100 to 5, they will not be removed until the next call completes or the administrator issues a clear command. This command will act on call history data even with VQM disabled. The default history count is set to 100, and the thresholds are set to 0. By default, the MOS thresholds are set to 4.4.

Table 2. Command Summary Table (Continued)




max-streams <history count> Specifies the number of previously completed call statistics to store. This is a count of RTP streams; each call can contain two RTP streams. The range is 0 to 2000. lq-mos <value> Specifies a threshold (number) for the listening quality (LQ) MOS, and stores statistics for streams below this threshold. The range is 0 to 4.4. cq-mos <value> Specifies a threshold (number) for the conversational quality (CQ) MOS, and stores statistics for streams below this threshold. The range is 0 to 4.4. pq-mos <value> Specifies a threshold (number) for the listening quality MOS normalized to the PESQ (PQ) scale, and stores statistics for streams below this threshold. The range is 0 to 4.4. loss <value> Specifies a threshold (number) for loss (in packets). Streams experiencing more lost packets than this threshold are stored in the call history; otherwise, they are kept or discarded as dictated by the other thresholds. The range is 0 to 30000. out-of-order <value> Specifies a threshold (number) for out-of-order packets. Streams experiencing more out-of-order packets than this threshold are stored in the call history; otherwise, they are kept or discarded as dictated by the other thresholds. The range is 0 to 30000. jitter <value> Specifies a threshold (number) for the jitter. Streams experiencing greater jitter than this threshold are stored in the call history; otherwise, they are kept or discarded as dictated by the other thresholds. The range is 0 to 30000.

For a complete list of VQM commands, refer to the AOS Command Reference Guide located on your AOS Documentation CD shipped with your AOS product or available on the Web at www.adtran.com.

Table 2. Command Summary Table (Continued)




Step 2: Evaluate the VQM Metrics

The following examples are designed to enhance understanding and utilization of the VQM RTP Quality Metrics menus on the AOS GUI. Apply the techniques highlighted throughout this section to all the RTP Quality Metrics menus. The Clear Data, Download Data (.csv), and Refresh Data buttons are available on all the RTP Quality Metrics menus.

RTP Monitoring Summary

Use the Summary tab to view general statistics on RTP flows through AOS product(s). Select any section of the pie graph to view calls attributed to that section of the graph.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Summary tab to view a summary of the voice traffic statistics. Select the All Calls button to display a graph containing all RTP flows since the last reload or since Clear Data was conducted on the unit.

Figure 7. RTP Monitoring Summary Tab (All Calls)

Select Download Data (.csv) at any time (from any tab) to export the data in comma separated values (.csv) or extensible markup language (.xml) format.

Select Refresh Data to refresh the data for the current tab at any time (from any tab).

Select Clear Data at any time (from any tab) to clear all RTP monitoring data on the system (not just the data for the current tab).



2. Select the Calls in Record button to view a graph of all the RTP flows in the Past Calls record.

Figure 8. RTP Monitoring Summary Tab (Calls in Record)

3. Select the Active Calls button to view a graph of the currently active RTP flows on the unit.

Figure 9. RTP Monitoring Summary Tab (Active Calls)

This is the Active Calls button.

This is the Active Calls tab.



Past Calls Metrics

Use the Past Calls tab to view a chart that plots prior calls (by interface) over time. Select a color-coded interface below the graph to view statistics of past calls specific to that interface. Move your mouse over each data point to view detailed statistics. Use the slider bar to zoom in and out on data points plotted on the chart. Use the buttons, MOS, Jitter, Out of Order, Loss, and Delay, to sort the RTP quality statistical data displayed for each interface.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Past Calls tab. Select the MOS button to view MOS scores on all RTP streams for each enabled interface. See Table 1 on page 2 for voice quality ranges based on MOS scores. Notice in Figure 10, the vlan 4003 RTP streams are excellent, but several vlan 4001 RTP streams are poor.

Figure 10. RTP Monitoring Past Calls Tab (MOS)

Use the slider bar with color-coded interfaces to filter RTP streams (by time) in the Past Calls tab.

An example of a data point on the graph with a low MOS (1.86) that indicates poor voice quality. Use your mouse to hover over any data point throughout the RTP Quality Metrics menu tabs to see detailed information pertaining to that specific call. See Figure 11 on page 21 to view sample information available for each data point.

Use the search field to sort a large number of data points. Use your mouse to hover over the question mark symbol for examples of multiple term searches and valid filters.



Figure 11. Past Calls Tab Data Point

Use your mouse to hover over any data point to view statistics on inbound and outbound RTP streams. Select the data point by clicking on it. See Figure 12 to view information available for a selected RTP data point.

After selecting a data point, a display of statistics will appear. Use the Back to Chart button to return to the previous Past Calls menu.

Select the Extended button to view additional statistics on this data point.



Figure 12. Past Calls Tab Selected Data point

2. Select the Jitter button to view a chart that illustrates jitter experienced on the RTP streams of the past calls. Acceptable jitter is usually any data point below 150 ms that cannot be heard during voice calls.

Figure 13. RTP Monitoring Past Calls Tab (Jitter)

3. Select the Out of Order button to view a chart that illustrates packets received out of order on the RTP streams of the past calls.

Figure 14. RTP Monitoring Past Calls Tab (Out of Order)



4. Select the Loss button to view a chart that displays lost packets that occurred on each past call.

Figure 15. RTP Monitoring Past Calls Tab (Loss)

5. Select the Delay button to view a chart of delay that occurred on each past call.

Figure 16. RTP Monitoring Past Calls Tab (Delay)



Active Calls Metrics

Use the Active Calls tab to view a chart that plots live RTP streams. Use the legend below the chart to find specific calls. Move your mouse over each data point to view detailed statistics. Use the buttons, MOS, Jitter, Loss, and Delay, to sort the RTP voice quality statistical data occurring on each interface.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Active Calls tab. Select the MOS button to view a chart of MOS statistics on all live RTP streams. See Table 1 on page 2 for voice quality ranges based on MOS scores. All the Active Calls metrics are the same as Past Calls metrics, but they are for live RTP streams and the metrics are updated every 7 seconds. Once the call ends, it will appear in the Past Calls log.

Figure 17. RTP Monitoring Active Calls Tab (MOS)



2. Select the Jitter button to view a chart that illustrates jitter experienced on the RTP streams of the live calls.

Figure 18. RTP Monitoring Active Calls Tab (Jitter)

3. Select the Loss button to view a chart that displays any lost packets occurring during voice calls on the enabled interfaces.

Figure 19. RTP Monitoring Active Calls Tab (Loss)



4. Select the Delay button to view a chart of delay occurring on the live calls.

Figure 20. RTP Monitoring Active Calls Tab (Delay)



Extensions Metrics

Use the Extensions tab to view a chart with VQM statistical data sorted by extension numbers. Move your mouse over each data point to view detailed statistics. Use the buttons, MOS, Calls, Jitter, and Delay to sort the RTP statistical quality data recorded for each extension.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Extensions tab. Select the MOS button to view a chart of MOS statistics on all monitored extensions. See Table 1 on page 2 for voice quality ranges based on MOS scores.

Figure 21. RTP Monitoring Extensions Tab (MOS)

The Extensions tab is only available on the AOS voice products.



2. Select the Calls button to view a chart of calls sorted by each extension being monitored.

Figure 22. RTP Monitoring Extensions Tab (Calls)



3. Select the Jitter button to view a chart that illustrates jitter experienced on the RTP streams of the extensions being monitored.

Figure 23. RTP Monitoring Extensions Tab (Jitter)



4. Select the Delay button to view a chart of delay occurring on the extensions being monitored.

Figure 24. RTP Monitoring Extensions Tab (Delay)



Source IPs Metrics

Use the Source IPs tab to view a chart with VQM statistical data sorted by source IP address. Move your mouse over each data point to view detailed statistics. Use the buttons, MOS, Calls, Jitter, Loss, Delay, and Out of Order, to sort the RTP statistical quality data recorded for each interface.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Source IPs tab. Select the MOS button to view a chart of MOS statistics on all source IP RTP streams. See Table 1 on page 2 for voice quality ranges based on MOS scores.

Figure 25. RTP Monitoring Source IPs Tab (MOS)



2. Select the Calls button to view a pie chart of the number of calls per source IP address.

Figure 26. RTP Monitoring Source IPs Tab (Calls)

3. Select the Jitter button to view a chart that illustrates jitter on RTP streams sourced from the given IP addresses.

Figure 27. RTP Monitoring Source IPs Tab (Jitter)



4. Select the Loss button to view a chart that displays any lost packets occurring during voice calls on specific source IPs.

Figure 28. RTP Monitoring Source IPs Tab (Loss)

5. Select the Delay button to view a chart of delay experienced on the RTP streams sourced from the given IP addresses.

Figure 29. RTP Monitoring Source IPs Tab (Delay)



6. Select the Out of Order button to view a chart that illustrates packets received out of order on the RTP streams of the source IP addresses.

Figure 30. RTP Monitoring Source IPs Tab (Out of Order)



Interfaces Metrics

Use the Interfaces tab to view a chart with VQM statistical data sorted by individual interfaces. Move your mouse over each data point in any section of the graphs to view detailed statistics. Select a bar on any metric button to view additional statistics. Explore the buttons, MOS, Calls, Loss, Discarded, and Out of Order, to sort the RTP quality statistical data sorted by interface.

1. Navigate to Monitoring > Voice Quality > RTP Monitoring > Interfaces tab. Select the MOS button to view a chart of MOS statistics on specific interfaces. See Table 1 on page 2 for voice quality ranges based on MOS scores.

Figure 31. RTP Monitoring Interfaces Tab (MOS)



2. Select the Calls button to view bar graphs of the calls for specific interfaces.

Figure 32. RTP Monitoring Interfaces Tab (Calls)

3. Select the Loss button to view the bar graphs of lost packets that occurred on the specific interfaces.

Figure 33. RTP Monitoring Interfaces Tab (Loss)



4. Select the Discarded button to view bar graphs of discarded packets on the specific interfaces.

Figure 34. RTP Monitoring Interfaces Tab (Discarded)

5. Select the Out of Order button to view a chart that illustrates packets received out of order on the RTP streams of specific interfaces.

Figure 35. RTP Monitoring Interfaces Tab (Out of Order)

Troubleshooting Voice Quality Monitoring


Troubleshooting

VQM is primarily a troubleshooting feature. The example below illustrates using VQM to help identify the cause of voice quality issues on your network after viewing the reports (statistics).

Figure 36. RTP Voice Stream Monitoring Segment Points

In Figure 36, the RTP streams flow in both directions and both routers are using VQM. This figure illustrates the possible directions in the network to monitor in order to resolve detected voice quality issues or narrow the troubleshooting down to a specific segment.

The router at Site A monitors the inbound stream along Segment Y plus Segment Z (blue) up to the WAN interface, and the RTP stream along Segment X (gray) up to the LAN interface. The router at Site B monitors the inbound RTP stream along Segment X plus Segment Y (gray) up to the WAN interface, and the RTP stream along Segment Z (blue) up to the LAN interface.

Troubleshooting Tips and Scenarios

If issues occur with the voice quality on calls flowing through your AOS unit(s), here are a few tips to help you find where the issue(s) is occurring:

Review the RTP quality metric reports (refer to Step 2: Evaluate the VQM Metrics on page 18) or issue RTP quality CLI show commands (refer to Troubleshooting Command Summary on page 43) to identify the interface(s) and endpoint(s) with perceived voice quality issues.

Internet Service Provider

IP Phones

IP Phones

RTP Traffic flow from Site A to Site B

RTP Traffic flow from Site B to Site A

A3 A2 A1

Site A

NetVanta 1335

B3B2B1

Site B

NetVanta 1335

Segment X Segment Y Segment Z

RTP Voice Streams Inbound Interface VQM Monitoring

Voice Quality Monitoring Troubleshooting


If you discover poor RTP metrics on the WAN (public) interface packets, check the physical WAN interface for configuration and connectivity issues. If the LAN (private) interface does not show any errors, but the WAN interface is experiencing errors, contact your Internet Service Provider (ISP), report the errors, and request testing of their network to resolve the issues. Refer to GUI Interface Troubleshooting on page 41 and CLI Interface Troubleshooting on page 42 for example menus and output.

If you discover poor RTP metrics on the LAN (private) interface packets, check to see if the issues are specific to an endpoint. If so, test the endpoint for proper connectivity, functionality, and configuration. Also, check the interface configuration to make sure the interface negotiated the correct speed and duplex. If there are no errors, discards, or throttles and the configuration is correct, the AOS device is not causing the issues. Refer to GUI Interface Troubleshooting on page 41 and CLI Interface Troubleshooting on page 42 for example menus and output.

Lost Packets Troubleshooting Scenario

During a call between A1 and B1 in Figure 36 on page 38, A1 experienced poor voice quality and reports it to the ISP. Further investigation by the ISP discovers lost and out-of-order packets on the public segment of the network (Segment Y). This leads the ISP technician to suspect either the ISP’s uplink, the ISP’s network, or a specific endpoint as the source of the problem. If lost packets had been discovered on the customer’s segment of the network (Segment X), and Segment Y did not have errors, then the problem would have been on the customer’s network.

Check the public interface for errors, discards, or throttles to eliminate the AOS device as the source of any network issues. It is possible for the AOS device to drop packets due to interface errors, network load issues, or incorrect speed/duplex negotiations. If there are no dropped packets, errors, or throttles, and the speed and duplex settings are correct, the AOS device can be cleared in the troubleshooting exercise.

Next, the ISP technician can view the call history (Past Calls) to search for the source of the lost packets. Using the sort-by (loss) option, the technician can quickly identify specific endpoints with errors. If only one endpoint has errors, that particular endpoint or connection is faulty. If multiple endpoints have errors, the problem is most likely a general issue with the uplink to the ISP (network congestion due to provisioning or other errors). A traceroute can be performed from the AOS device to the endpoint to determine on which portion of the network the problem occurs.

Jitter Troubleshooting Scenario

In Figure 36 on page 38, several phone users at Site B are complaining of choppy voice connections. After viewing the VQM statistics for the inbound RTP traffic at Site B, the site technician discovers jitter problems on the public interface only (no jitter on the private interface). The cause of the jitter problem is narrowed down to the ISP’s uplink, the ISP network, or a specific endpoint on the far end. If there had been jitter problems on the private interface, the technician would have suspected an issue with Site B’s network or endpoints.

To determine the source of the jitter, the technician sorts by jitter the RTP streams stored in the call history (Past Calls) to determine if the public network (in general) is the cause, or if it is a specific endpoint within the network. If a specific endpoint has a problem, the jitter errors will only appear on that particular RTP source (endpoint). If the network in general is the cause, jitter errors will be present on multiple RTP sources (endpoints). A potential source of jitter is a device with misconfigured QoS.



Loopback Account Troubleshooting

The loopback account feature is a diagnostic tool that allows the system administrator to set up a voice account similar to a user account. The loopback account will automatically answer any call received based on the number of rings. Calls can also be originated and terminated from the loopback account via the CLI commands. Active voice loopbacks will return RTP streams back to the remote site for monitoring. The system allows up to five simultaneously active loopback calls for troubleshooting purposes. In conjunction with VQM, the loopback account RTP packets from a remote phone or device are quickly analyzed. This process allows the administrator to test round-trip network connectivity from a remote site and judge the quality of the connection with the provided VQM metrics. Once the loopback call is placed, the system administrator can use the VQM feature to diagnose voice quality issues or listen to the quality of the voice echoed back on a call into the loopback account.

Loopback Account Quick Configuration

Unlike user accounts, loopback accounts can only be created through CLI configuration and a few of the commands have slightly different functions. The majority of the loopback account commands are identical to the user (station) account commands with the following exceptions:

appearances specifies the maximum number of simultaneous calls with the account. The default is 1.

caller-id [name | number] specifies the name and number on the account. The default is the specified extension number used to create the account.

num-rings specifies the number of rings prior to the loopback account answering a call. The default is 0.

shutdown disables the account. Calls into the account will not be answered when disabled.

The following example shows how to create a loopback account. Replace all underlined entries (example) with your specific parameters. Refer to the Loopback Account Command Set in the AOS Command Reference Guide located on your AOS Documentation CD shipped with your unit or on the Web at www.adtran.com for detailed descriptions of all the available loopback commands.

>enable#configure terminal(config)#voice loopback 5555

Configuring New Loopback Account “5555”.

! Assign an existing CODEC group (created with the codec-list command), assign the SIP identity, and register the loopback account with the SIP trunk.(config-LB-5555)#codec-group users(config-LB-5555)#sip-identity 5555 T02 register auth-name admin password word(config-LB-5555)#caller-id name Test108(config-LB-5555)#exit(config)#exit

! Execute the command below to begin the loopback test call.#voice loopback-call start from 5555 to 959-1234 Initiating loopback call id 5555!The system attempts a call from the loopback account 5555 to the specified number 959-1234. The system returns the ID of the call that can be used to terminate the loopback call.

Voice Quality Monitoring Troubleshooting


!Use the command below to check the status of the loopback call.

#show voice loopback calls! Use the command below to end the loopback test call. #voice loopback-call stop [account | all | id]

Example 1: GUI Interface Troubleshooting

Navigate to System > Physical Interfaces and select the VoIP LAN interface and view the Port Statistics.

Figure 37. Physical Interfaces Port Statistics



Example 2: CLI Interface Troubleshooting

Issue the show interface <interface name> command at the Global command prompt (#).

Sample Output:

#show interface eth 0/24eth 0/24 is UP, line protocol is UP

Hardware address is 00:A0:C8:00:97:1A 100Mb/s, negotiated full-duplex, configured full-duplex ARP type: ARPA; ARP timeout is 20 minutes 5 minute input rate 1440 bits/sec, 3 packets/sec 5 minute output rate 160 bits/sec, 0 packets/sec

Queueing method: fifo Output queue: 0/256/0 (size/max total/drops) 7550726 packets input, 497595536 bytes 9436 unicasts, 52208 broadcasts, 149050 multicasts input 0 unknown protocol, 0 symbol errors, 0 discards 0 input errors, 0 runts, 0 giants 0 no buffer, 0 overruns, 0 internal receive errors 0 alignment errors, 0 crc errors 104393 packets output, 22096113 bytes 5309 unicasts, 513 broadcasts, 98571 multicasts output 0 output errors, 0 deferred, 0 discards 0 single, 0 multiple, 0 late collisions 0 excessive collisions, 0 underruns 0 internal transmit errors, 0 carrier sense errors 0 resets, 0 throttles

Voice Quality Monitoring Troubleshooting Command Summary


Troubleshooting Command Summary

After configuring VQM in the CLI, several different commands can be issued from the Enable mode prompt to assist in troubleshooting VoIP issues. Use the summary of show commands in Table 3. For a complete list of VQM show commands, refer to the Enable Mode Command Set in the AOS Command Reference Guide located on your AOS Documentation CD shipped with your unit or on the Web at www.adtran.com.

The output of all show commands can be limited by appending the following modifiers to the end of the command: | begin <text>, | exclude <text>, and | include <text>. The include modifier limits output to lines that contain the specified text, the exclude modifier excludes any lines with the specified text, and the begin modifier displays the first line of output with the specified text and all lines thereafter.

Table 3. AOS VQM Show and Clear Commands

Command Explanation

#show ip rtp quality-monitoring Displays a summary of VQM statistics.

#show ip rtp quality-monitoring active-calls [sort-by [loss | out-of-order | jitter | mos-pq | mos-lq]] [degradation | detail]

Displays per call statistics for currently active calls. This command will not display any statistics when VQM is disabled.sort-by [loss | out-of-order | jitter | mos-pq | mos-lq] Specifies the metric to use when sorting active calls. Calls with poorer quality metrics will appear first. If no sort-by metric is chosen, calls are sorted by start time with the most recent calls appearing first.degradation Displays possible sources of voice-quality degradation.detail Displays all available statistics. By default, only commonly useful statistics are shown since detail is not activated.

#show ip rtp quality-monitoring call-history [sort-by [loss | out-of-order | jitter | mos-pq | mos-lq]] [degradation | detail]

Displays per call statistics for completed calls in the call history. The call history is still available when VQM is disabled.sort-by [loss | out-of-order | jitter | mos-pq | mos-lq] Specifies the metric to use when sorting the call history. Calls with poorer quality metrics will appear first. If no sort-by metric is chosen, calls are sorted by start time with the most recent calls appearing first.degradation Displays possible sources of voice-quality degradation.detail Displays all available statistics. When detail is not appended, only commonly useful statistics are presented.

Troubleshooting Command Summary Voice Quality Monitoring


#show ip rtp quality-monitoring endpoints [sort-by [loss | out-of-order | jitter | pq-mos | lq-mos]]

Aggregates previous call statistics per endpoint (the source IP address of the RTP stream). When sorted, endpoints with poorer quality metrics will appear first. Issuing this command will display previously collected endpoint statistics even with VQM disabled.sort-by [loss | out-of-order | jitter | pq-mos | lq-mos] Specifies the metric to use when sorting endpoint statistics. Calls with poorer quality metrics will appear first.

#show ip rtp quality-monitoring endpoints summary

Aggregates previous call statistics per endpoint (the source IP address of the RTP stream). This command displays a summary of RTP streams on each endpoint. The RTP streams are placed in Excellent, Good, Fair, and Poor categories. Issuing this command will display previously collected endpoint statistics even with VQM disabled.

#show ip rtp quality-monitoring interface [<interface name> | sort-by [loss | out-of-order | jitter | pq-mos | lq-mos]] [detail]

Displays statistics for the specified interface. Displays the statistics using <interface name>, or a metric by which to sort when multiple interfaces are enabled. sort-by [loss | out-of-order | jitter | pq-mos | lq-mos] Specifies the metric to use when sorting. Calls with poorer quality metrics will appear first.detail Displays all available statistics. When detail is not appended, only commonly useful statistics are presented. By default, only commonly useful statistics are shown. These statistics are aggregated only from calls saved in the call history. This command is not valid when VQM is disabled.

#show ip rtp quality-monitoring interface [<interface name>] summary

Displays statistics for the specified interface. Choosing a specific interface to display using the <interface name> is optional. Use the summary subcommand to view the general voice quality stream statistics on the interface(s). These statistics are aggregated only from calls saved in the call history. This command is not valid when VQM is disabled.

#show ip rtp quality-monitoring call-history[to-uri <to-uri substring>] [from-uri <from-uri-substring>] [call-id <call-id-substring>] [sort-by [loss | out-of-order | jitter | mos-pq | mos-lq]] [degradation | detail]

Displays per call statistics for completed calls in the call history based on known information about the call. Any substring of the To URI, the From URI, and/or the Call-ID fields can be used in this query. The calls reported can also be sorted by the available metrics. This command will act on call history data even with VQM disabled.sort-by [loss | out-of-order | jitter | mos-pq | mos-lq] Specifies the metric to use when sorting. Calls with poorer quality metrics will appear first.degradation Displays possible sources of voice-quality degradation.detail Displays all available statistics. When detail is not appended, only commonly useful statistics are presented. By default, only commonly useful statistics are shown.

Table 3. AOS VQM Show and Clear Commands (Continued)

Command Explanation

Voice Quality Monitoring Troubleshooting Command Summary


#show ip rtp quality-monitoring endpoints [sort-by [loss | out-of-order | jitter | pq-mos | lq-mos]]

Aggregates previous call statistics per endpoint (the source IP address of the RTP stream). When sorted, endpoints with poorer quality metrics will appear first. Issuing this command will display previously collected endpoint statistics even with VQM disabled.sort-by [loss | out-of-order | jitter | pq-mos | lq-mos] Specifies the metric to use when sorting endpoint statistics. Calls with poorer quality metrics will appear first.

#show ip rtp quality-monitoring endpoints summary

Aggregates previous call statistics per endpoint (the source IP address of the RTP stream). This command displays a summary of RTP streams on each endpoint. The RTP streams are placed in Excellent, Good, Fair, and Poor categories. Issuing this command will display previously collected endpoint statistics even with VQM disabled.

#show ip rtp quality-monitoring interface [<interface name> | sort-by [loss | out-of-order | jitter | pq-mos | lq-mos]] [detail]

Displays statistics for the specified interface. Displays the statistics using <interface name>, or a metric by which to sort when multiple interfaces are enabled. sort-by [loss | out-of-order | jitter | pq-mos | lq-mos] Specifies the metric to use when sorting. Calls with poorer quality metrics will appear first.detail Displays all available statistics. When detail is not appended, only commonly useful statistics are presented. By default, only commonly useful statistics are shown. These statistics are aggregated only from calls saved in the call history. This command is not valid when VQM is disabled.

#show ip rtp quality-monitoring interface [<interface name>] summary

Displays statistics for the specified interface. Choosing a specific interface to display using the <interface name> is optional. Use the summary subcommand to view the general voice quality stream statistics on the interface(s). These statistics are aggregated only from calls saved in the call history. This command is not valid when VQM is disabled.

#show ip rtp quality-monitoring call-history[to-uri <to-uri substring>] [from-uri <from-uri-substring>] [call-id <call-id-substring>] [sort-by [loss | out-of-order | jitter | mos-pq | mos-lq]] [degradation | detail]

Displays per call statistics for completed calls in the call history based on known information about the call. Any substring of the To URI, the From URI, and/or the Call-ID fields can be used in this query. The calls reported can also be sorted by the available metrics. This command will act on call history data even with VQM disabled.sort-by [loss | out-of-order | jitter | mos-pq | mos-lq] Specifies the metric to use when sorting. Calls with poorer quality metrics will appear first.degradation Displays possible sources of voice-quality degradation.detail Displays all available statistics. When detail is not appended, only commonly useful statistics are presented. By default, only commonly useful statistics are shown.


Command Explanation

Troubleshooting Command Summary Voice Quality Monitoring


#clear ip rtp quality-monitoring [interface <interface name> | call-history]

Clears the various VQM statistics. If no arguments are specified, all calls will be removed from the call history and all interfaces will be reset.interface Resets interface statistics for the specified interface. If no interface is specified, all interface statistics are reset.call-history Removes all calls from the call history.

#clear ip rtp quality-monitoring [interface <interface name> | call-history]

Clears the various VQM statistics. If no arguments are specified, all calls will be removed from the call history and all interfaces will be reset.interface Resets interface statistics for the specified interface. If no interface is specified, all interface statistics are reset.call-history Removes all calls from the call history.


Command Explanation

Voice Quality Monitoring Appendix A. AOS VQM Statistics Descriptions


Appendix A. AOS VQM Statistics Descriptions

The following is CLI sample output of various show commands that display AOS VQM statistics for RTP streams. The statistic names shown in blue italics are defined in this appendix starting on page 49. The VQM statistics below represent a number or string in true sample output information.

Sample Output#show ip rtp quality-monitoring [call-history | active calls]RTP stream: VqmRtpSourceIp:VqmRtpSourcePort, VqmSourceIntName ->

VqmRtpDestIp:VqmRtpDestPort, VqmDestIntNameRTP is sourced from VqmRtpSourceUriTo: VqmToFrom: VqmFrom Call-start (duration): VqmCallStart (VqmCallDurationMs ms) MOS LQ: VqmMosLq MOS PQ: VqmMosPq Loss: VqmPktsLostTotal pkts Out-of-order: VqmOutOfOrder pkts Jitter: VqmPdvAverageMs ms CODEC: VqmCodec Resyncs: VqmResyncCount Simulated jitter buffer delay (current/min/max):

VqmDelayCurrentMsec/VqmDelayMinMsec/VqmDelayMaxMsec ms

#show ip rtp quality-monitoring [call-history | active calls] detailRTP stream: VqmRtpSourceIp:VqmRtpSourcePort, VqmSourceIntName ->

VqmRtpDestIp:VqmRtpDestPort, VqmDestIntNameRTP is sourced from VqmRtpSourceUriTo: VqmToFrom: VqmFrom Call-ID: VqmCallid CCM-ID: VqmCcmid, SSRC: VqmSsrcid Call-start (duration): VqmCallStart (VqmCallDurationMs ms) PDV (avg/max): VqmPdvAverageMs/VqmJitterMaximum ms CODEC: VqmCodec, VqmBitrate bps DSCP: VqmDscp External delay sources: round trip delay (inst/avg/max): VqmRtDelayInst/VqmRtDelayAverage/VqmRtDelayMaximum ms One-way delay (inst/avg/max):

VqmOnewayDelayInst/VqmOnewayDelayAverage/VqmOnewayDelayMaximum ms Origination delay (inst/avg/max): VqmOrigDelayInst/VqmOrigDelayAverage/VqmOrigDelayMaximum

ms Termination delay (min/avg/max):

VqmTermDelayMinimum/VqmTermDelayAverage/VqmTermDelayMaximum ms Quality: R (LQ/CQ/G.107/Nominal): VqmRLq/VqmRCq/VqmRG107/VqmNominal MOS (LQ/CQ/PQ/Nominal): VqmMosLq/VqmMosPq/VqmMosCq/VqmMosNominal Degradation: (the following will be sorted in descending order) Packet loss: VqmDegLoss%

Appendix A. AOS VQM Statistics Descriptions Voice Quality Monitoring


Simulated jitter buffer discard: VqmDegDiscard% Voice encode/decoder selection: VqmDegVocoder% Recency: VqmDegRecency% Delay: VqmDegDelay% Signal level: VqmDegSignallvl% Noise level: VqmDegNoiselvl% Echo level: VqmDegEcholvl% Burst / Gap / Loss: R-LQ (during burst): VqmBurstRLq Burst count: VqmBurstCount Avg burst loss rate: VqmBurstLossRateAvg% Avg burst length: VqmBurstLenAvgPkts pkts (VqmBurstLenAvgMsec ms) Burst excess: VqmExcessBurst ms R-LQ (during gap): VqmGapRLq Gap count: VqmGapCount Avg gap loss rate: VqmGapLossRateAvg% Avg gap length: VqmGapLenAvgPkts pkts (VqmGapLenAvgMsec ms) Burst excess: VqmExcessGap ms Avg loss rate: VqmLossRateAvg% Avg discard rate: VqmDiscardRateAvg% Avg network loss rate: VqmNetworkLossAvg% Simulated jitter buffer: Configuration: VqmJitterBufferType (min/nom/max): VqmJbCfgMin/VqmJbCfgNom/VqmJbCfgMax ms PPDV (jitter): VqmPpdvMsec ms Early threshold: VqmEarlyThreshMs ms Early percentile: PVqmEarlyThreshPc Early count (under threshold/total): VqmEarlyUnderThresh/VqmEarlyTotalCount pkts Early peak: VqmEarlyPeakJitterMs ms Late threshold: VqmLateThreshMs ms Late percentile: PVqmLateThreshPc Late count (under threshold/total): VqmLateUnderThresh/VqmLateTotalCount pkts Late peak: VqmLatePeakJitterMs ms Adaptive Increases/Decreases: VqmDelayIncreaseCount/VqmDelayDecreaseCount Resyncs: VqmResyncCount Simulated jitter buffer delay (current/min/max):

VqmDelayCurrentMsec/VqmDelayMinMsec/VqmDelayMaxMsec ms Packets (rx/lost/out of seq/duplicate):

VqmPktsRcvdTotal/VqmPktsLostTotal/VqmOutOfOrder/VqmDuplicatePkts Packets (early/late): VqmEarlyPkts/VqmLatePkts Discards (total/overrun/underrun):

VqmPktsDiscardedTotal/VqmOverrunDiscardPkts/VqmUnderrunDiscardPkts External Quality Metrics: External R-LQ in: VqmExtRLqIn External R-LQ out: VqmExtRLqOut External R-CQ in: VqmExtRCqIn External R-CQ out: VqmExtRCqOut Fax / Modem Metrics: Estimated throughput: VqmThroughPutIndex bps Reliability index (0-100): VqmReliabilityIndex



Adtran VQM StatisticsVqmRtpSourceIp is the source IP address of this Realtime Transport Protocol (RTP) stream. If network address translation (NAT) is involved, private side addresses and ports are reported. For source NAT, the address and port before NAT are reported. For destination NAT, the address and port after NAT are reported.

VqmRtpSourcePort is the source port of this RTP stream. If NAT is involved, private side addresses and ports are reported. For source NAT, the address and port before NAT are reported. For destination NAT, the address and port after NAT are reported.

VqmSourceIntName is the interface at which RTP arrived inbound to the unit; RTP is monitored at this inbound interface.

VqmRtpDestIp is the destination IP address of this RTP stream. If NAT is involved, private side addresses and ports are reported. For source NAT, the address and port before NAT are reported. For destination NAT, the address and port after NAT are reported.

VqmRtpDestPort is the destination port of this RTP stream. If NAT is involved, private side addresses and ports are reported. For source NAT, the address and port before NAT are reported. For destination NAT, the address and port after NAT are reported.

VqmDestIntName is the destination interface for this RTP stream.

VqmRtpSourceUri is the URI of the sender of the RTP; this is always either the To URI or the From URI. It may be the case (such as for RTP from a music on hold server) that the source URI is incorrect; in this case it will correspond to the direction in which the URI is located in the network. If call signaling is not being monitored, this value will be unavailable.

VqmTo is the To URI from the Session Initiation Protocol (SIP) signaling, or the extension was dialed. If call signaling is not being monitored, this value may be unknown.

VqmFrom is the From URI from the SIP signaling, or the extension originating the call. If call signaling is not being monitored, this value may be unknown.

VqmCallStart is the time that monitoring began on this RTP stream.

VqmCallDurationMs is the time in milliseconds from when monitoring began on this RTP stream until the reception of the last RTP packet on this stream.

VqmMosLq is the listening quality MOS. Listening quality indicates the perceived quality of the transmission for a user not actively involved in the conversation, but passively listening. Listening quality does not consider delay or recency.

VqmMosPq is the listening quality MOS normalized to the PESQ scale. Users interested in scoring based on the ITU-T recommendation P.862 (PESQ) should use this value.

VqmPktsLostTotal is the total number of packets determined to be lost in the network by the jitter buffer.

VqmOutOfOrder is the total number of packets that arrive at the jitter buffer out of sequence.

VqmPdvAverageMs is the maximum instantaneous packet delay variation (PDV) for packets in the RTP stream, reported in milliseconds.



VqmCodec is the last voice CODEC detected in this RTP stream. Note that an endpoint may change the voice CODEC mid-stream.

VqmResyncCount is the total number of jitter buffer resynchronizations caused by discontinuous transmission (DTX), voice activity detection (VAD), or silence suppression.

VqmDelayCurrentMsec is the current jitter buffer delay in milliseconds, or, in the case of an RTP stream in the call-history, the last jitter buffer delay. (This does not apply to a fixed jitter buffer configuration.)

VqmDelayMinMsec is the minimum jitter buffer delay in milliseconds. (This does not apply to a fixed jitter buffer configuration.)

VqmDelayMaxMsec is the maximum jitter buffer delay in milliseconds. (This does not apply to a fixed jitter buffer configuration.)

Detailed Statistics are some of the statistics listed above in the basic statistics, also appear in the detailed statistics; those that appear only in the detailed view are listed below.

VqmCallid is the SIP call ID read only by the SIP proxy; this value may be unknown if using the B2BUA or call signaling is not being monitored.

VqmCcmid is an internally generated ID identifying this call.

VqmSsrcid is the synchronization source ID (SSRC) for this stream. RFC 3550 defines this as a randomly generated 32-bit number that is globally unique within an RTP session.

VqmJitterMaximum is the maximum instantaneous packet delay variation (PDV) for packets in the RTP stream, reported in milliseconds.

VqmBitrate is the actual bitrate of the RTP stream, calculated using the size of each RTP packet in bits and the duration of audio represented in each packet. This value can give an idea of how much bandwidth is required for this RTP stream.

VqmDscp is the differentiated services code point (DSCP) value recorded in the IP header of RTP packets in this stream. The DSCP displayed is taken from the first RTP packet in this stream, and is refreshed whenever the voice CODEC changes. This value can be useful when troubleshooting QoS in the path of the RTP stream.

Delay Metrics

VqmRtDelayInst is the instantaneous round trip delay. This may be obtained from RTCP XR or SR reports, or, if no reports are available, from an average of ICMP echo or timestamp requests sent to both endpoints. If no report information is available and round trip delay cannot be determined from ICMP (e.g., a firewall in the path did not allow the traffic), this statistic will be reported as unavailable.

VqmRtDelayAverage is the average round trip delay. This is obtained from all available information, including RTCP XR and SR reports and from an average of ICMP echo or timestamp requests sent to both endpoints. If no report information is available and round trip delay cannot be determined from ICMP (e.g., a firewall in the path did not allow the traffic), this statistic will be reported as unavailable.



VqmRtDelayMaximum is the maximum round trip delay. This is obtained from all available information, including RTCP XR and SR reports and from an average of ICMP echo or timestamp requests sent to both endpoints. If no report information is available and round trip delay cannot be determined from ICMP (e.g., a firewall in the path did not allow the traffic), this statistic will be reported as unavailable.

VqmOnewayDelayInst is the instantaneous one-way delay, including any delay that can be introduced by the jitter buffer. The calculation for this statistic assumes that round trip delay is symmetric. If round trip delay is unavailable, this statistic will also be unavailable.

VqmOnewayDelayAverage is the average one-way delay, including any delay that can be introduced by the jitter buffer. The calculation for this statistic assumes that round trip delay is symmetric. If round trip delay is unavailable, this statistic will also be unavailable.

VqmOnewayDelayMaximum is the maximum one-way delay, including any delay that can be introduced by the jitter buffer. The calculation for this statistic assumes that round trip delay is symmetric. If round trip delay is unavailable, this statistic will also be unavailable.

VqmOrigDelayInst is the instantaneous origination point end-system delay. This value is obtained from RTCP XR reports. If no reports are available, this statistic will be unavailable.

VqmOrigDelayAverage is the average origination point end-system delay. This value is obtained from RTCP XR reports. If no reports are available, this statistic will be unavailable.

VqmOrigDelayMaximum is the maximum origination point end-system delay. This value is obtained from RTCP XR reports. If no reports are available, this statistic will be unavailable.

VqmTermDelayMinimum is the instantaneous termination point end-system delay. Computation of this delay involves delay introduced by the jitter buffer and voice CODEC-specific delay related to sampling and encoding.

VqmTermDelayAverage is the average termination point end-system delay. Computation of this delay involves delay introduced by the jitter buffer and voice CODEC-specific delay related to sampling and encoding.

VqmTermDelayMaximum is the maximum termination point end-system delay. Computation of this delay involves delay introduced by the jitter buffer and voice CODEC specific delay related to sampling and encoding.

Quality Metrics

VqmRLq is the listening quality R factor. Listening quality indicates the perceived quality of the transmission for a user not actively involved in the conversation, but passively listening. Listening quality does not consider delay or recency. Some users may prefer R factor measurements to MOS scores, since MOS scales may differ based on the CODEC type and region of deployment, whereas R factor measurements are consistent across CODECs and regions.



VqmRCq is the conversational quality R factor. Conversational quality indicates the impact of the quality of the transmission on the dynamics of conversational exchanges between two parties; such metrics take into account delay, echo, and recency. For example, for a link with a large delay, participants in a conversation might frequently find themselves interrupting each other and talking over each other, since one party will be unable to perceive when the other party has started talking. Some users may prefer R factor measurements to MOS, since MOS scales may differ based on the CODEC type and region of deployment, whereas R factor measurements are consistent across CODECs and regions.

VqmRG107 is the G.107 R factor. Users interested in the R factor score based exclusively on the ITU G.107 E model should use this value. Some users may prefer R factor measurements to MOS, since MOS scales may differ based on the CODEC type and region of deployment, whereas R factor measurements are consistent across CODECs and regions.

VqmRNominal is the nominal or generally accepted maximum obtainable R factor for this RTP stream. The nominal value may change based on the CODEC used. Some users may prefer R factor measurements to MOS, since MOS scales may differ based on the CODEC type and region of deployment, whereas R factor measurements are consistent across CODECs and regions.

VqmMosCq is the conversational quality MOS. Conversational quality indicates the impact of the quality of the transmission on the dynamics of conversational exchanges between two parties; such metrics take into account delay, echo, and recency. For example, for a link with a large delay, participants in a conversation might frequently find themselves interrupting each other and talking over each other, since one party will be unable to perceive when the other party has started talking.

VqmMosNominal is the nominal, or generally accepted maximum obtainable MOS for this RTP stream. The nominal value may change based on CODEC used.

Degradation Metrics

VqmDegLoss reports an estimated percentage of the overall degradation in quality caused by network packet loss.

VqmDegDiscard reports an estimated percentage of the overall degradation in quality caused by discards by the jitter buffer.

VqmDegVocoder reports an estimated percentage of the overall degradation in quality caused by the voice CODEC selection.

VqmDegRecency reports an estimated percentage of the overall degradation in quality caused by loss or discard recency. Participants in a conversation are likely to be more forgiving of quality degradation occurring near the beginning of a call that later resolves than they are to be forgiving of quality degradation occurring near the end of a call.

VqmDegDelay reports an estimated percentage of the overall degradation in quality caused by delay.

VqmDegSiglvl reports an estimated percentage of the overall degradation in quality caused by low speech energy signal level.

VqmDegNoiselvl reports an estimated percentage of the overall degradation in quality caused by high noise levels.



VqmDegEcholvl reports an estimated percentage of the overall degradation in quality caused by high echo levels.

Burst, Gap, and Loss Metrics

VqmBurstRLq is the average listening quality R factor while the stream is in a burst condition. A stream is in a burst condition if two or more successive voice encoder/decoder frames have been lost or discarded. (Note that a stream is always in either a burst or a gap condition.)

VqmBurstCount is the number of times the given stream was in a burst condition during the call. A stream is in a burst condition if two or more successive voice encoder/decoder frames have been lost or discarded. (Note that a stream is always in either a burst or a gap condition.)

VqmBurstLossRateAvg is the total average percentage of voice encoder/decoder frames lost or discarded while in burst conditions. A stream is in a burst condition if two or more successive voice encoder/decoder frames have been lost or discarded. (Note that a stream is always in either a burst or a gap condition.)

VqmBurstLenAvgPkts is the average burst length in packets. A stream is in a burst condition if two or more successive voice encoder/decoder frames have been lost or discarded. (Note that a stream is always in either a burst or a gap condition.)

VqmBurstLenAvgMsec is the average burst length in milliseconds. A stream is in a burst condition if two or more successive voice encoder/decoder frames have been lost or discarded. (Note that a stream is always in either a burst or a gap condition.)

VqmExcessBurst is the total length (in milliseconds) of speech lost during burst conditions not handled effectively by packet loss concealment.

VqmGapR is the average listening quality R factor while the stream is in a gap condition. A stream is in a gap condition if 16 voice encoder/decoder frames are received without any intervening lost or discarded frames. (Note that a stream is always in either a burst or a gap condition.)

VqmGapCount is the number of times the given stream was in a gap condition during the call. A stream is in a gap condition if 16 voice encoder/decoder frames are received without any intervening lost or discarded frames. (Note that a stream is always in either a burst or a gap condition.)

VqmGapLossRateAvg is the total average percentage of voice encoder/decoder frames lost or discarded while in gap conditions. A stream is in a gap condition if 16 voice encoder/decoder frames are received without any intervening lost or discarded frames. (Note that a stream is always in either a burst or a gap condition.)

VqmGapLenPkts is the average gap length in packets. A stream is in a gap condition if 16 voice encoder/decoder frames are received without any intervening lost or discarded frames. (Note that a stream is always in either a burst or a gap condition.)

VqmGapLenMsec is the average gap length in milliseconds. A stream is in a gap condition if 16 voice encoder/decoder frames are received without any intervening lost or discarded frames. (Note that a stream is always in either a burst or a gap condition.)

VqmExcessGap is the total length (in milliseconds) of speech lost during gap conditions not handled effectively by packet loss concealment.



VqmLossRateAvg is the total average percentage of voice encoder/decoder frames lost or discarded, regardless of burst or gap conditions. (This is a sum of the average network loss rate and the average discard rate.)

VqmDiscardRateAvg is the total average percentage of voice encoder/decoder frames as discarded by the jitter buffer.

VqmNetworkLossAvg is the total average percentage of voice encoder/decoder frames lost in the network. Note that this does not include frames that are discarded by the jitter buffer. If this percentage is very small when compared with the overall average loss rate, examine your jitter buffer configuration. If it is large, examine the network to determine the source of the loss.

Simulated Jitter Buffer Metrics

VqmJitterBufferType is the configured jitter buffer type for this RTP stream, either adaptive or fixed. An adaptive jitter buffer dynamically varies the delay from packet reception to packet playback; a fixed jitter buffer uses the same delay for each packet. This is a jitter buffer; no packets are actually being discarded.

VqmJbCfgMin is the minimum delay that will be applied to packets received when using an adaptive jitter buffer.

VqmJbCfgNom is the value that represents the initial delay that will be used to apply to received packets when using an adaptive jitter buffer. When using a fixed jitter buffer, this represents the delay that will be applied to each packet when it is received.

VqmJbCfgMax is the value that represents an upper bound on the delay that will be applied to received packets when using an adaptive jitter buffer. When using a fixed jitter buffer, this represents the maximum number of packets that can be inserted into the buffer. (Subsequently, inserted packets will be discarded.)

VqmPpdvMsec is the packet-to-packet delay variation (jitter) in milliseconds, as defined in RFC 3550.

VqmEarlyThreshMs is the early threshold in milliseconds; this is a configured value. Early packets arriving under this threshold will not be discarded by the jitter buffer as early.

VqmEarlyThreshPc is the percentage of total packets (including both early and late packets) not judged as being under the early jitter threshold.

VqmEarlyUnderThresh is a count of early packets that arrived under the configured early jitter threshold (of the total count of early packets).

VqmEarlyTotalCount is the total count of early packets arriving before the expected delay. (This count is not necessarily the same as the count of early packets listed below, that is based on the first reference packet.)

VqmEarlyPeakJitterMs is the largest jitter encountered among packets counted as early (the total of which is given as the total early count under the jitter buffer statistics).

VqmLateThresholdMs is the late threshold in milliseconds; this is a configured value. Late packets arriving under this threshold will not be discarded by the jitter buffer as late.

VqmLateThresholdPc is the percentage of total packets (including both early and late packets) not judged as being under the late jitter threshold.



VqmLateUnderThresh is a total count of packets that arrived under the configured late jitter threshold (of the total count of late packets).

VqmLateTotalCount is the total count of late packets arriving after the expected delay. (This count is not necessarily the same as the count of late packets listed below, that is based on the first reference packet.)

VqmLatePeakJitterMs is the largest jitter encountered among packets counted as late (the total of which is given as the total late count under the jitter buffer statistics).

VqmDelayIncreaseCount is the total number of jitter buffer delay increases. (This applies to adaptive mode only.)

VqmDelayDecreaseCount is the total number of jitter buffer delay increases. (This applies to adaptive mode only.)

VqmPktsRcvdTotal is the total number of packets received by the jitter buffer.

VqmDuplicatePkts is the total number of duplicate packets for this RTP stream discarded by the jitter buffer.

VqmEarlyPkts is the total number of packets for this RTP stream arriving early (prior to anticipated packet arrival). Each packet is classified as either late or early, with the exception of the first packet, treated as a reference packet. (This count is not necessarily the same as the count shown above under the jitter buffer statistics.)

VqmLatePkts is the total number of packets for this RTP stream arriving late (after anticipated packet arrival). Each packet is classified as either late or early, with the exception of the first packet, treated as a reference packet. (This count is not necessarily the same as the count shown above under the jitter buffer statistics.)

VqmPktsDiscardedTotal is the total number of packets discarded by the jitter buffer.

VqmOverrunDiscardPkts is the total number of packets discarded by the jitter buffer due to jitter buffer overrun.

VqmUnderrunDiscardPkts is the total number of packets discarded by the jitter buffer due to jitter buffer underrun.

External Quality Metrics

VqmExtRLqIn is the external listening quality R factor (in), as determined from an RTCP XR report (RFC 3611) and RTCP-HR, currently in draft. It represents the listening quality R factor incoming to the other side of this endpoint; the other side may be an external PCM or cellular network. For example, suppose VQM were deployed in the following network: Phone A <-- VQM --> Bridge <--> Phone B. For RTCP XR reports sent from Bridge to Phone A, the external LQ R factor (in) would represent quality for RTP flowing from Phone B to Bridge. If no applicable reports are received, this statistic will be unavailable.



VqmExtRLqOut is the external listening quality R factor (out), as determined from an RTCP XR report (RFC 3611) and RTCP-HR, currently in draft. This measurement is copied from an RTCP XR message received from a remote endpoint on the other side of this endpoint. For example, suppose VQM were deployed in the following network: Phone A <-- VQM --> Bridge <--> Phone B. For RTCP XR reports sent from Bridge to Phone A, the external LQ R factor (out) would represent quality for RTP flowing from Bridge to Phone B. If no applicable reports are received, this statistic will be unavailable.

VqmExtRCqIn is the external conversational quality R factor (in), as determined from an RTCP XR report (RFC 3611) and RTCP-HR, currently in draft. It represents the conversational quality R factor incoming to the other side of this endpoint; the other side may be an external PCM or cellular network. For example, suppose VQM were deployed in the following network: Phone A <-- VQM --> Bridge <--> Phone B. For RTCP XR reports sent from Bridge to Phone A, the external CQ R factor (in) would represent quality for RTP flowing from Phone B to Bridge. If no applicable reports are received, this statistic will be unavailable.

VqmExtRCqOut is the external conversational quality R factor (out), as determined from an RTCP XR report (RFC 3611) and RTCP-HR, currently in draft. This measurement is copied from an RTCP XR message received from a remote endpoint on the other side of this endpoint. For example, suppose VQM were deployed in the following network: Phone A <-- VQM --> Bridge <--> Phone B. For RTCP XR reports sent from Bridge to Phone A, the external CQ R factor (out) would represent quality for RTP flowing from Bridge to Phone B. If no applicable reports are received, this statistic will be unavailable.

Fax and Modem Metrics

VqmThroughPutIndex is the estimated throughput for a fax or data call; a bitrate ranging from 0 to 35000 bps. This value is calculated based on gap/burst conditions and loss/discard rates.

VqmReliabilityIndex is a reliability index for a fax or data call ranging from 0 (least reliable) to 100 (most reliable).

Voice Quality Monitoring Appendix B. ADTRAN Supported CODECs


Appendix B. ADTRAN Supported CODECs

The following CODECs are supported by VQM in AOS:• G.711 64k µ-law voice encoder/decoder• G.711 64k µ-law with PLC voice encoder/decoder• G.723.1 5.3k voice encoder/decoder• G.723.1 6.3k voice encoder/decoder• G.728 voice encoder/decoder• G.729 voice encoder/decoder• G.729A voice encoder/decoder• GSM 6.10 (full-rate)• Reserved for GSM 6.10 (half-rate)• GSM 6.10 (enhanced full-rate)• Lucent/elemedia SX7300/8300• Lucent/elemedia SX9600• G.711 64k A-law voice encoder/decoder• G.711 64k A-law with PLC voice encoder/decoder• G.726 ADPCM voice encoder/decoder (16, 24, 32, 40 kbit)• GIPS Enhanced G.711 µ-law voice encoder/decoder• GIPS Enhanced G.711 A-law voice encoder/decoder• GIPS iLBC voice encoder/decoder• GIPS iSAC voice encoder/decoder• GIPS iPCM-wb voice encoder/decoder• G.729E voice encoder/decoder (8.0, 11.8 kbit)• Wideband Linear PCM voice encoder/decoder• Wideband Linear PCM voice encoder/decoder with PLC• G.722 voice encoder/decoder (64, 56, 48 kbit)• G.722.1 voice encoder/decoder (32, 24 kbit)• G.722.2 voice encoder/decoder (23.85 kbit, 23.05, 19.85, 18.25, 15.85, 14.25, 12.85, 8.85, 6.6 kbit)• QCELP voice encoder/decoder (8, 13 kbit)• EVRC voice encoder/decoder• SMV voice encoder/decoder (8.12, 5.79, 4.44, 3.95 kbit)• AMR Narrowband voice encoder/decoder (12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.15, 4.75 kbit)• iLBC voice encoder/decoder (13.3, 15.2 kbit)• G.711 56k µ-law voice encoder/decoder• G.711 56k µ-law with PLC voice encoder/decoder• G.711 56k A-law voice encoder/decoder• G.711 56k A-law with PLC voice encoder/decoder• G.723.1 Annex C voice encoder/decoder• Speex Narrowband voice encoder/decoder (2.15, 5.95, 8, 11, 15, 18.2, 24.6, 3.95)• Speex Wideband voice encoder/decoder (12.8, 16.8, 20.6, 23.8, 27.8, 34.2, 42.2 kbit)

Documents

AOS Voice Quality Monitoring (VQM)