Devices on a network, such as a packet-switched network, typically run using internal clocks to determine timing information. This means that the sending device's clock and the receiving device's clocked can be unsynchronized. Commonly, these devices transmit data and so the clock rate differences that occur between the different devices does not pose a problem. An arbitrary amount of buffering can be applied and long time-outs can be programmed to ensure that all that is received is stored. However, real-time data, such as voice, fax, video, modem communications, and the like, can be interactive by nature with short time outs and delays. This type of data can benefit greatly by having synchronized clocks between the sender and the receiver.
At the receiver, an internal clock is used to control play-out rate and it is the timing of this clock that should be correlated with the clock of the sending device. For example, in any PC being used as a soft phone, the sound card clock governs the rate of play-out. In an IP telephone, it is the rate at which the A/D and D/A conversion is carried out on the channel. And, for example, in a gateway, the back plane rate is the controlling clock.
The crystals used in such environments can range from accurate to fairly poor. Clock mismatch often results in a need to spill or gain samples periodically to prevent jitter buffer over or underrun in, for example, a voice call. This can affect call quality, albeit in a minor way, while in a modem or fax, call adjustments cannot be carried out as this would cause a modem retrain and potentially a dropped call as the carrier is interrupted. In this example, the jitter buffer continues to build out or shrink resulting in greater delays in one direction which affects time outs. If the call lasts longer, the call ultimately drops when the jitter buffer limit is reached. Bonded video can become distorted depending on where the jitter buffer adjustment is made, or, if none is made, then once the jitter buffer overruns or underruns, a large disturbance in the video can be created.
Related to this issue is lip synchronization in IP video. Due to the timing differences, it is difficult to synchronize voice with the video, making the video a less attractive proposition if it is not dealt with adequately.
Other techniques to solve this problem utilize signal processing techniques such as Kalman filters to extract the long term drift from the short term jitter. This technique is complicated and requires significant processing to maintain. IEEE 1588 sends special frames on request from a device wanting synchronization. The sync source responds with a time stamp. This works on a local LAN with the same subnet.