Cisco Unified IP Phone 7900 Series

Using the 79xx Status Information For Troubleshooting

Cisco - Using the 79xx Status Information For Troubleshooting


This document focuses on the status information that all Cisco 79xx IP phones provide on their display for troubleshooting problems. This information can be used to determine the type of codec in use for a call in progress. It also provides real-time information on the performance characteristics for a call in progress.

Before You Begin


For more information on document conventions, see the Cisco Technical Tips Conventions.


There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.


The Cisco IP Phone 79xx display can be utilized for troubleshooting purposes via the Information (I) button on the phone to display information on a call in progress. Press this button twice during an active call to activate this feature.


Note: The "i" button looks like this telecaster-trouble_9.gif.

This menu provides the following information:

  • RxType/TxType—The codecs currently utilized in the current active voice conversation.

  • RxSize/TxSize—The size of the payload of the codecs, in this case 20 msec of voice/packet.

    Note: The 79xx MGCP IP phones only support a payload size of 10-40 msec.

  • RxCount/TxCount—Amount of packets sent/received.

  • AvgJtr—Average jitter is the estimated average jitter observed in the last 16 RTP packets (the averaging function is just a simple low-pass filter).

  • MaxJtr—Maximum jitter is the maximum jitter seen during the life of the RTP receive stream. Remember that this is not for the life of the call, but for the stream. If you put a person on hold, the stream goes away and needs to be restarted and hence new values here.

  • RxDisc—The number of packets discarded inbound on this Cisco IP Phone 79xx.

  • RxLost—The number of packets that did not arrive inbound on this Cisco IP Phone 79xx.

Things to focus on for troubleshooting:

  • The RxType/TxType tells you what codec is being used for the conversation between this IP phone and the other device. See if they match on both sides. If they do not match, verify that the other device can handle the codec conversation or that a transcoder is in place to handle the service.

  • The size of the sound samples should match on both devices. This is found in the RxSize/TxSize fields.

  • The RxCount/TxCount is useful for troubleshooting dropped packets, one way voice problems, and voice activity detection (VAD).


In the voice world, jitter relates to the inter gap of packets in the network. Ideally, voice packets should be received synchronously with a constant (but not too long) delay. Unfortunately, most networks deliver voice packets asynchronously. In other words, there is a variance in the time between voice packets. This is referred to as jitter. When the time between voice packets (jitter) varies beyond the playout buffers on the receiving device, the called party will hear gaps in the voice stream.

In an ideal world, a stream of packets containing voice would arrive at the end device (called party) with exactly the same amount of inter packet gap. This would result in a jitter value of 0. In the real world, the gap between voice packets can vary from packet to packet introducing jitter in the sequence.

To cope with this issue, 79xx phones contain a first-in, first-out (FIFO) queue that acts as an elastic packet buffer. It tries to keep the flow of voice packets to the DSPs constant by playing out the packets with a constant inter packet gap. This helps ensure acceptable voice quality. The 79xx jitter buffer will handle up to two seconds of jitter. Jitter is measured in ms.

If the inter packet gap of an incoming voice stream varies between 0 ms and 2 s, the 79xx's FIFO buffer will be able to mask this variation and no gaps in the incoming voice stream will be detected by the called party. On the other hand, if an incoming voice stream experiences an inter packet gap in excess of 2 s, the 79xx's FIFO buffer will have been drained while waiting for the next voice packet. In this situation gaps in the voice stream will be detected. This is explained in more detail below.

In the example below each packet has exactly the same amount of delay between it and the next packet in the sequence. In this case the constant delay value between the packets (5 ms) results in a jitter value of 0.


In a real network situation the inter packet delay is rarely constant:


As a stream of voice packets passes through the buffers of any routers and switches that exist between the source and the destination, gaps are inserted between the packets. These gaps will vary in size because the load on the routers and switches between the source and the destination will be changing constantly.

In the above diagram we can see the inter packet gap range from 5 to 14 to 10. The end devices in the network (IP Phones in this case) have to compensate for these variations so that the packets are played out to the listener (called party) at a constant rate. This requires that the FIFO buffers always have voice packets available to play out.

