Wireshark · Ethereal-dev: RE: [Ethereal-dev] Transform "H323 Conversations" to a more gener ic "VoIP Convesations"

["Francisco Alcoba (TS/EEM)" <francisco.alcoba@xxxxxxxxxxxx>]

Hi,

> Miha Jemec wrote:
>
> I agree we should have a framework for decoding VoIP and other
> conversations, where adding a new protocol should be trivial. 
> My opinion
> is that in this case we shouldn't fix the column with predefined names
> and values like IP, IP:port, status, etc... because not all 
> use the same
> parameters (f.e. faststart is H323 specific). So maybe we should have
> some general routines similar to those in 
> h323_conversations_dlg.c (plus
> some fromh323_conversations.c) and could be the same for all 
> protocols.
> This routines would be able to draw the dialog window, register the
> taps, specify the filter and other general stuff. They could be called
> from the menu list and depending on which protocol was choosed
> (Menu->Conversations->H323, Menu->Conversations->SIP,
> Menu->Conversations->...) with the parameters required to do 
> the actual
> decoding: title, number of columns, columns names, protocol used, ... 

If you do it just with Menu->Conversations->VoIP, then you can have all the protocols on the same window. The advantage is that you can follow a call that is translated -i.e. incoming ISUP call that relates to a MEGACO context, then gets translated into SIP...-. I think you can do that if you choose columns that are generic enough -time, protocol, number of packets...- and leave protocol specific information for a "Comments", or "Protocol specific"... one. On the other hand, if the mechanism is generic you might use it afterwards for any session-oriented protocol, like GTP.

> 
> With this approach you can add any new protocol but you have to write
> all the tap routines. The question is, is it possible to 
> write also the
> tap routines in a general way, without getting to much limitations?

The problem is that the tapping info is different for each protocol. For instance, SIP sends the Call Identifier as a string, but ISUP/MTP send the Signalling Point Codes and CIC as numbers, and you need the information from both (ISUP and MTP3) dissectors. So, you need to either adapt to this in the "conversations" module or in each dissector -i.e. force all of them to send the information in the format the conversations module can use it, force synchronization between ISUP and MTP3, or H225 and H245...-.

Regards, 

 Francisco