Let's say that RFC3550 (RTP) explicitly allows for negative counts:
cumulative number of packets lost: 24 bits
The total number of RTP data packets from source SSRC_n that have
been lost since the beginning of reception. This number is
defined to be the number of packets expected less the number of
packets actually received, where the number of packets received
includes any which are late or duplicates. Thus, packets that
arrive late are not counted as lost, and the loss may be negative
if there are duplicates. The number of packets expected is
defined to be the extended last sequence number received, as
defined next, less the initial sequence number received. This may
be calculated as shown in Appendix A.3.
...and Wireshark applies this by the letter in RTP analysis.
Regards,
Lars
________________________________
From: Farooq Razzaque [mailto:farooq_mcp@xxxxxxxxxxx]
Sent: lundi 26 septembre 2011 14:36
To: wireshark-users@xxxxxxxxxxxxx; RUOFF, LARS (LARS)** CTR **
Subject: RE: [Wireshark-users] Wireshark RTP Stream - Packet Lost in Neg value over the WAN
Dear Lars
Really thanks for your support.
Can u please let me know that is this the wireshark or RTP behaviour of showing the duplicate packets in negative value
<http://www.flamingtext.com/hmail.html>
> From: lars.ruoff@xxxxxxxxxxxxxxxxxx
> To: wireshark-users@xxxxxxxxxxxxx
> Date: Mon, 26 Sep 2011 13:56:49 +0200
> Subject: Re: [Wireshark-users] Wireshark RTP Stream - Packet Lost in Neg value over the WAN
>
> Farooq,
> (I put this back on the list if you don't mind, so others can comment and it gets archived.)
>
> In reality, there were only 1744/4 = 436 unique RTP packets sent between the endpoints.
> But Wireshark captured each packet 4 times.
> (Note that your packet counts are always multiples of 4)
> Each duplicate packet (packet with same RTP sequence number) gives rise to a lost count of -1.
> Thus from the 1744, 436 were unique, the remaing 3/4 i.e. 1308 are duplicate.
> Thus a lost count of -1308, corresponding to -300% of the 100% unique packets.
> Hope this is clear.
>
>
> regards,
> Lars
>
>
> ________________________________>
> From: Farooq Razzaque [mailto:farooq_mcp@xxxxxxxxxxx]
> Sent: lundi 26 septembre 2011 12:21
> To: jaap.keuter@xxxxxxxxx; RUOFF, LARS (LARS)** CTR **
> Subject: RE: [Wireshark-users] Wireshark RTP Stream - Packet Lost in Neg value over the WAN
>
>
> Dear Lars/Jaap
>
> Thanks for your support.
>
> we are SPANing the data on cisco switch and forwarding to Alcatel and Cisco recording machine.
>
> monitor session 2 source interface x
> monitor session2 destination interface x.
>
> Can u please let me know how the following can be seen by analysis engine by 4 times. how it is calculate
>
> Number of packet = 1744
> Lost -1308 (-300)
>
>
>
> <http://www.flamingtext.com/hmail.html>
>
>
>
>
>
>
> > From: lars.ruoff@xxxxxxxxxxxxxxxxxx
> > To: wireshark-users@w! ireshark.org
> > Date: Mon, 26 Sep 2011 09:44:30 +0200
> ; > Subject: Re: [Wireshark-users] Wireshark RTP Stream - Packet Lost in Neg value over the WAN
> >
> > Hi,
> >
> > No, since you (almost) consistently have -300% all the time, it is most likely that every packet has been seen exactly 4 times by the analysis engine, but no packets have been lost.
> > (It is an artefact of the RFC3550 lost packets algorithm that duplicate packets are counted as negative losses)
> > However, as Jaap noted, in order to get more readable data, you should fix your capture setup issue which makes you see every packet multiple times.
> >
> > Regards,
> > Lars
> >
> >
> >
> > ________________________________
> >
> > From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Farooq Razzaque
> > Sent: same! di 24 septembre 2011 19:04
> > To: wire! shark-users@xxxxxxxxxxxxx
> > Subject: [Wireshark-users] Wireshark RTP Stream - Packet Lost in Neg value over the WAN
> >
> >
> > Dear All
> >
> >
> >
> >
> > Can u have a look at the attached screen shot of wireshark. In LOST COLUMN it is showing 300% , -299.7% pack lost.
> >
> >
> >
> > Do u have any idea that are these packet loss is normal/abnormal.
> >
> >
> >
> > IP phones ( 172.20.24.x) are located in one branch and Recording machine (172.20.19.17) is located in other branch.
> >
> >
> >
> > SPANing is happing over the WAN via L2TPV3.
> >
> >
> >
> > IP Phones : 172.20.24.X (IP Phone)
> >
> >
> >
> > 172.20.19.17 (Recording machine)
> >
> > ____________________________! _______________________________________________
> > Sent via: Wireshark-users mailing list <wireshark-use! rs@xxxxxxxxxxxxx>
> > Archives: http://www.wireshark.org/lists/ wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> 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
