http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1279
martin.mathieson@xxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Comment #1 from martin.mathieson@xxxxxxxxxxxx 2006-12-24 15:41 GMT -------
I did make a change to this code after 0.9.44 was released (see
http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/epan/dissectors/packet-rtcp.c?r1=19709&r2=19778)
to try to avoid reporting -ve values.
However, I've since realised that there is another underlying problem in the
code, in that it can look at earlier frames as being subsequent reports to
later ones (this can also cause -ve deltas to be calculated). The code does
try to verify that the original frame and response match, by matching the first
timestamp and the LSR of the supposed reply... It may be that this is what
you're seeing in the trace you have, check the generated field that points at
the original frame used in the calculation?
I think you're right, it should show and report the difference as a signed
value - this would highlight problems with the way equipment was generating
RTCP reports, which is better than hiding them with the > 0 test that is
currently there.
Maybe minimum preference should just be a +ve number which set a magnitude,
i.e. 10 would apply reporting of values between -10 and 10?
I've assigned this bug to myself, and I'll investigate early next year if
no-one else gets to it first (I don't currently have access to a build
environment or the capture file that displayed this problem)
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.