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
>
