This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to decode UDP as RTP tshark only

In the GUI I can use Analyze > Decode as... > RTP

Searching on google I find two "ways" of doing this:

tshark -n -r file.pcap -o rtp.heuristic_rtp:TRUE -w p_out.pcap

and

tshark -n -r file.pcap -d udp.port==#,rtp -w p_out.pcap (where # is the port number)

neither of these work. When I open the p_out.pcap in wireshark it's still in UDP

What is the proper method for achieving this?

h264 udp rtp h264_decode tshark

asked 15 Feb '16, 23:42

testname0110
15●5●5●9
accept rate: 75%

edited 16 Feb '16, 00:35

sindy
6.0k●4●8●51

2 Answers:

When I open the p_out.pcap in wireshark it's still in UDP

The pcap (or pcapng, or any other capture file format) does not store the Decode as... or any other preferences. So whatever you tell tshark only affects that particular run. So what you did was actually an equivalent of cp file.pcap p_out.pcap.

So you could use "display filter" -Y rtp in combination with e.g. the -d udp.port==#,rtp to allow only RTP packets from the input file file.pcap to be written to the output file p_out.pcap, but to display them as RTP when you handle the p_out.pcap by tshark or Wireshark, the decode as still needs to be stored in your preferences folder (in case of Wireshark 2.0.1, the file name is decode_as_entries). Or you may use -o to tell tshark how to override/extend the stored preferences.

answered 16 Feb '16, 01:06

sindy
6.0k●4●8●51
accept rate: 24%

Are you saying that the changes are being made but only within that command line? So if I need the file in that format I need to pipe it immediately in the same command to use it in that format?

(16 Feb '16, 11:28) testname0110

No. I am saying that no changes are made at all, and I am saying that "piping the output to another application on a common command line" has nothing to do with it either. By specifying command line parameters to tshark, you are not modifying environmental values of the shell (which another application could look at) but merely controlling the behaviour of that tshark instance alone.

I am also saying that there is no way to associate any individual decode as rules to a particular capture file, which is what I suppose you want to achieve. You can define a set of static decode as rules in the basic preferences profile and/or additional preferences profiles you can switch among, but the rule set from the chosen profile will be used to any capture file, not just to a particular one.

Without the -w filename option, tshark's output is textual. With that option, its output is in a pcapng binary format, whose structure provides no room for specification of any dissection rules.

What you tell tshark is:

what dissectors to use for specific packets on top / instead of the default ones. This is the equivalent of manual Decode as... setting in Wireshark.
which packets to let through to the output, using the "display filter" and/or "capture filter" expressions. This is a direct equivalent of capture filter and display filter in Wireshark.
only if the specified output type is textual, i.e. if -w is not specified: which information from the packets elected by the display filter and in what form to display in textual form.

If you would use -w - to tell tshark that the format of the output shall be pcapng but stdout shall be used, and pipe that output to another instance of tshark (or to Wireshark), that other instance of tshark would not inherit the settings from the first one.

(16 Feb '16, 13:22) sindy

When I run "tshark -r file.pcap -o rtp.heuristic_rtp" it does indeed output the decoded, dynamic payload packets. But this is only during that thread of execution, so it is necessary to pipe the output where I want it immediately. But you are correct

(16 Feb '16, 14:50) testname0110

Back to the basics. Wireshark makes interpretations based on its knowledge on how network frames are composed. Therefore we start at the bottom.

For most common network frames the datalinktype is Ethernet. Therefore the (generic) frame dissector hands the received frame (read form the pcap file) to the ethernet dissector. This reads the beginning of the frame and decides it contains an IP packet, and hands the remainder to the IP dissector. The IP dissector decides it contains an UDP payload, and hands the remainder to the UDP dissector.

The UDP dissector now has a problem. The port number in the dissector doesn't uniformly identify the payload type, so it has to try to find out where to hand the payload another way. Sometimes there are other protocols in the capture which tell something (think SIP/SDP for example), sometimes the payload itself has a 'magic' value to identify the payload type.

For RTP there is very little to go on, unless an external signalling protocol identifies gives you the port numbers, the payload doesn't give you much to go on. That's where the option 'decode as' and rtp_udp preference come into play. These allow the operator to force interpretation of the UDP payload as RTP, because of the high probability of false positive identification of random UDP payload as RTP.

So, the capture file just contains network frames, it's the interpretation Wireshark makes of them that shows RTP.

answered 16 Feb '16, 12:44

Jaap ♦
11.7k●16●101
accept rate: 14%