Wireshark-bugs: [Wireshark-bugs] [Bug 10665] RTP stream analysis reports high packet loss, when
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 12 Nov 2014 02:59:37 +0000

changed bug 10665


What Removed Added
Status UNCONFIRMED CONFIRMED
Component Common utilities (libwsutil) Dissection engine (libwireshark)
Ever confirmed   1

Comment # 2 on bug 10665 from 
(Jeff sent me the capture file off line.)

It's actually possible to get the capture file down to a reasonable size by
applying this display filter and saving the resulting frames:

rtp.ssrc==0x1089AC00

The resulting file is 2.9 Mbytes compressed.  BUT it appears to contain a real
call so I'm not going to attach the file or put its URL.  Jeff, could I attach
it and mark it private so only Wireshark's core developers can access it?

The problem with this call appears to be that the sender resets its RTP
sequence number.  Here's the output of:

tshark -Y"rtp.ssrc==0x1089AC00" -Tfields -e frame.number -e rtp.seq -r
/tmp/qos.pcap

~~~
201054  43775
201063  43776
201071  43777
201078  43778
201085  43779
201105  20989 <<< here
201114  20990
201122  20991
201132  20992
201139  20993
201147  20994
~~~

Note how the sequence number jumps back to 20989, seemingly in the middle of
the call.  The peers don't seem to mind this but it confuses Wireshark's packet
loss calculation into saying the call had *negative* 94% packet loss.

I don't know about RTP to know what should be done here.

(Bug 3348 is somewhat related.)

You are receiving this mail because:
  • You are watching all bug changes.