/mcpDSP VOICE ERROR STATISTICS Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 DSP LEVELS 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 to Playout Delay Enhancements for Voice over IP. 5. What Causes Jitter? 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. Encapsulation Considerations 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. Jitter in a Frame Relay Environment Three parameters need to be addressed to find the jitter in a Frame Relay environment: Traffic Shaping • Fragmentation • Queueing • For sample configurations and information related to configuring this, refer to VoIP over Frame Relay with Quality of Service. Traffic Shaping 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 show frame−relay pvc xx command , where xx is the Data−link connection identifier (DLCI) number. You should receive output similar to this: