Wireshark-bugs: [Wireshark-bugs] [Bug 4902] Delta is always 0 in RTP Stream Analysis
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4902
--- Comment #7 from Jaap Keuter <jaap.keuter@xxxxxxxxx> 2010-06-23 16:10:41 CEST ---
(In reply to comment #6)
> Ah okay - indeed the stream was from VLC and there was no way wireshark could
> have known what the streams were. However, firstly surly the delta column only
> requires the time at which the packets were detected rather than any
> stream-specific information?
I'm afraid not. The delta is based on the timestamps carried in the RTP packet,
not the frame timestamps.
> Having the arrival deltas in this column does make
> debugging and RTP stream much easier even if the other columns can't be
> populated.
Then you're not looking at the RTP timestamping but the capture timestamping.
If you want to see that just change the Time Display Format from the View menu
into Seconds since previous display packet.
> Secondly, I've provided another sample file where again dynamic payload types
> are used but the SIP/SDP is present and as such wireshark is able to determine
> that the RTP streams are MP4V-ES and speex respectively. In the case of the
> MP4V-ES stream wireshark does populate all the columns but with the speex
> stream it does not, despite knowing that the stream is speex. I assume it has
> just taken the encoding name but is unable to read the RTP clock rate. It
> seems like speex ought to be supported (and as I mention, in any case should
> have the delta column populated).
Speex comes in several flavours, see RFC5574, and has three possible clock
rates, see section 3.3: "The sampling rate MUST be either 8000 Hz, 16000 Hz, or
32000 Hz." So, from Speex alone the clockrate can't be derived.
What should be improved is the interpretation of the SDP negotiations, so these
clock rates are extracted.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
