Lars Ruoff wrote:
> This question is with regard to priorities of the various sub-dissection
> mechanisms:
> For clarity, let me define the different sub-dissection mechanism as:
> - "parent": subdissection based on info or preferences in the parent (lower
> level) protocol. (for example IP -> UDP)
> - "user": as choosen by the user in Decode As...
> - "session": dissection based on session protocols, such as for example RTP
> conversations initiated by H.225 etc.
> (is this handled with "conversations"?)
> - "heuristic".
>
> As i see it, the order in which these subdissections are tried out is:
> parent, session, user, heuristic.
> (I'm not sure about the "parent", but thats not available on for example the
> UDP layer anyway, see below)
>
> Is it that way?
> Now, the question i ask myself is if "user" shouldnt have the highest
> priority?
>
> For example: i wanted to force decoding of some channel to T.38 (because it
> WAS T.38 at some point). However the channel was decoded as RTP by H.225.
> Doing a "Decode As.. T.38" will not change anything. You will have to
> disable H.225 in order to see the packets decoded as T.38.
> This is not very user-friendly at least.
>
> and in this same context:
> If you choose "try heuristic dissectors first" in UDP preferences, before
> what will the heuristics come?
>
>
If there is a conversation then the packet will not be dissected other dissectors
even if RTP dissector would reject the packet.
There are quite many changes that needs to be done in order to solve the
T.38/RTP problem in a good way. The way conversation is working needs to
be changed and then it can be complicated to solve the H.245 stuff at least.
For SDP it may be a bit simpler.
On way to tempoarily solve the problem for T.38 is to change so that the SDP/H.245 dissector starts up
convesration with "t38" instead of "rtp", and use the "feature" I added that T.38 dissector
will call the RTP dissector if the packet looks like RTP (Preference in T.38 dissector).
Then you will normally get T.38 decoded as T.38 and RTP as RTP.
The disadvantage will be that T.38 dissector will be called for each RTP packet.
I have built some special versions of Ethereal that I uses when look into T.38 where I
have done such a change.
The new preference setting can be sueful to handle the Decode As when same port used for both RTP and T.38,
but it will only work if no RTP conversation has been started for that port number.
Use "Decode As..." T.38 and set the preference setting in T.38 dissector to decode packets
that looks like RTP packets with the RTP dissector.
Another way I did it was to change the code so that Ethereal would continue with another dissector
even for conversations. It was just a few small changes I needed to do. I sent some mails
to ethereal-dev about it in January or so.