Jitter is the variation in packet delay as packets cross the network. Jitter is usually measured as packet inter-arrival time, which isn’t quite the same thing, but works well for a packet stream that is sent at a periodic interval like a voice stream. Jitter is primarily caused by queue delays. If a packet passes through a nearly empty queue, its delay is short. If the next packet behind it finds the same queue nearly full, it waits a long time before being forwarded. Jitter management is done by managing queue depths. A shorter queue means packets won’t have to wait long, but it also means bursts of traffic will cause packet loss sooner. So by managing jitter properly, it pushes the problem back onto packet loss.

Jitter is managed by a receiving endpoint with a jitter buffer. This buffer holds an on-time packet for some period of time before playing it. The depth of the jitter buffer determines the amount of time an on-time packet is held. A late packet will be moved through the jitter buffer quickly, to bring it up to the right ‘play’ time. Jitter is specified in Table 6 as 40 ms because some Polycom conferencing systems have a 40 ms jitter buffer. This means packets arriving as much as 40 ms late can still be played on-time, but packets arriving later than this will be discarded. The network needs to keep jitter within this bound to prevent more packets being dropped, and the subsequent degradation of voice or video quality.

Network jitter can result in packet loss

A 1% packet loss may produce blocky video and/or audio loss

A 2% packet loss may make video unusable, although audio may sound somewhat acceptable

While packet loss above 2% is unacceptable for H.323, 1-2% is considered “poor” and should be resolved immediately in consultation with the connectivity / service provider.