If you know what delay is, jitter is simply the difference in packet delay. In other words, jitter is measuring 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 this image above, you can notice that the time it takes for packets to be send is not the same as the time in which he will arrive at the receiver side. One of the packets encounters some delay on his way and it is received 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 bigger chance to get some delay.
In order to better tune the jitter correction, best practice is to note packets who 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 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 to, 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 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 itself.
For 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 networks thing where there are more hops towards the destination, and more different paths to those destinations, 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 to 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.