Hello Jan,
[CC'ing ethereal-dev]
If the initial message (H.225 SETUP) spans more than one TCP segment, then
you may enocunter this problem as only the last packet required to
reassemble the H.225 message will match the h225 display filter. If you then
save only the packets that match the current display filter, you now loose
packets hence Ethereal cannot reassemble those packets anymore.
[To ethereal-dev now] We should enhance reassembly-and-matching code so that
this type of behavior does not occur anymore.
Regards,
Olivier
|-----Original Message-----
|From: Jan.Van_Opstal@xxxxxxxxxx
|
|Some more info:
|
|The problem only occurs when the originating client uses the Slow
|Connect scenario.
|When using a client which supports faststart, then the H.225 SETUP is
|visible after
|saving my trace ...
|
| Jan
|
|Jan.Van_Opstal@xxxxxxxxxx wrote:
|
|> Hi all,
|>
|> Currently, I am working with Ethereal 0.10.2 and I am facing the
|> following problem:
|> I have taken a trace of a H323 client (NetMeeting) calling another
|> H323 client.
|>
|> During the capture, I see that Ethereal has recognised the
|H.225 SETUP
|> message.
|> After I have made my call, I saved the packets currently displayed
|> (using filter: 'h225 or h245').
|>
|> When I later on open the saved capture file, the H.225 SETUP is just
|> shown as a TCP packet
|> and not as a SETUP ??? (I first I thought it was gone, but removing
|> the filter 'h225 or h245'
|> showed me the TCP packet ...)
|>
|> I have attached the trace to this email. The packet that I
|am talking
|> about is packet no. 3.
|>
|> Cheers,
|>
|> Jan
|>
|> Note: I can't use the 'Decode As ...' feature, since H.225 is not in
|> the list there ...