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.
For more information on document conventions, see the
Technical Tips Conventions.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware
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
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
Note: The "i" button looks like this
This menu provides the following information:
RxType/TxType—The codecs currently utilized in the current active
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
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
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
RxDisc—The number of packets discarded inbound on this Cisco IP Phone
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
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
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
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
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
In a real network situation the inter packet delay is rarely
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
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
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
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.