Jeff Morriss
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 Morriss
(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.