Can you not change
packet#928 OpenLogicalChannel (t38fax)
packet#932 OpenLogicalChannelAck
so that if they detect it as being a t38 channel that it will change the
conversation to be t38 instead?
You would also have to change all :
conv=find_conversation(&src_addr, &src_addr, PT_UDP, ipv4_port,
ipv4_port, NO_ADDR_B|NO_PORT_B);
if(!conv){
conv=conversation_new(&src_addr, &src_addr, PT_UDP, ipv4_port,
ipv4_port, NO_ADDR_B|NO_PORT_B);
conversation_set_dissector(conv, rtp_handle);
}
into
conv=find_conversation(&src_addr, &src_addr, PT_UDP, ipv4_port,
ipv4_port, NO_ADDR_B|NO_PORT_B);
if(conv){
conversation_delete(...
}
conv=conversation_new(&src_addr, &src_addr, PT_UDP, ipv4_port,
ipv4_port, NO_ADDR_B|NO_PORT_B);
conversation_set_dissector(conv, rtp_handle);
as well but that should probably be done anyway sooner or later.
then add something similar when t38 is created.
----- Original Message -----
From: "Martin Regner"
Sent: Tuesday, January 06, 2004 8:53 PM
Subject: Re: [Ethereal-dev] [PATCH] T.38 dissector improvements
>
> 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.
>
>
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