The size of a 79xx's FIFO buffer varies based on the amount of jitter experienced in the incoming voice stream. If the jitter value of an incoming voice stream is low, the 79xx will use a smaller FIFO buffer than when the the jitter value of an incoming voice stream is high. It is possible however, that the rate of change in the jitter value will be faster than the 79xx can cope with. In this case, the listener (called party) will experience a brief gap in the voice stream while the 79xx adjusts its FIFO buffer size.

Note: The Cisco IP Phone 79xx increases the FIFO buffer size quickly and decreases it slowly.

The size of the FIFO buffer has a direct effect on the delay between a voice packet being sent and being received by the destination. As the FIFO buffer grows larger, the delay in moving packets out of the FIFO buffer increases. See the next section on Delay for more information on this subject.

The following diagram shows a FIFO buffer removing the jitter from an incoming voice stream.


If you are experiencing gaps in your voice calls (cutouts) check the AvgJtr and MaxJtr values. If, for example, the average jitter value is 5 and the maximum jitter value is 3000, there is a chance of a problem because the variance between the two values is very high. If this happened fast, there might not have been enough time for the 79xx's FIFO queue to compensate. This type of behavior can be found in networks that have periodic high rates of activity such as large routing table updates or batch file transfers. In these cases traffic loads go from low or moderate to high and back again in a very short period of time.

Note: The Cisco IP Phone 79xx can typically handle up to 20 percent packet loss without noticeable quality degradation.


Delay is the amount of time it takes a voice packet (or voice stream) to travel from the source to the destination. In most cases delay will vary over the course of a voice stream (conversation). In a properly tuned network, the maximum delay between the time a calling party speaks and the called party hears what was said is less than what the average person can detect. In other words, there is no perceptible delay in the conversation - words are heard as soon as they are spoken.

In some cases delay across the network will increase to a level that is detectable by the human ear. In a worst case scenario the conversation will deteriorate to the point where each person has to indicate that they have stopped speaking so that the other person will know that they can talk without being interrupted by voice packets that have not yet been received. If you are familiar with Ethernet you might call this behavior a late collision.

All networks impose some delay in the transmission of packets from source to destination. Even a network with a constant inter packet gap of < 1ms will experience some delay in the time between when a source device sends a packet and the destination device receives it. Slow speed serial links (64K and below) create more delay than a high speed link such as an OC12 because of the time it takes to serialize the bits onto the transmission medium.

Variations in delay are caused by the same situations that lead to long inter packet gaps as described in the section on jitter above. In the case of delay, however, the causes typically last longer than a few voice packets. Instead of causing an increase in the inter packet gap for a few packets in a conversation, these problems affect entire conversations.

Note: The Cisco IP Phone 79xx does not provide a delay counter. Delay can be measured by network analyzers and other network management devices.

Minor delay problems do not affect voice quality as badly as jitter can. This is because jitter can cause breaks in the voice stream where entire spoken words can be lost, whereas with delay, all of the spoken words will eventually arrive. In other words jitter is very similar to packet loss in an over subscribed network - the packets over flow the interface buffers and get dropped, which means that they never arrive at the destination.

The diagram below shows the combined effect of delay with jitter, which go hand in hand. The packets are transmitted at a constant rate. The IP network does not forward the packets as quickly or consistently, which has resulted in larger and varied inter packet gaps. In addition, the fourth packet is still somewhere in the network.


The cumulative delay in a network depends on how many router and switches your traffic needs to pass through between the source and the destination of any conversation.

In an IP environment, one way of measuring the delay would be to use the traceroute tool, but this will only work for router hops. In addition, some hosts that support traceroute run it at a very low CPU priority, which helps during a Denial of Service (DOS) attack. This means that there is an imposed delay on the part of the CPU that will be added to the time that the packets took to go from one hop to another. In other words - don't place a lot of faith in the numbers reported by traceroute.

There are third-party network analysis tools that can send packets and measure delay down to the nsec. They are very useful for testing network design prototypes under loaded conditions prior to implementing them. It should be noted however that a robust, well designed and tuned voice network should not have consistent delay and jitter problems.

Related Information

Updated: Nov 13, 2006
Document ID: 7415