Guy Harris wrote:
> On Jan 8, 2004, at 11:03 PM, Martin Regner wrote:
>
> > It will certainly not be possible to implement this before next
> > version of
> > Ethereal, so can you please have a look at just the packet-t38.c file
> > I sent
> > in my previous message
> > http://www.ethereal.com/lists/ethereal-dev/200401/msg00085.html
>
> I've checked that in, with a change to a comment to note that #1 is a
> temporary hack and should be handled by allowing conversations to be
> closed.
Actually the problem that is solved with the new preference setting
dissect_possible_rtpv2_packets_as_rtp in T.38 dissector (point#3 in my
original mail, point#1 in your comment above) will not be solved by allowing
conversations to be closed.
The new preference setting is and will be useful for scenarios where there
is no H.245 signalling in the capture or similar.
I have some T.38/UDPTL captures where the H.245 signalling is missing (e.g.
captured only UDP packets or didn't capture the H.245 packets
of some other reason) and then you have to use the "Decode As..." method,
but if you mark one packet and indicate that port 6005
shall be decoded as T.38 you will get that both the RTP packets and the T.38
(UDPTL) packets will be decoded as T.38 since they are sent on the same port
numbers (some packets will be indicated as Malformed, but since it's really
possible to have UDPTL sequence numbers above 32767 not all of them will
even if it's not normal with so high sequence numbers).
The new preference setting in T.38 dissector will however not solve the
problem LFAIM noticed. Point#1 and point#2 in my original mail (changes in
rtp.c, conversations.c and packet.h) intended to solve that problem until
the conversation handling for H.245 is solved. Since conversations have
higher priority and H.245 dissector now always starts a conversation so that
RTP dissector is called you will normally see T.38 packets as RTP packets
with "unknown version: 0".
This problem will be solved when it is possible to close conversations and
H.245 dissector has been updated as discussed in some other mails.
But I guess that it will take some time to fix everything realeted to this.
It could be possible to, just as a temporar solution, add a preference
setting in RTP to decode packets with other RTP version than 2 with the T.38
dissector, but I don't know if T.38 and RTP are the only UDP based protocols
that could be signalled via H.245 (or SDP in case if there is similar
problems for SDP) etc.
T.120 seems to use TCP so you will not get this problem for T.120.
The RTP dissector may not be able to sort out which dissector to call in a
good way, so the idea with point#1 and point#2 in my original mail was that
RTP dissector could reject packets that doesn't look like RTP version 2
packets (but only when the user had specified that with a preference
setting) so that Ethereal could call other dissectors in the normal way
(based on port number tables and heuristics, so that you could e.g. use
Decode As.. to decode the other packets with T.38 dissector).
When I started with making the patch I actually thought that Ethereal would
continue with other dissectors as in other cases where a packet is rejected
by a dissector. I still think that there *might* be some scenarios where it
may be relevant that packets are rejected for a conversation, especially
when conversations may be setup with just one ip-address and port. However
rejecting packets that are malformed is not always so good, so I prefer that
non-heuristic dissectors that are using the rejection mechanism should have
a preference setting whether to reject packets that are not matching the
pattern and that the checks are just some checks that will not fail if there
is just some small error in the packet or similar.
