["RUOFF LARS" <Lars.Ruoff@xxxxxxxxxxxxxxxxx>]

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.