On Tue, Feb 19, 2002 at 09:57:45AM +0100, andreas.sikkema@xxxxxxxxxxx wrote:
> H323 is a couple of protocols stacked onto each other.
With a pile of specification documents that appear to be available only
in @#$$@$%$ Microsoft Word format - no PDFs.
> There's H.225 RAS which is simple straightforward UDP.
> H.225 Call signalling is TPKT + Q.931 + H.225 CS
> H.245 is TPKT + H245
> And there is off course the media, RTP and RTCP
>
> So from the existing Q.931 dissector I would try to load my H.225
> plugin.
The current CVS version tries to find a dissector with the name
"h225_cs" ("cs" for "Call Setup", which is what I infer that stuff is
for), and, if it finds it, calls it if it's TPKT-encapsulated Q.931 and
it sees a user-user Information Element with a protocol discriminator of
"Q.931". (If it doesn't find the dissector, it just dissects the IE's
data as a single "User Information" item, showing the raw bytes.)
> To be able to decode H.245 I have to tell the H.245 dissector from
> thew H225 dissector which conversation(s) it can dissect.
I.e., the H.225 dissector has to create TCP conversations and make the
H.245 dissector the dissector for them? (I infer from
http://www.packetizer.com/iptel/testtools/images/ethereal_h245_decode.jpg
that H.245 runs atop TCP.)
> From H.245 I have to tell the RTP/RTCP dissectors which conversations
> they should dissect.
I.e., it'd create conversations and associate RTP and RTCP with them, as
the RTSP dissector does?
> I don't think you can do this with only adding a H.225 and H.245
> dissector, I would have to do some magic in the plugin interface by
> exposing the RTP/RTCP and TPKT dissectors...
I'm not sure the RTP and RTCP dissectors are an issue - see how
"packet-rtsp.c" does it. It just gets handles for the RTP and RTCP
dissectors, and uses "conversation_set_dissector()".
TPKT is both a dissector (for port 102, as per RFC 1006) and a set of
service routines for other dissectors to use.
A heuristic TPKT dissector would be a bit difficult, as the check for a
TPKT header may not be enough to avoid false positives. If it's not, it
could handle protocols that put a protocol discriminator at the
beginning (such as Q.931, although you might also want to add a
minimum-length check) without too much difficulty, but it looks as if
H.245 just uses ASN.1, so there's no protocol discriminator.
It could, instead, allow subdissectors to register both "checking" and
"dissecting" routines - it'd have a list of "checking" routines, which
would be handed a tvbuff containing the TPKT payload and:
1) not ever throw an exception;
2) not modify the columns or protocol tree;
3) return TRUE or FALSE depending on whether the tvbuff appeared
to contain a PDU for that protocol;
and, for each of the "checking" routines, a matching (non-heuristic)
"dissecting" routine.
The TPKT dissector would have a routine to be called by subdissectors to
register their "checking" and "dissecting" routines. That routine would
be added to the plugin API table for use in Windows.
(Given that captures such as the one listed above and
http://www.packetizer.com/iptel/testtools/images/ethereal_h2250_decode.jpg
seem to show TPKT headers in a TCP segment by themselves, the heuristic
TPKT dissector should probably treat as the beginning of a TPKT PDU a
TCP segment that either
1) contains exactly 4 characters, the first two of which are 3
and 0
or
2) a TCP segment that begins with 3 and 0 and, after the length
field, has enough payload for one of the heuristic dissectors
to identify as one of its PDUs.
The TPKT dissector would do the standard packet-with-header-field stuff
atop TCP, complete with TCP segment reassembly, handling multiple PDUs
per TCP segment, etc..
