Hi,
The code adds H323 conversations over UDP to the conversation list, but it does not analyze them or sets them as filter because it later assumes the transport is TCP. I have added a parameter to remember the transport and build the filters accordingly. A couple of issues, though:
1) I have diff'ed it agains the code in the 2004-09-30 tarball, that I think does not include the changes referred below. This is because I don't know how to apply a diff to the source code I have. If someone can please explain me how to do this -in Windows- it would be very useful, and I can do the diffs again properly. I don't think the codes collide, but it would be safer.
2) I don't really know if there can be H225 over anything that is not UDP or TCP, so I've included an integer parameter, not a boolean. However, this makes the string definition in h323_conversations.h a bit bulky. If someone knows for sure that only UDP or TCP are/will be possible, or if someone knows of anywhere else in the code where such a string definition is stored -I have looked for it without success- it might be replaced.
3) Does someone know what would happen if the H225 packet is encapsulated -e.g. in GRE-? Would the code receive the addresses, ports, protocol of the encapsulating or the encapsulated packet? I have no trace with which I can test that.
Regards,
Francisco
> Hello all,
>
> Having a closer look at the new and very useful H323 Call Analysis
> feature, I have found some bugs and unnecessarily complicated
> code for
> managing the registration of the tap listeners. So I decided
> to rewrite
> this part of the source code. This part of the code is much
> smaller now.
> Unnecessary and wrong calls of register_ethereal_tap() and
> register_tap_listener_xxx() have been removed or replaced.
>
> I also fixed a bug with RAS Messages.
>
> Please check in.
>
> H323 Call Analysis works currently only with direct calls,
> support for
> calls involving a gatekeeper is missing.
> The mechanism for matching h323 packets to a specific call is
> currently
> based on ip addresses and port numbers. At least for h225 packets we
> should use the call id instead.
>
> BTW the usage of register_ethereal_tap() in the rtp taps needs to be
> fixed, too.
>
> Regards,
> Lars
>
>
>
Attachment:
h323_analysis.h.diff
Description: Binary data
Attachment:
h323_analysis.diff
Description: Binary data
Attachment:
h323_conversations.c.diff
Description: Binary data
Attachment:
h323_conversations.h.diff
Description: Binary data
Attachment:
h323_conversations_dlg.c.diff
Description: Binary data
