Clarification: Quality stats retrieved forom RTPEngine-CTL

[Carlo Benfatti]

Hello all,

I hope this isn't a duplicate issue — I couldn’t find anything about it here or in the RTPEngine documentation.

I'm using `rtpengine-ctl list jsonstats` to retrieve quality stats, but I've run into the following issues:
- I couldn't find any explanation or documentation about how the voip metrics are measured, nor how often RTP streams are sampled
- The stats seem to be measured since the start of the RTPEngine service, so, if we have an RTPEngine instance that has been running for two years, the avarages have basically no significance. Is there any way we can restart the measures over without restarting the service?
- In the docs, there's no measure unit for jitter and rtt, nor an explaination of what's the difference between "jitter" and "jitter_measured", or "rtt_e2e" and "rtt_dsct". I'm not familiar with standard definitions of those terms, and google searches about end-to-end versus discrete rtt are yielding no clear result.

Can anyone point me to the right documentation, if it exists, or briefly explain those points? I'd like to avoid digging into the code if possible.

Thanks in advance!

Carlo

[Richard Fuchs]

On 19/09/2025 05.48, Carlo Benfatti wrote:
> Hello all,
>
> I hope this isn't a duplicate issue — I couldn’t find anything about
> it here or in the RTPEngine documentation.
>
> I'm using `rtpengine-ctl list jsonstats` to retrieve quality stats,
> but I've run into the following issues:
> - I couldn't find any explanation or documentation about how the voip
> metrics are measured, nor how often RTP streams are sampled

Measurements are tied to RTCP, and sampling happens either when an RTCP
report is received or generated to be sent. If generated it happens
every ~5 seconds per stream by default, but can be configured via the
RTCP-interval option.

> - The stats seem to be measured since the start of the RTPEngine
> service, so, if we have an RTPEngine instance that has been running
> for two years, the avarages have basically no significance. Is there
> any way we can restart the measures over without restarting the service?

Averages are provided for convenience only and currently there's no way
to reset them. Normally you would feed all the values into some
collection service (e.g. Prometheus) and have that service calculate the
averages based on the cumulative total and the number of samples, or the
respective difference between them for interval-based averages. You can
also do it manually with some simple math.

> - In the docs, there's no measure unit for jitter and rtt, nor an
> explaination of what's the difference between "jitter" and
> "jitter_measured", or "rtt_e2e" and "rtt_dsct". I'm not familiar with
> standard definitions of those terms, and google searches about
> end-to-end versus discrete rtt are yielding no clear result.

Jitter is in milliseconds, RTT is in microseconds.

Jitter values are normally taken from RTCP receiver reports, but
rtpengine can also optionally measure it itself, hence two values.

RTT can be end-to-end, i.e. between Alice and Bob, or between either end
and rtpengine, i.e. between Alice and rtpengine and/or between Bob and
rtpengine. Generally the end-to-end RTT is the sum of two discrete RTTs.

HTH

Cheers