Wireshark-bugs: [Wireshark-bugs] [Bug 3348] New: Re: [Wireshark-users] VoIP call analysis / numb
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3348
Summary: Re: [Wireshark-users] VoIP call analysis / number of
expected RTP packet wrong calculation
Product: Wireshark
Version: 1.0.5
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Enhancement
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: stcohen@xxxxxxxxx
Created an attachment (id=2876)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2876)
corresponding filtered sniffer capture
Build Information:
Version 1.0.1 (SVN Rev 25639)
--
Context :
>From Statistics -> RTP -> Stream analysis, you get a report including the
number of packet lost, which is calculated against the number of expected
packets. We know this is not 100% safe as from the source code comments
<snip>
* There are some combinations (rare but theoretically possible),
* where below code won't work correctly - statistic may be wrong then.
<snip>
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?
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.
Thanks,
Stephane.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
