Wireshark · Ethereal-dev: Re: [Ethereal-dev] H323 Analysis cleanup

[Lars Roland <Lars.Roland@xxxxxxx>]

Hi,

Francisco Alcoba (ML/EEM) schrieb:
> 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 
Doing step by step, we should first have a tap, which creates a list 
where each line represents an h323 call and the filter button will 
create an appropriate filter.
Then we should create a seperate similar taps for other voip protocols.

A tap for showing all RAS request/response pairs is something different. 
It shouldn't be integrated in the h323 call anaylsis tap. Instead it 
should use the infrastructure of the RAS SRT tap, as it already contains 
all information you need and it is much more stable than the h323 
analysis tap. I will have a look at this. I am sure that I can create 
such a tap quite fast by mixing the gui stuff of the h323 analysis tap 
with code of the h225 ras srt tap. :)

BTW, some of your code is redundant and can be replaced by more efficent 
code anyway. I will have a look at it, too.

> 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-.
You can do this by having seperate taps for each protocol, too.

> 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.
You don't need the information of the transport protocol, because you 
cannot choose between them. RAS messages have to use UDP, other h323 
messages have to use tcp. By having the message type you automatically 
know which transport was used. So I will prepare a patch to remove the 
redundant code. I will leave the rest of your code in it for now. But 
when we have a seperate tap for it, it should be removed, too.

Regards,
Lars