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

wanted RTP, got UDP (?!)



I decided to break a trace on three parts with filtering SIP, RTP and DIAMETER protocol. For SIP and DIAMETER it went ok - I filtered the original trace and saved it as a new (trace) file. When a new file was opened, it was displayed ok.

But now, when I filter the original file with RTP protocol, save it as a new file and then open this new file, instead of RTP it shows like I filtered with UDP protocol. Why? I don't want so...

Br Thomas.

asked 28 Apr '11, 16:43

wired's gravatar image

accept rate: 9%

Is the answer inside here?:

Protocol dependencies

UDP: Typically, RTP uses UDP as its transport protocol. RTP does
not have a well known UDP port (although the IETF recommend ports
6970 to 6999). Instead, the ports are allocated dynamically and
then signalled using a different protocol such as SIP or H245.
In SIP and other protocols a RTP session is described by SDP
(Session Description Protocol), which is not really a protocol
itself but rather a formalised way to describe a media session.
(28 Apr '11, 16:54) wired

One Answer:


Wireshark parses the SDP information in the SIP packets to learn about the upcoming RTP sessions. So, without the SIP packets, it does not know that the UDP packets are actually RTP packets. Possible solutions:

  • Save both the SIP and RTP in a new file and it should decode OK
  • Use "Decode as..." to decode the UDP packets as RTP
  • Enable the "Try to decode RTP outside of conversations" setting in the RTP protocol preferences

answered 28 Apr '11, 22:52

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%


I decided to use the third option (RTP preferences). At first I intended to choose the second option (decode as), but I'm not sure whether to choose transport on UDP source, UDP destination or both. (What's the point of choosing between these three options?)

(29 Apr '11, 03:57) wired

(I converted your "answer" to a "comment", as that's the way this site works best, see the FAQ)

For your purpose there is not much difference, as both ports will be dynamically chosen. But imagine an http-server on port 8080, then you want to decode all traffic to/from port 8080 as HTTP.

So in that case, choosing the other (dynamic) port will only decode that specific session as HTTP.

(29 Apr '11, 04:06) SYN-bit ♦♦