Hi,
> > Francisco Alcoba (ML/EEM) wrote:
> >
> >> 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.
> >
> IMO it was a bug, that H225 over udp converasations were shown in the
> dialog. Thus I have removed them.
> So, my previous patch makes your patch probably useless as the
> conversations you look for aren't available any more.
>
> However I don't think we should add H225 RAS conversations as single
> H323 conversations. Instead we should use the Call Identifier
> to add all
> packets related to a call to one H323 conversation, including RAS
> messages (I would call it a "call").
I agree on the best direction being the Call Identifier, if you need to choose. However, there are RAS messages that are not call related, and so have no Call Identifier -like Registration Requests-; I still think something like an H225 display of all messages from one direction, which would include this RASes, might be useful -maybe as an alternative-. In fact, I'm thinking that it might be useful to rework the functionality into something like:
- a call list that shows calls -maybe with calling and called identities for reference- and allows you to set the Call Identifier as a filter
- the generic possibility to display whatever the main window is displaying as a flow
That would make it possible to match different protocols. Let's say you can have a conversation list that allows you to filter for an H.323 call, other -or the same- that allows you to select a SIP call, and another for an ISUP call. If all of that can end up into a display filter, and then you can select the Analyze function on that display filter, then you can picture them together. In fact, you might include packets that are not VoIP related and use the Protocol+INFO fields in the display to identify them. If you are going to try and analyze a capture, identify different speakers and display their flow, it seems a pity not to make it usable for every protocol -this is something I have been thinking on for a time-.
Anyway, I made the patch because in its present state it does not work with Call References, and even though I agree it should, I don't know if it will. While it works with addresses and ports I think it would be good include the transport.
