By definition, the round trip time (RTT) can’t really be 0.000000.
wiki.kolmisoft.com/index.php/RTP … emystified
What do i need to do in order to have the RTT populate?
Asterisk: 1.8
Phones: Yealink
NAT: yes
Direct media: no
Seen some chatter about phones having to send RTCP packets or something on order for it to pick it up… donno tho, how can this be the case, isn’t Asterisk supposed to pinging, and timing the response.
The chatter is correct.
qualify is only there to detect unusable devices, to avoid wasting time trying to make calls through them, and to keep firewalls, etc., alive.
Ah ha!, nice one, so i whipped open Blink and tried my testing from here… what do you know my SIP history came alive with additional information.
...
17. RTCPaudio Quality:ssrc=1323090553;themssrc=1007107891;lp=0;rxjitter=0.005
18. RTCPaudioJitter Quality:minrxjitter=0.000000;maxrxjitter=0.000000;avgrxjitter=0
19. RTCPaudioLoss Quality:minrxlost=0.000000;maxrxlost=0.000000;avgrxlost=0.00000
20. RTCPaudioRTT Quality:minrtt=0.000000;maxrtt=0.000000;avgrtt=0.000000;stdevrt
21. SchedDestroy 6400 ms
22. TxResp SIP/2.0 / 25996 BYE - 200 OK
I also got RTT and more
rtt: 0.058000
maxrtt: 0.065000
minrtt: 0.058000
normdevrtt: 0.061250
stdevrtt: 20.664548
back in my hangup macro from the ${CHANNEL(rtpqos,audio,XXXX)}
So now i think the question becomes… HUH, what are these values? My understanding of the RTT is: “Go there, turn-around, and come back” and ill time you. Are these values in seconds, milliseconds, what?
Again with Jitter… my understanding of jitter is the variation in ping replies, so 80,81,79 has a jitter of 1. So what are these values:
txjitter: 0.005055
rxjitter: 0.000000
If you don’t know what they mean the chances are that you don’t need to know the values.
I suspect that these value are defined in the RTCP RFC or in an ITU-T document.
Because RTP includes timestamps and sends packets at nominally exact intervals, jitter can and is measured in one direction, not for the round trip.
Note that Asterisk fails to update SSRC appropriately, so can result in false high jitters.
Jitter is a more complex problem than latency and packet loss. It’s the variation in latency time from one packet to the next. It causes packets to arrive out of order, leaving gaps in the framing sequence of the voice signal. Jitter is at its worst when voice traffic must travel through several routers on the network. The more hops, the worse jitter can get. Different routers, especially those at ISPs, may be configured to queue and forward different kinds of traffic in different ways. Others may be load-balancing, which can contribute to jitter. The chief goal of QoS protocols is to eliminate jitter. Devices called jitter buffers, in endpoints and VoIP servers, can minimize the effect of jitter, too. But, like PLC measures, they do so by increasing latency. (Switching to VoIP By Theodore Wallingford)
In the given example:
How do I interprete the jitter value ? Is the value 0.020917 good ? Bad ? Is there a unit behind this value ?
Answer:
It’s a ratio of out-of-order (jittered) to in-order packets, calculated progressively. Due to the progressive calculation, it’s not exactly 3/147, in this case, but it’s close enough to know that 3 packets were received out-of-order. The closer the value is to 0, the better. – Tilghman Lesher
To get approximate value of received packets out of order do such calculations: rxcount * rxjitter (in our example 150 * 0.020917 = 3.13755 ~= 3 packets). Same for transmitting end: txcount * txjitter.
That is not how jitter is calculated for RTCP. RFC 3550 says:
[quote] interarrival jitter: 32 bits
An estimate of the statistical variance of the RTP data packet
interarrival time, measured in timestamp units and expressed as an
unsigned integer. The interarrival jitter J is defined to be the
mean deviation (smoothed absolute value) of the difference D in
packet spacing at the receiver compared to the sender for a pair
of packets. [/quote]
The averaging is exponential.