|
<Recently, I got some H.323 capture sample
in tcpdump format.
<The tcp server port of the H.225 Setup message
is TCP 1721
<but not the default 1720. I found that some 3rd
party analyzer
<like Sniffer cannot decode that mesage in H.323
but living it
<undecoded. However, Ethereal can well decode
those non-standard
<H.323 setup message. May I understand what
magic stuff making
<Ethereal be able to decode those non-standard
traffic?
<By intellegent pattern trigger decoding
library?
Ethereal uses different mechanisms for different
protocols.
Ethereal will normally recognize H.225-CS over
TPKT (or really Q.931 over TPKT) even if it is not sent on the
normal
port numbers since there is a heuristic dissector
for Q.931 over TPKT (implemented in the file packet-q931.c) that will
look for a certain pattern
in the TCP payload (a TPKT version 3 header
followed by the Q.931 protocol discriminator):
03 00 xx xx 08
Further on when Ethereal dissects a H.225-CS
message with a H245Address field it will start up a "conversation" so that
also
non-tunneled H.245 signalling will be recognized
even if dynamic port numbers are used for that signalling.
However if you have just captured H.245 over TPKT
without the corresponding H.225.0 signalling the H.245 over TPKT
messages
may not be decoded as H.245 over TPKT. But you can
use the "Decode As" functionality in that case.
For H.225-RAS it is required that the standard
port numbers (1718, 1719) are used in order for Ethereal to decode the
packets automatically, I think.
If non-standard port numbers are used then you can
use the "Decode As..." functionality.
Unfortunately it is not possible to save "Decode
As.." settings so that they can be used each time Ethereal is started, but maybe
someone will
add that functionality later on.
|