On Fri, Apr 3, 2009 at 1:03 PM, Sebastian Mellmann < sebastian.mellmann at net.t-labs.tu-berlin.de> wrote: > > > On Fri, Apr 3, 2009 at 10:12 AM, Sebastian Mellmann > > <sebastian.mellmann at net.t-labs.tu-berlin.de > > <mailto:sebastian.mellmann at net.t-labs.tu-berlin.de>> wrote: > > > > Hi everyone! > > > > After each call 'pjusa' prints some information about the past call. > > > > An example summary looks like this: > > > > [DISCONNCTD] To: sip:30.30.30.1;tag=04YY1YX4-0S0HH2yi7LWNBSZ8mXDD9jy > > Call time: 00h:01m:01s, 1st res in 71 ms, conn in 71ms > > SRTP status: Not active Crypto-suite: (null) > > #0 PCMU @8KHz, sendrecv, peer=30.30.30.1:4000 > > <http://30.30.30.1:4000> > > RX pt=0, stat last update: 00h:00m:01.243s ago > > total 2.7Kpkt 444.3KB (555.4KB +IP hdr) > > @avg=58.1Kbps/72.7Kbps > > pkt loss=276 (9.0%), discrd=1 (0.0%), dup=0 (0.0%), > > reord=0 (0.0%) > > (msec) min avg max last dev > > loss period: 20.000 22.258 60.000 20.000 6.820 > > jitter : 0.000 0.337 1.750 0.750 0.278 > > TX pt=0, ptime=20ms, stat last update: 00h:00m:01.555s ago > > total 3.0Kpkt 488.8KB (611.0KB +IP hdr) @avg > > 64.0Kbps/80.0Kbps > > pkt loss=308 (9.2%), dup=0 (0.0%), reorder=0 (0.0%) > > (msec) min avg max last dev > > loss period: 340.000 513.333 720.000 480.000 56.446 > > jitter : 0.125 0.208 0.250 0.125 0.058 > > RTT msec : 0.762 1.252 2.817 2.817 0.705 > > > > I'm not sure what the 'loss period' and 'jitter' values mean. > > How can I interpret those values? > > I know what 'jitter' means, but not in this case. > > > > > > Loss period means the period on which we didn't have audio, due to > > packet loss. There are some definitions/explanations in RFC 3357, not > > sure if this helps or not. But the main use in our case is to have > > some understanding about the nature of the packet losses, i.e. if we > > have total of 10 packet losts, the loss period helps us to know > > whether these losses are random/one by one (in this case the loss > > period would be 1 frame/20ms) or in a burst (in this case the loss > > period would be more than 1 frame). > > > So in the above example the loss period on the transmitter side means > that we had no audio for 340ms minimum, 720ms maximum etcpp.? > > Uhm, no actually! The definition of the loss period would be accurate for RX side, so for the RX side, we have no audio for 20ms minimum and 60ms maximum. But for TX, the situation is different. Remember that for TX, we get the statistic from RTCP RR packet sent by remote peer, and unfortunately there is no "loss period" field in RTCP RR. All we have in RTCP RR is just total number of packet lost so far since the session was started. So lacking this, all we can do (for the TX side) is to display the worst case scenario, where we assume that all the packets were lost in burst. So for the TX above, it means that we've had minimum of 17 packets losses (340/20=17) and maximum of 36 packet losses during one RTCP interval (5 seconds normally). We don't know whether these losses happened in burst (hence the loss period definition is accourate) or not. > > I'm not sure which part of jitter that's not clear. > > > The definition of jitter I know is: > The jitter represents the variance of the runtime of a data packet. > The question is, what does those 'min' 'max' etc. jitter values in the > summary tell me? > For example I see a 'min' jitter value of 0.000 on the RX side. > What does this mean? > > On the RX side, the jitter value of an incoming RTP packet is calculated as soon as the packet is received, using the calculation in the RTP RFC. From this then we recalculate the min, max, avg, and stddev jitter values for the session. So the min/max etc really means that it says. For the TX side, again we can only rely on RTCP RR sent by remote, hence the min, max, avg, and stddev values are taken from the value in the RTCP RR packets. So in this case, the min/max actually means the min/max of the RTCP RR values (or in other words, min/max of the averaged value, since RTCP RR jitter value is an averaged value for that RTCP interval). Not sure if my descriptions above make sense, if not then I guess the source code would be the best place to seek clarifications (see pjmedia/rtcp.c). cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090406/352c8816/attachment.html>
