McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 16

↗ View in doc context
page
16
source
voice-quality/troubleshooting/troubleshoot-qos-voice/troubleshoot-qos-voice.md
chunk_id
voice-quality::troubleshooting::troubleshoot-qos-voice::troubleshoot-qos-voice::15

Jitter Buffer The jitter buffer is confined by a high water mark and a low water mark. The high water mark is the upper time limit within which a packet is expected to arrive for on−time playout. Packets that arrive after the high water mark are marked as late packets or lost packets. The low water mark is the minimum time within which a packet is expected to arrive for on−time playout. Packets that arrive before the low water mark are considered early packets (it can still be played out on time). If the terminating gateway continues to see an increment in the arrival of late packets, it increases the high water mark. This value for high water mark remains the same throughout the duration of the call. This is increased up to a maximum defined in the configuration. In a similar manner, the terminating gateway observes the number of early packets received. If these packets start to frequent the gateway, it reduces the low water mark. This value remains the same throughout the duration of the call. This mode of jitter buffer is referred to as "adaptive mode," where the terminating gateway adapts its jitter buffer based on the traffic pattern. The other mode is "fixed mode." In the fixed mode, there is one initial value for the low water mark and the high water mark. This value is based on the estimated received delay ( see the show voice call <port−number> section of this document). For further details on jitter buffer, refer to Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms). Identify Delay and Jitter This section describes how to identify jitter in your network. show call active voice The show call active voice brief command gives a great deal of information about an ongoing conversation. This output displays some important points that are learned from this command: 11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active dur 00:08:43 tx:26157/522967 rx:7044/139565 Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:−62 acom:0 i/0:−56/−48 dBm 11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active dur 00:08:43 tx:7044/139565 rx:26165/523127 IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8 From the show call active voice brief command output, you see that whatever is received on the Telephony leg (rx:7044) is transmitted to the IP leg (tx:7044). The same is true for packets received on the IP legs (26165) that are forwarded to the Telephony leg (26157). The difference in the number of packets received on the IP leg versus the number of packets transmitted on the Telephony leg is contributed to late packets that do not make it in time. This output of the show call active voice command (without the "brief" keyword), points to further details about parameters that directly identify jitter. GapFillWithSilence=850 ms GapFillWithPrediction=9230 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms show voice call <port−number> The show voice call port−number command provides useful information. Make sure to be either consoled in