Jitter data in rtpp_acct_csv is sometimes wrong

[YehonatanVonage]

Hi, I'm running the RTPProxy with the flag: --dso lib/rtpproxy/rtpp_acct_csv.so, in order to log to file the jitter data calculated in the rtp_analyze.c ("rtpa_jitter_last_ino", "rtpa_jitter_max_ino", "rtpa_jitter_avg_ino", "rtpa_jitter_last_ina", "rtpa_jitter_max_ina", "rtpa_jitter_avg_ina").

I have 2 questions regarding this log: 1. What is the units for the jitter? seconds / ms? 2. After examining the jitter stats from the log file, I see sometimes jitter data that doesn't make any sense: f.e. In a specific call log for a call with 12 seconds duration I get the next data: The originator jitter seems to be OK: "rtpa_jitter_last_ino", "rtpa_jitter_max_ino", "rtpa_jitter_avg_ino" 7.181892,43.909236,13.803124

But the answerer jitter seems to be not logical: "rtpa_jitter_last_ina", "rtpa_jitter_max_ina", "rtpa_jitter_avg_ina" 80.685281,13936773.413711,554700.367942

Is this issue is known? Do you know why it happens?

Thanks

[sobomax]

@YehonatanVonage jitter is expressed in terms of timestamp units. Usually timestamp unit for the audio streams is 1/8000s, which is 0.125ms (as per RFC3550 definition/formulae, page 38 here https://www.ietf.org/rfc/rfc3550.txt). So the value 43.x is jitter of about 5ms. The other (huge) value looks like rubbish, probably caused by some bogus values in the RTP headers. The RTPproxy is not doing much sanity checking on those values, which is probably why. It's hard to say more without looking at the capture in question.

[YehonatanVonage]

Hi, Thanks for the response.

One more question: Is this the only way to dump the jitter stats from the RTPProxy, or there is another recommended way to do so?

Thanks

[sobomax]

@YehonatanVonage you can also use Q command to pull those live.