Guy Harris wrote:
>
> On Jan 5, 2004, at 9:12 AM, Martin Regner wrote:
>
> > I also needed to do some small changes in epan/conversation.c and
> > epan/packet.h so that Ethereal will continue with other dissectors if
> > the
> > conversation dissector rejects the packet.
>
> In what cases would a conversation dissector reject a packet?
> Conversation dissectors are usually set up either for
>
> 1) earlier packets indicate that a future conversation will be using a
> particular protocol - e.g., RTSP or SDP specifies a future RTP/RTCP
> conversation
>
> or
>
> 2) a dissector needs to ensure that future packets that might not
> otherwise be handed to that dissector be handed to it (some heuristic
> dissectors might do to keep subsequent packets from being taken by
> other dissectors, and the TFTP dissector uses it to ensure that packets
> after the first one get dissected as TFTP)
>
> and in both of those cases the packets shouldn't be inappropriate.
>
> Is the problem that you have, in a capture, more than one conversation
> between two endpoints, the first of which is RTP and the second of
> which is T.38?
>
Hi,
The H.245 disector will always start a conversation when it sees a
mediaChannel in the H.245 message and the RTP dissector
will be put as the dissector to be called for the conversation. I have been
thinking to look into how to change that (I started to look into how to get
the information about dynamic payload types to the RTP dissector in some way
a while ago), but it might not be so easy since
the information about the logical channels (e.g. that logical channel 2 is
supposed to use T.38) is sent in OpenLogicalChannel and then
the OpenLogicalChannelAck is sent in another message (e.g. indicating that
logical channel 2 is using port 35001) and it may
also be that you only get the OpenLogicalChannelAck in the capture and then
you cannot do the matching that it's T.38 and so on.
In the capture I have experimented with (which I got from LFAIM since I seem
to have lost the UDPTL captures where I noticed similar problems myself)
there is the following scenario:
packet#4 Setup with Fast Start OpenLogicalChannel
(mediaChannel ip x.x.x.x port 19530 is in the message, so conversations will
be started for one direction).
This is actually a RTP session.
packet#5 Call Proceeding with Fast Start OpenLogicalChannel
(media Channel ip y.y.y.y port 16558 + ip x.x.x.x 19530 in the message, so
conversation will be started for other direction).
This is actually a RTP session.
packet#924 CloseLogicalChannel
packet#925 CloseLogicalChannel, OpenLogicalChannel (t38fax)
packet#928 OpenLogicalChannel (t38fax)
packet#932 OpenLogicalChannelAck
(mediaChannel ip x.x.x.x port 19530 is in the message, conversation already
started for that combination).
Now it's a T.38 session (but you may get still get some RTP packets during
the switch over from RTP to T.38 so the T.38
application may have to check if the packet has a low UDPTL sequence number)
packet#933 OpenLogicalChannelAck
(mediaChannel ip y.y.y.y port 16558, conversation already started for that
combination).
Now it's a T.38 session.
