Ethereal-dev: [Ethereal-dev] [Patches] Navigating from RTP/RTCP packets to setup where it was

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Martin Mathieson" <martin.mathieson@xxxxxxxxxxxx>
Date: Tue, 8 Jun 2004 16:28:43 +0100
Hi,

I finally returned to "RTP Analysis - linking back to setup traffic?"
(http://ethereal.com/lists/ethereal-dev/200404/msg00537.html).  These
patches add 'setup method' and 'setup frame' fields into the RTP/RTCP
packets themselves rather than showing them in the RTP Analysis GUI.  This
info could later be added to the _rtp_info struct that is passed to the tap,
and displayed somewhere in the GUI, but for now I find it more useful in the
packets themselves.

These patches need a bit of review - in particular:

- I'm using modified versions of rtp_add_address() and rtcp_add_address() to
create the RTP and RTCP conversations.  These were previously unused but
wanted to register RTP/RTCP as heuristic dissectors.  Should they?  At the
moment I don't so there are new warnings that dissect_rt(c)p_heur() and
heur_init() are defined but not used.

- These _add_address() functions are called in 3 different places (SDP,
H.245 and RTSP).  I've followed the way SDP and H.245 used the
conversations, i.e. only interested in the server address+port (pass the
same address and port twice with the flags NO_ADDR2 | NO_PORT2  for new and
NO_ADDR_B | NO_PORT_B for find).  RTSP does it differently though, it loooks
like it's trying to make use of the client port (if known) as well.  Will
this ever catch more RTP/RTCP packets in practice, or is my use of the
add_address() functions OK...?  I'm not familiar with RTSP and don't have
any captures to play with (I also let my editor cull some trailing
whitespace in packet-rtsp.c)

- I removed the (unused) prototypes for proto_register_rtp() and
proto_register_rtcp() from the rtp/rtcp header files.

- There was a fair bit of copying/pasting between packet-rtp.c and
packet-rtcp.c, but I'm not sure if it can be avoided tidily

- If anyone found these fields annoying I could add preferences to turn them
off...

Regards,
Martin





Attachment: packet-sdp.c.diff
Description: Binary data

Attachment: packet-rtcp.c.diff
Description: Binary data

Attachment: packet-rtcp.h.diff
Description: Binary data

Attachment: packet-rtp.c.diff
Description: Binary data

Attachment: packet-rtp.h.diff
Description: Binary data

Attachment: packet-rtsp.c.diff
Description: Binary data

Attachment: packet-h245.c.diff
Description: Binary data