Hadriel Kaplan
changed
bug 3348
Comment # 1
on bug 3348
from Hadriel Kaplan
(In reply to Stephane Cohen from comment #0)
> However we may want to improve this section ...
>
> <snip
> /* so if the current sequence number is less than the start one
> * we assume, that there is another cycle running */
> if ((pri->info_seq_num < rs->f_start_seq_nr) && (rs->f_under == FALSE)){
> rs->f_cycles++;
> rs->f_under = TRUE;
> <snip?
The existing code is broken. If the first packet has the sequence number of 0,
then no packet in the future will ever be less than that, and thus no "cycles"
will be counted even if the number wraps (because it will wrap back to 0, which
is not less than rs->f_start_seq_nr).
> In our case the second packet has a seq number lower than the first one (due
> to high jitter). So f_cycles is wrongly incremented and we end up with 97%
> packet loss. I think a simple check would be to see if 2 consecutive packets
> (or more) have a lower value than the initial one.
That would mean the first packet would have to have a sequence number of >= 2,
or else we'd never see two consecutive packets be less than it. And if one of
those two were dropped and not captured, we'd miss the cycle altogether for
that round unless the first packet's sequence number was >= 3, etc.
But initial sequence numbers are supposed to be chosen randomly by the sender,
so it might be 0, or 1, or 2, ...
Judging from the problems raised in a recent question on ask.wireshark.org,
there are other problems too:
https://ask.wireshark.org/questions/44022/negative-packet-loss
The whole RTP loss analysis model might need to be rethought.
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.