Wireshark-users: Re: [Wireshark-users] [Wireshark-dev] RTCP Frame length check: Wrong
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 13 Apr 2009 15:40:39 -0700

On Apr 10, 2009, at 9:17 PM, Guy Harris wrote:


On Apr 10, 2009, at 11:56 AM, Guy Harris wrote:

Packet 63 in the capture you sent, which only dissect as RTCP in my
version of Wireshark if you explicitly use "Decode As" - even the
heuristics aren't recognizing it as RTCP.

I'll see whether the heuristics can be changed.

They were checking both the source and destination port, for both RTP (checking for even ports) and RTCP (checking for odd ports). RFC 3550 says, in section 11 "RTP over Network and Transport Protocols":

RTP relies on the underlying protocol(s) to provide demultiplexing of
   RTP data and RTCP control streams.  For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
RTCP stream SHOULD use the next higher (odd) destination port number.
   For applications that take a single port number as a parameter and
   derive the RTP and RTCP port pair from that number, if an odd number
   is supplied then the application SHOULD replace that number with the
   next lower (even) number to use as the base of the port pair.  For
   applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.  The
   RTP and RTCP port numbers MUST NOT be the same since RTP relies on
   the port numbers to demultiplex the RTP data and RTCP control
   streams.

That says nothing about the source port; I've removed the source port checks from the RTP and RTCP heuristic dissectors. We'll see whether that results in any packets being misidentified as RTP or RTCP.