On Tue, Feb 19, 2002 at 11:26:40AM +0100, [EMAIL PROTECTED] 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.
