Fixed RTCP packet lost calculation

[sauwming]

Suppose RTP packets arrive in the following order: seq 5, 10, 6, 7, 8, 9

Currently, upon receiving seq 10, we will calculate it as 4 lost packets (6 until 9) in pjmedia_rtcp_rx_rtp2(): sess->stat.rx.loss += (seq_st.diff - 1).

According to the RFC https://datatracker.ietf.org/doc/html/rfc3550#appendix-A.3, we should calculate it as lost = expected - s->received instead. But we commented this code in 84f4589 because we have done the calculation earlier in pjmedia_rtcp_rx_rtp2(). So we probably should use the later calculation instead.

[sauwming]

The first commits introduce a behavioural change, i.e. in that the packet lost will be calculated even if the probation is not over. For example, RTP packets received in order: seq 1, 12, 13, 14, ... will previously be considered 0 loss, but now will be 10 losses (2 until 11).
This is because previously pjmedia_rtp_seq_update() will not consider the seq diff when we're still in probation.

According to the RFC https://datatracker.ietf.org/doc/html/rfc3550#appendix-A.1:

               if (s->probation == 0) {
                   init_seq(s, seq);
                   s->received++;
...

we only init the sequence and start counting the packets received once the probation has ended, and the seq is inited to the last seq received during probation, not the first seq.

[sauwming]

The third commit is to fix #3655, to handle seq rollover during probation.

[nanangizz]

What if this calculation is done on each incoming RTP instead of in building RTCP for faster stats update (by moving this block there perhaps), because the RTCP interval is configurable so it can be long, default is not that long though, 5 seconds.

Also, perhaps only update/calculate it when out-of-order flag is not set.

[sauwming]

Okay, done in the latest commit.

There are a couple of drawbacks though:

• Calculating only when not out of order means that the packet loss stat may not always be accurate.
• There is also complication with updating the loss period. The stats such as avg, max, std, etc will be inaccurate.

[nanangizz]

Re: first drawback should be acceptable, as I think most RTP packets are ordered (e.g: every second there should be at least two properly ordered packets).

Re: second drawback. Currently the count is the total loss count since the beginning of the session? If it is, the period should not be counted using count. IMO the loss period represents the consecutive loss packets (in time unit) of every packet loss occurance. So the calculation is perhaps: when total loss count is increased, compare the current loss count vs previous loss count, the difference should be the period?

[nanangizz]

minor: move this period calculation to inside the loss_period update block below?