(Adding categories) |
|||
| Line 9: | Line 9: | ||
Jitter is often caused by low [[bandwidth]] situations in [[VoIP]] and can be exceptionally detrimental to the overall [[quality of service]]. Jitter can cause [[packet]]s to arrive and be processed out of sequence. When jitter is high, [[packet]]s arrive at their destination in spurts. This situation is analogous to uniform road traffic coming to a stoplight. As soon as the stoplight turns green ([[bandwidth]] opens up), traffic races through in a clump. The general prescription to control jitter at [[VoIP]] endpoints is the use of a [[buffer]], but such a [[buffer]] has to release its voice [[packet]]s at least every 150 ms (usually a lot sooner given the transport delay) so the variations in delay must be bounded. The [[buffer]] implementation issue is compounded by the uncertainty of whether a missing [[packet]] is simply delayed an anomalously long amount of time, or is actually lost. Jitter can also be controlled throughout the [[VoIP network]] by using [[router]]s, [[firewall]]s, and other [[network]] elements that support [[quality of service]]. These elements process and pass along time urgent [[traffic]] like [[VoIP]] [[packet]]s sooner than less urgent [[data]] [[packet]]s. |
Jitter is often caused by low [[bandwidth]] situations in [[VoIP]] and can be exceptionally detrimental to the overall [[quality of service]]. Jitter can cause [[packet]]s to arrive and be processed out of sequence. When jitter is high, [[packet]]s arrive at their destination in spurts. This situation is analogous to uniform road traffic coming to a stoplight. As soon as the stoplight turns green ([[bandwidth]] opens up), traffic races through in a clump. The general prescription to control jitter at [[VoIP]] endpoints is the use of a [[buffer]], but such a [[buffer]] has to release its voice [[packet]]s at least every 150 ms (usually a lot sooner given the transport delay) so the variations in delay must be bounded. The [[buffer]] implementation issue is compounded by the uncertainty of whether a missing [[packet]] is simply delayed an anomalously long amount of time, or is actually lost. Jitter can also be controlled throughout the [[VoIP network]] by using [[router]]s, [[firewall]]s, and other [[network]] elements that support [[quality of service]]. These elements process and pass along time urgent [[traffic]] like [[VoIP]] [[packet]]s sooner than less urgent [[data]] [[packet]]s. |
||
[[Category:Technology]] |
[[Category:Technology]] |
||
| + | [[Category:Definition]] |
||
Revision as of 01:42, 14 November 2010
Packet switching
Jitter refers to non-uniform packet delays that can cause packets to arrive and be processed out of sequence.
Jitter, as it relates to queuing, is the difference in latency of packets.
VoIP
Jitter is often caused by low bandwidth situations in VoIP and can be exceptionally detrimental to the overall quality of service. Jitter can cause packets to arrive and be processed out of sequence. When jitter is high, packets arrive at their destination in spurts. This situation is analogous to uniform road traffic coming to a stoplight. As soon as the stoplight turns green (bandwidth opens up), traffic races through in a clump. The general prescription to control jitter at VoIP endpoints is the use of a buffer, but such a buffer has to release its voice packets at least every 150 ms (usually a lot sooner given the transport delay) so the variations in delay must be bounded. The buffer implementation issue is compounded by the uncertainty of whether a missing packet is simply delayed an anomalously long amount of time, or is actually lost. Jitter can also be controlled throughout the VoIP network by using routers, firewalls, and other network elements that support quality of service. These elements process and pass along time urgent traffic like VoIP packets sooner than less urgent data packets.