Wireshark · Wireshark-users: Re: [Wireshark-users] VoIP call analysis / number of expectedRTPpacket wrong calculation

["Stephane Cohen (stcohen)" <stcohen@xxxxxxxxx>]

Hi Lars and thanks for answering.

Yes I just reviewed the code and this is indeed the problem 

-			/* 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;


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. I think a
simple check would be to see if 2 consecutive packets (or more) have a
lower value than the initial one. I'll file a bug on this.

Cheers,

Stephane.


-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of RUOFF LARS
Sent: Friday, March 20, 2009 4:29 PM
To: Community support list for Wiresharkg. 
Subject: Re: [Wireshark-users] VoIP call analysis / number of
expectedRTPpacket wrong calculation

Hi Stephane,
 
Well, the comments from the corresponding section of code in the current
trunk (still) say this:
 
	/* When calculating expected rtp packets the seq number can wrap
around
	* so we have to count the number of cycles
	* Variable cycles counts the wraps around in forwarding
connection and
	* under is flag that indicates where we are
	*
	* XXX how to determine number of cycles with all possible lost,
late
	* and duplicated packets without any doubt? It seems to me, that
	* because of all possible combination of late, duplicated or
lost
	* packets, this can only be more or less good approximation
	*
	* There are some combinations (rare but theoretically possible),
	* where below code won't work correctly - statistic may be wrong
then.
	*/

So yes, it can happen that the statistics are not correct, especially
when we lose or duplicate or inverse packets around the 65536-boundary.
Getting all possible scenarios is difficult.
If you have time, please open a bug report and attach your capture, it
will definitively help to improve the algorithm.

Regards,
Lars Ruoff
 


________________________________

	From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Stephane
Cohen (stcohen)
	Sent: vendredi 20 mars 2009 12:42
	To: wireshark-users@xxxxxxxxxxxxx
	Subject: [Wireshark-users] VoIP call analysis / number of
expected RTPpacket wrong calculation
	
	
	Hi 
	 
	Using Wireshark 1.0.1
	 
	From Statistics -> RTP -> Stream analysis, you get a report
including the number of packet lost, which is calculated against the
number of *expected* packets.
	 
	From
http://www.ethereal.com/lists/ethereal-dev/200305/msg00106.html
<http://www.ethereal.com/lists/ethereal-dev/200305/msg00106.html>  I see
this is calculated that way 
	 
	guint32 f_expected = (rs->f_stop_seq_nr + rs->f_cycles*65536) -
rs->f_start_seq_nr + 1;

	That is "last packet seq number" - "first packet seq number"
corrected w the number of times you wrap the max int value 65536. This
seems fine however we have a few captures where wireshark miscalculates
the expected number of RTP packets b/c it wrongly adds a "cycle". I
think this is triggered by the fact some packets are received out of
sequence (due to high jitter) but I'm not positive.

	Have you seen this before? I can provide the capture unicast if
needed.

	Thanks in advance,

	Stephane.

	
________________________________________________________________________
___
Sent via:    Wireshark-users mailing list
<wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
 
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe