Wrong interpretation of RTP packets

This issue was migrated from bug 1589 in our old bug tracker.

Original bug information:

Reporter: Panagiotis Issaris
Status: RESOLVED NOTABUG
Product: Wireshark
Component: GTK+ UI
OS: Linux
Platform: x86
Version: 0.99.5

Attachments:

pi-20070507T174054-rtp_h264.pcap: Capture file containing RTP packets of type H.264
pi-20070507T181744-rtp_h264.pcap: Capture file containing RTP and SIP packets

Panagiotis Issaris said:

Build Information: wireshark 0.99.5

Copyright 1998-2007 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.10.11, with GLib 2.12.11, with libpcap 0.9.5, with libz 1.2.3, with libpcre 6.7, without Net-SNMP, with ADNS, with Lua 5.1, with GnuTLS 1.4.4, with Gcrypt 1.2.3, with MIT Kerberos, without PortAudio, without AirPcap.

Running on Linux 2.6.20-15-generic, with libpcap version 0.9.5.

Built using gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4).

When inspecting RTP packets, which have a payload type of 99 (H.264) Wireshark 0.99.4 and 0.99.5 interprets the package incorrectly (AFAIK).

According to Wireshark they are are indeed RTP packets with payload type 99 (H.264), but these RTP packets then contain "RFC2198: Redundant Audio Data", which they don't. Ethereal 0.10.12 correctly shows the packets as RTP packets of type 99 (H.264) and just shows the payload (which actually does contain H.264) without further (incorrectly) decoding the contents.

So, Ethereal correctly shows:
Frame
 Ethernet
  IP
   UDP
    RTP

While Wireshark incorrectly shows:
Frame
 Ethernet
  IP
   UDP
    RTP
     RFC2198: Redundant Audio Data

When analyzing the RTP-stream and trying to save the payload, the generated file is corrupt, as the first bytes of the RTP payload are interpreted as a header of type "RFC2198: Redundant Audio Data".

Furthermore, I am not able to stop Wireshark from interpreting the payload of the RTP packets. It seems that right clicking on the "RFC2198: Redun..." and selecting "Decode as...", followed by a "Do not decode" and finally an "Apply" should stop Wireshark from interpreting the payload contents of the RTP packets, but it doesn't.

added oslinux uigtk version0.x labels

Panagiotis Issaris said:

Created attachment 663 Capture file containing RTP packets of type H.264

This file contains 8 RTP packets of type H.264. With these packets separated from the rest of the stream, Wireshark can't see that it is an RTP stream, so you have to ask it to "Decode as..." RTP. It cleary shows that Wireshark interprets the payload of the packets as RFC2198.

Anders Broman said:

Hi, If you could provide the setup info as well it might be possible to improve the H.264 dissection as well. SDP data for H.264 or H.245 that is.

Panagiotis Issaris said:

Created attachment 664 Capture file containing RTP and SIP packets

This capture file contains the first 49 RTP and SIP packets related to the stream with which the problem occurs. There are both H.264 and G.711 packets in the stream.

Jaap Keuter said:

Several times you make the statement that payload type 99 equals H.264. This is plain wrong. A few payload types have a fixed assignment, most of them don't, see http://www.iana.org/assignments/rtp-parameters. 99 is explicitly dynamically assigned. With the absence of valid session negotiation Wireshark does make such dynamic assignment from its preferences. It then defaults to assigning payload type 99 to Redundant Audio Data. If you change that preference you'll get the plain data.

Panagiotis Issaris said:

Thanks for you explanation.

My apologies for my mistake. I was aware of the list of payload types, but assumed that because of some other RFC, it might have become common use to use 99 as the payload type for H.264. And that was because initially, I wasn't aware that Wireshark deducts the payload type name from the entire conversation, not from the individual packets.

I do think that Wireshark is adding just a tiny bit to the confusion here, as it shows "Payload type: H.264 (99)" when decoding the packets. As it shows "Payload type: ITU G.711 PCMU (0)" for fixed payload types such as 0, this only added to my impression that the name before the number in brackets was implying equality. Honestly, I wouldn't know a better way to express in short that one is the payload type number and the other is the actual deducted type from the conversation... or maybe something like this:

Payload type: <the actual name and number from the rtp-parameters list>
And in case the number is a dynamic one (maybe also for the unassigned ones?)
show in a separate line the deducted payload type?
Deducted payload type: H.264


From your suggestion I understood that I would have to modify the preferences, to be able to stop Wireshark from interpreting the RTP packets as containing Redundant Audio Data. But after modifying the 99 below into 98, 100, or 110 nothing changes.
Edit->Preferences->Protocols->RTP->Payload type for RFC2198: 99

I tried restarting Wireshark, checking if the parameter was still 110 and not reset to 99, but it appears to make no difference in the decoding of the packets, every packet still shows up as containing RFC2198: Redundant Audio Data.

Jaap Keuter said:

Thanks for providing the sample capture with SDP. It shows that Wireshark is capable of handling H.264 packet type for RTP payload. The indication "Payload type: H.264 (99)" does mean equality, but limited to the scope of this part of the session. That is what the stream setup information is for. In fact every payload type is (can be) deduced, with several defaults available. No need to indicate that further. Using Version 0.99.6 (SVN Rev 21731), applying a different payload type for RFC2198 does make a difference in the decoding of the payload.

closed