Re: [Ethereal-dev] [patch] conversations demarked by setup frame number

[Jon Ringle <ml-ethereal@xxxxxxxxxx>]

On Tuesday 18 January 2005 02:01 am, Jon Ringle wrote:
> 1) Added a setup_frame parameter to conversation_t
> 2) Used the conversation_t next to maintain a list of conversations with
> the same src/dest tuple but different setup_frame number.
> 3) Changed the signature of find_conversation() and conversation_new() to
> pass in the frame number.
> 4) Adjusted packet-sdp to select RTP conversation if both m=audio and
> m=image are present, and T.38 conversation if only m=image is present. I
> expect that RTP/T.38 dissecting to be better, but I don't have a way to
> generate T.38 packets.

One additional comment I'd like to make is that I don't believe that the 
functional behaviour has changed for any protocol with this patch except for 
SDP setting up multiple RTP/T.38 conversations based on the setup_frame 
number. The reason is that find_conversation() will return a conversation if 
one exists for the src/dest tuple. All the dissectors that use 
find_conversation() before invoking conversation_new() only test for a 
preexisting conversation. A dissector needs to add additional logic after the 
call to find_conversation() to decide whether conversation_new() needs to be 
called anyway even if there is a preexisting conversation. For instance in 
add_rtp_conversation() there is a test to see if the setup_frame_number 
matches the setup_frame number returned from find_conversation():

p_conv = find_conversation( setup_frame_number, addr, &null_addr, PT_UDP,
			port, other_port, NO_ADDR_B | (!other_port ? NO_PORT_B : 0));

if ( !p_conv || p_conv->setup_frame != setup_frame_number) {
	p_conv = conversation_new( setup_frame_number, addr, &null_addr, PT_UDP,
		(guint32)port, (guint32)other_port,
		NO_ADDR2 | (!other_port ? NO_PORT2 : 0));
}

Jon