[Ruud Linders <moztest@xxxxxxxxxxxxxxxxxxxx>]

Here is a patch (against nightly build 2004-07-02) to prevent both
RTCP and RTP to create conversations when the respective protocols
are disabled.

It solves for me the problem that in packet-sdp.c the function
rtp_add_address(... srcport ...) is blindly followed by
rtCp_add_address(..srcport+1...).
Since the SDP decoder can't now if RTCP is present or not, that
seems to be the only way to create a conversation for RTCP.
(IFF RTCP is present, it IS at the RTP port + 1)

However, in my trace there were no RTCP but instead RTP packets
at the srcport+1 which were subsequently decoded wrongly as RTCP.


Regards,
	Ruud Linders


--- packet-rtcp.c.20040702	2004-06-30 23:08:58.000000000 +0200
+++ packet-rtcp.c	2004-07-03 18:38:57.000000000 +0200
@@ -248,6 +248,13 @@
 	struct _rtcp_conversation_info *p_conv_data = NULL;
 
 	/*
+	 * If protocol isn't enabled, we shouldn't create a conversation
+	 */
+	if (!proto_is_protocol_enabled(find_protocol_by_id(proto_rtcp))) {
+	  return;
+	}
+	    
+	/*
 	 * If this isn't the first time this packet has been processed,
 	 * we've already done this work, so we don't need to do it
 	 * again.
--- packet-rtp.c.20040702	2004-07-01 08:59:38.000000000 +0200
+++ packet-rtp.c	2004-07-03 18:40:31.000000000 +0200
@@ -203,6 +203,13 @@
 	struct _rtp_conversation_info *p_conv_data = NULL;
 
 	/*
+	 * If protocol isn't enabled, we shouldn't create a conversation
+	 */
+	if (!proto_is_protocol_enabled(find_protocol_by_id(proto_rtp))) {
+	  return;
+	}
+
+	/*
 	 * If this isn't the first time this packet has been processed,
 	 * we've already done this work, so we don't need to do it
 	 * again.