This document describes jitter, and how to measure and compensate for
Readers of this document should have knowledge of these topics:
The information in this document is applicable to Cisco IOS voice
gateways and routers.
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
For more information on document conventions, refer to the
Cisco Technical Tips
Jitter is defined as a variation in the delay of received packets. At
the sending side, packets are sent in a continuous stream with the packets
spaced evenly apart. Due to network congestion, improper queuing, or
configuration errors, this steady stream can become lumpy, or the delay between
each packet can vary instead of remaining constant.
This diagram illustrates how a steady stream of packets is handled.
When a router receives a Real-Time Protocol (RTP) audio stream for
Voice over IP (VoIP), it must compensate for the jitter that is encountered.
The mechanism that handles this function is the playout delay buffer. The
playout delay buffer must buffer these packets and then play them out in a
steady stream to the digital signal processors (DSPs) to be converted back to
an analog audio stream. The playout delay buffer is also sometimes referred to
as the de-jitter buffer.
This diagram illustrates how jitter is handled.
If the jitter is so large that it causes packets to be received out of
the range of this buffer, the out-of-range packets are discarded and dropouts
are heard in the audio. For losses as small as one packet, the DSP interpolates
what it thinks the audio should be and no problem is audible. When jitter
exceeds what the DSP can do to make up for the missing packets, audio problems
This diagram illustrates how excessive jitter is handled.
The presence of excessive jitter can be confirmed through Cisco IOS by
completing these steps.
Once a call is up and active, and jitter is suspected, Telnet to
one of the gateways involved.
Monitor in order to be able to see console messages through your Telnet
Note: This step is not necessary if you are connected to the console
voice call summary
command. Output similar to this
PORT CODEC VAD VTSP STATE VPM STATE
============ ======== === ==================== ======================
1/0/0 - - - FXSLS_ONHOOK
1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Select the call where the jitter is experienced. In this example,
it is 1/0/1.
To look at this specific call, enter the show voice
In this example, it is show voice call
1/0/1. The output that is given comes from the DSP that handles
the call and is similar to this:
1/0/1 vtsp level 0 state = S_CONNECT
vpm level 1 state = FXSLS_CONNECT
vpm level 0 state = S_UP
MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 50
Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 0, Interpolate Conceal(ms): 0
Silence Conceal(ms): 0, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 0
***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0
Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0
TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9
TDM Bgd Levels(dBm0): -49.4, with activity being voice
View the ***DSP VOICE VP_ERROR
STATISTICS*** section in the output.
Under this section, there are several parameters to look at. The
main one is the number of Buf Overflow Discard
(ms) that are seen. This counts the packets that are out of
range for the playout delay buffer (dropped). This may have some value in it,
as long as it does not constantly increase. It is normal to get some overflows
when a call is first initiated, but this value should not increase when the
show voice call X/X/X command is repeated. This
number is a direct indication of excessive jitter.
By default, this buffer runs in an adaptive mode where it
dynamically adjusts to the amount of jitter present (up to a point). Configure
the playout-delay command to change the defaults for
the dynamic behavior of the de-jitter buffer. This buffer can also be set in
fixed mode. This can fix some issues with jitter. For more information, refer
Delay Enhancements for Voice over IP.
Jitter is generally caused by congestion in the IP network. The
congestion can occur either at the router interfaces or in a provider or
carrier network if the circuit has not been provisioned correctly.
The easiest and best place to start looking for jitter is at the router
interfaces since you have direct control over this portion of the circuit. How
you track down the source of the jitter depends greatly on the encapsulation
and type of link where the jitter happens. Typically, ATM circuits do not
experience jitter when configured correctly due to the constant cell rate
involved. This gives a very consistent latency. If jitter is seen in an ATM
environment, examination of the ATM configuration is necessary. When ATM works
correctly (no dropped cells), you can expect jitter to be a non-issue. In
Point-to-Point Protocol (PPP) encapsulation, jitter is almost always due to
serialization delay. This can easily be managed with
Link Fragmentation and
Interleaving on the PPP link. The nature of PPP means that PPP endpoints
talk directly to each other, without a network of switches between them. This
is so that the network administrator has control over all interfaces involved.
Three parameters need to be addressed to find the jitter in a Frame
For sample configurations and information related to configuring this,
refer to VoIP over
Frame Relay with Quality of Service.
You need to ensure that you are shaping the traffic that leaves the
router to the actual Committed Information Rate (CIR) that the carrier
provides. Verify this by looking at the Frame Relay statistics and check with
the carrier. The first place to look is at the Frame Relay statistics. Use the
frame-relay pvc xx command
, where xx is the Data-link
connection identifier (DLCI) number. You should receive output similar to this:
PVC Statistics for interface Serial0/1 (Frame Relay DTE)
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1
input pkts 103611 output pkts 120054 in bytes 9909818
out bytes 10962348 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 1366 out bcast bytes 448048
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 22:45:57, last time pvc status changed 22:45:57
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 18303
fragment type end-to-end fragment size 1600
cir 20000 bc 1000 be 0 limit 125 interval 50
mincir 20000 byte increment 125 BECN response no IF_CONG no
frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120
traffic shaping drops 18303
Refer to the
show frame-relay pvc
description for a complete
explanation of all fields.
What to Look For
What you should be concerned with in the command output are the values
that show if there has been congestion in the frame network. These values are
the forward explicit congestion notification (FECN), backward explicit
congestion notification (BECN) and discard eligible (DE) parameters. You should
be concerned with only input packets since Cisco does not send any of these.
You may see one or more of these values incrementing. This depends on the type
and configuration of the frame switches that the provider uses. In general
terms, if you have Frame Relay traffic shaping, and are configured for the same
CIR as the circuit, you should never see these values increment. If you do see
these values increment, and you match the true CIR of the circuit, something in
the frame provider's network is not configured properly.
One good example of this is if you purchase a zero CIR circuit, but
have a burst value. Some providers sell the zero CIR permanent virtual circuit
(PVC). This is fine for data, but causes problems with voice quality. If you
look at the command output from a zero CIR circuit, the number of DE or FECN
packets equals the number of input packets. To take this a step further, if you
have a PVC that is provisioned by the carrier to be 128 kbs and the CIR of the
router is set to 512 kbs, you see these counters increment (at a slower rate).
Remember that you are only looking at packets that come into the router
interface and that this rate is controlled by the traffic-shaping parameters
configured on the router at the opposite end of the PVC. Conversely, you
control what is input to the other router by which traffic-shaping parameters
are configured on the local end.
It is very important that you not exceed the CIR for the PVC that is
provisioned by the carrier. You can be below this CIR without having problems.
However, if you exceed it, you will see congestion.
The reason you are able to see the congestion in this fashion is
because the CIR that is configured for a specific PVC on a frame switch
dictates the rate that traffic is passed by that switch (for that PVC). When
the configured CIR on the frame switch is exceeded by the actual data rate it
receives, it must buffer the frames that exceed the CIR until the capacity is
available to forward the buffered packets. Any packet that is buffered gets
either the DE bit set or the FECN bit set by the frame switch.
As always, you also want to closely examine the interface statistics,
and look for drops or errors to be sure that everything functions correctly at
the physical layer. To do this, use the
How this relates to jitter is if this occurs, and some packets need to
be buffered in the frame network, they have a longer latency in getting to the
remote router. However, when there is no congestion, they get through in the
latency time that you normally expect. This causes a variation in the delta
time between packets received at the remote router. Hence, jitter.
Fragmentation associates more with serialization delay than with
jitter. However, under certain conditions, it can be the cause of jitter.
Fragmentation should always be configured in the Frame Relay map class when
doing packetized voice. The configuration of this parameter has two effects on
the interface. The first effect is that all packets larger than the size
specified are fragmented. The second effect is less apparent, but is just as
important. If you look at the interface on which fragmentation is configured,
you can see the effect of this command. Without fragmentation, the queuing
strategy shown in the output of the show interface x
command shows that first in first out (FIFO) queueing is in use.
Once fragmentation is applied to the Frame Relay map class, the output of this
command shows the queueing strategy as dual-FIFO. This creates the priority
queue that is used for voice traffic on the interface. It is strongly suggested
that the fragmentation value be set to the values that are advised in the
section of the VoIP over Frame Relay with QoS
document. If you still experience jitter problems at the recommended value,
lower the fragmentation value one step at a time until voice quality becomes
There are two generally accepted queueing methods used for VoIP traffic
in this type of environment:
One method or the other should be used, they should not both be
configured. If the queueing operation looks correct according to the
documentation, then you can conclude that queueing works properly and the
problem lies elsewhere. Queuing is generally not a cause of jitter since the
variations in delay created by it are relatively small. However, if VoIP
packets do not get queued properly and there is data on the same circuit,
jitter can result.
Jitter is a variation in packet latency for voice packets. The DSPs
inside the router can make up for some jitter, but can be overcome by excessive
jitter. This results in poor voice quality. The cause of jitter is that a
packet gets queued or delayed somewhere in the circuit, where there was no
delay or queueing for other packets. This causes a variation in latency. Jitter
can be caused both by router misconfiguration and by PVC misconfiguration by
the carrier or provider.