If you know what delay is, jitter is simply the difference in packet delay. In other words, jitter is measuring the time difference in packet inter-arrival time.
It is a specific phenomenon that normally exists in bigger packet-switched networks. As a time-shift phenomenon, it usually does not cause any communication problems. Actually, TCP/IP is responsible for dealing with the jitter impact on communication.
On the other hand, when we speak about Voice traffic and VoIP network environment this can be an issue. When someone is sending VoIP communication at a normal interval, (let’s say one frame every 10 ms), those packets could have stuck somewhere in-between the network and not arrive at expected regular pace to the destined station. It is not usual, but the packets could take different routes or get load-balanced through two similar paths where one of those is congested in that moment.
That’s the whole jitter phenomenon. We can look at it as the anomaly in tempo, with which packet is expected to come and the time he was late to really get there.
In the image above, you can notice that the time it takes for packets to be sent is not the same as the time in which they will arrive at the receiver side. One of the packets encounters some delay on its way and it is received a little later than it was expected. Jitter buffers are entering the story. They will try to remedy packet delay if required and if possible. VoIP packets in networks have very changeable packet inter-arrival intervals because they are usually smaller than normal data packets, and are therefore more numerous, with a bigger chance to get some delay.
In order to better tune the jitter correction, the best practice is to note packets that arrive late and, with that base data, calculate a ratio of those packets and packets that are successfully transferred. Using that ratio, you can adapt the jitter buffer to some predictable amount describing the number of packets late arriving. This is the best way to tune the jitter buffer.
It can be confusing at first. The jitter and total delay are not even close to be the same thing. Having a lot of jitter in the network will probably increase the total delay, but this should be avoided. It will usually mean that, because there is more jitter, you need more jitter buffer, to be able to compensate.
The buffers are not endless. In the case of heavy jitter situation, it is better to drop some packets or have fixed-size buffers, instead of creating delays in the jitter buffers themselves.
For a local network, if you did a good job in planning and designing the network, the chance to have jitter, and issues that come with it, is minimal. In that kind of network jitter is normally not a big problem, it is more a WAN network thing where there are more hops towards the destination, and more different paths to those destinations, and not all are controlled by you.
You can RTP timestamps in Cisco IOS to see if there is some jitter in your network. Cisco IOS, by default, manages jitter buffers as a dynamic queue. This queue will change its size depending on the packet timing and tempo of arriving at destination. Almost all other vendors use static jitter buffers. Cisco selected dynamic jitter buffer management because, with some enhancement in the network design, it turned out to be the best way to manage the buffers for VoIP traffic.