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.
