On Tue, Feb 19, 2002 at 11:26:40AM +0100, andreas.sikkema@xxxxxxxxxxx wrote:
> > > That is implementation dependant.
> > Dependent on what?
>
> The sample you have seen is from Netmeeting, which is, how shall I put this,
> different than most other H.323 endpoints.
Oh.
You mean that which segments contain what data is dependent on the
implementation of the endpoints.
That's interesting in the abstract sense, but Ethereal has to deal with
all of them, hence the heuristics I mentioned - an exactly-4-byte TCP
segment starting with 03 00 will be treated as a segment with only the
TPKT header, and a TCP segment starting with 03 00 <length> and followed
by something that one of the dissectors registered with TPKT recognizes
will be treated as a segment with the TPKT header and (some or all of)
the TPKT payload.
> For H.225 most of the time you see in one segment TPKT + H.225 CS
> (which means Call signalling btw), or the UDP RAS messages.
> Except of course Netmeeting, which always sends first a TPKT segment
> and then a Q.931 message.
>
> For H.245 I have seen these variants
> - TKPT
> - H245
Do you mean you've seen H.245 with *no* TPKT headers? The ASN.1 header
is sufficient to get the length (as per LDAP, for example), so the TPKT
header isn't necessary, but if one peer expects the header and the other
doesn't, that's not going to work.
If an H.245 message can be sent without a TPKT header, then, there has
to be some way to negotiate whether TPKT headers will be used or not.
Or do you mean you've seen the H.245 message by itself in a segment with
the TPKT header in the previous segment? If so, then this is just like
Q.931-over-TPKT.