Wireshark-users: Re: [Wireshark-users] [Wireshark-dev] RTCP Frame length check: Wrong
Hi,
That's:
Network Working Group D. Wing
Request for Comments: 4961 Cisco Systems
BCP: 131 July 2007
Category: Best Current Practice
Symmetric RTP / RTP Control Protocol (RTCP)
Thanx,
Jaap
Anders Broman wrote:
Most applications tend to use the signalled RTP port pair
As SRC and DST.
A -- SDP port Y--> B
<--- SDP port-- X
-- RTP SRC Y DST X -->
<-- RTP SRC X DST Y
Some Firewalls assumes this and will block traffic not following this
"rule". I haven't found any RFC to support the above behaviour but in
Practice almost every one seems to follow it and it seems like a good idea
to design your application that way as there may be interworking problems
otherwise.
Regards
Anders
-----Ursprungligt meddelande-----
Från: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] För Guy Harris
Skickat: den 14 april 2009 00:41
Till: Community support list for Wireshark
Kopia: shivani matta
Ämne: Re: [Wireshark-users] [Wireshark-dev] RTCP Frame length check: Wrong
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.
