On Aug 25, 2009, at 9:32 PM, Peter Childs wrote:
Passive taps will only give you 'partial' view of performance, unless both ends support RTCP in which case life is much better.
RTCP is very useful for some things, but not for jitter. Estimating jitter certainly APPEARS easier with RTCP -- but the facts disappoint. You can have a RTCP-reported jitter, but still have a terrible phone call. The RTCP-reported jitter average masks periods where the jitter buffer overflows (due to router queue compression) or underflows (due to long delays). The jitter calculation in RTCP gives, at best, a vague long- term statistical view. For example: using the RTCP jitter statistic defined in RFC 3550, suppose you have 20 ms ptime RTP, but network congestion causes each packet to arrive 25 ms apart. Suppose also you have a 6*ptime (120 ms) jitter buffer that begins playback when it's filled to 3*ptime (60 ms). RTCP will dutifully report 5 ms of jitter, but in reality the user will experience alternating periods of audio and silence (The pattern will be something like: 75 ms silence followed by 600 ms audio, then 75 ms silence, then 600 ms audio, etc.) RTCP XR (RFC 3611) does provide some additional useful data on this in the discard-rate field. This is a direct measurement of jitter buffer behavior. However, I believe you can still have silent periods due to network congestion, but report no discards and trivial jitter averages. mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013