Ethereal-dev: [Ethereal-dev] RTP analysis w/out-of-order packets (patch included)
Hi folks,
I was using the RTP stream analysis tool, and noticed it didn't do very well with out-of-order packets. The way the number of cycles was counted (which is used for the total/lost packets calculations) incremented whenever the current packet has a sequence number larger than the previous. With out-of-order packets, this happens many times, causing the cycle count to be too high.
With the attached patch, I fix this and a few other things, notably:
- Correctly detect the first sequence number, even if it doesn't arrive as the first packet.
- Correctly detect the last sequence number, even it it didn't arrive last.
- Do not require the source port to be fixed (this is not part of the RTP spec -- RTP doesn't know anything about the transport protocol). One of my RTP sources increments the source port with each packet, and with this patch, all packets to the same destination port are treated as a single stream, regardless of what the source port was.
- Attempt to guess the clock frequency for unknown RTP payload types. Payload type 96 (dynamic) is used with RFC 3551. If the smallest delta between two timestamps is a "standard" time increment, I use the corresponding clock frequency. Currently, I only have 4 deltas, all video with a 90kHz clock, and for 24, 25, 29.97, and 30 fps. I welcome others to extend this list to include audio or other standard clock rates.
- Extended the summary at the bottom of the RTP dialog to include the clock rate (and whether it's guessed or not), first and last sequence number, and the number of sequence number cycles.
This patch is diff against a subversion checkout made today.
Feedback is welcome.
Patrick
Attachment:
ethereal_rtp.patch
Description: ethereal_rtp.patch
