then we definitely need a tethereal version that outputs the graph in ASCII ! -z voip,callanalysis[,<filter>] :-) On Wed, 02 Feb 2005 01:20:00 -0800, Guy Harris <gharris@xxxxxxxxx> wrote: > Alejandro Vaquero wrote: > > > Attached is the new "Voip call analysis" patch file and a screen shot > > of a SIP to H323 interop call. It is based on Francisco Alcoba source, > > and added support of H323, RTP and a Graph analysis. The Graph interface > > can also be used in other no Voip analysis. > > I didn't see any references to "gtk" in a case-insensitive search of > "voip_calls.[ch]", so it appears that, at least for the graphing, the > Graph code handles all the GUI stuff - that's good, as it means that, > for other GUI tookits, a "graph_analysis.c" module would be needed, but > "voip_calls.c" would work with that without having to be changed. > "voip_calls_dlg.c" has GTK+ code - some other mechanism would be needed > to make that GUI toolkit-independent (and would be needed for other taps > that have a UI, if the taps are to be GUI toolkit-independent). > > > And the "Graph Analysis" has: > > - Graph up to ten columns or "nodes". Each "node" it is defined as an IP > > address. > > Perhaps "nodes" should be an array of "address" structures, as defined > in "epan/address.h"; the "data" member of those structures would > presumably point to mallocated data. Similarly, "ip_src" and "ip_dst" > would be "address" structures (and I'd advise making "port_src" and > "port_dst" 32 bits, in case some protocol has 32-bit values that would > correspond to port numbers). If that can be done, a node could be any > type of address in the "address_type" enum in "epan/address.h"; > "address_to_str()" could be used instead of "ip_to_str()". > > _______________________________________________ > Ethereal-dev mailing list > Ethereal-dev@xxxxxxxxxxxx > http://www.ethereal.com/mailman/listinfo/ethereal-dev >
Powered by MHonArc 2.6.10