The code does not compile neither for Gtk1 or for Gtk2
Gtk1 complains about missing definitions for g_strl...
Gtk2 complains about a lot of unused variables and fails shortly thereafter.
Please provide a real diff -c diff that also updates the appropriate
makefiles (Makefile.am Makefile.nmake)
and updates to ethereal.pod.template documentation when it compiles.
----- Original Message -----
From: "Lars Ruoff"
Sent: Saturday, August 23, 2003 1:10 AM
Subject: [Ethereal-dev] Proposal for replacement of tap_rtp.c
>
> Hi,
>
> i present a new version of the RTP analysis module for the GUI version of
> Ethereal.
> It completely replaces Miha Jemec's "tap_rtp" (accessible via
> Tools/Statistics/RTP Analysis...).
>
> For the moment, there is no real extension of features (apart from the
> streams list, which i will explain later),
> but the main difference lies in the code, which i completely reviewed and
> refactured:
> - It is much clearer now and easier to read (Sorry Miha, but you will
agree
> on that the old one was really a mess in some places).
> Now there is a strict separation between logic- and GUI- stuff.
> - The code is more modular. The analysis window can be shown from
anywhere.
> Its entry point is declared in a .h-File, so it can be called from
anywhere
> (as long as the needed parameters are provided), without having to know
> anything about the tap system.
> - There can be multiple analysis windows open (meaning that each one keeps
> track of its personal data)
> - There is a new feature which i called the RTP Streams list, and a dialog
> associated with it, which shows all different RTP streams (identified by a
> SSRC) present in the capture.
> This is nice for a quick overview of all RTP traffic.
>
> This is how it works:
>
> First a brief recapitulation on how the old tap_rtp worked:
> It would take the src-ip,-port, dest-ip,-port and SSRC from the selected
> packet. (If selected packet was not RTP it would return with an error
> message).
> With this data, it would do a first redissection to find the SSRC of the
> reversed direction.
> If more than one stream with reversed parameters would be found, the user
> would have to choose from a list box.
> Then the second (main) redissection would be carried out, to analyse
delay,
> jitter and sequence numbers of forward and reverse streams.
>
> Here is how the new module works:
> There is one tap listener that is connected constantly and keeps
up-to-date
> a global list with ALL RTP streams present in the capture.
> This list can be viewed with an associated dialog box via
> "Tools/Statistics/RTP Streams.../Show all".
> The analysis function has been moved to "Tools/Statistics/RTP
> Streams.../Analyse".
> There is no more need for the first dissection, since the data can be
> retrieved from the global RTP streams list.
> Again, if more than one stream with reversed parameters are be found, the
> user will have to choose.
> But now, he can do so directly in the RTP streams dialog box, which will
be
> displayed in that case, with the selected forward stream at the head of
the
> list and all possible reverse streams following.
> The dialog box allows to make two selections: one for the forward and
> reversed direction.
> The user needs to choose the streams and press "analyse".
>
> The user may also decide to start directly with the RTP streams dialog,
and
> use the "analysis" button on any pair of two selected streams.
> (This is also the default, if no packet is selected when activating
> "Tools/Statistics/RTP Streams.../Analyse")
>
> The new module comes in form of 6 files (3x.cpp, 3x.h) instead of one as
the
> old one. :-/
> But this is to reflect the modularity:
> - rtp_analysis is the direct successsor of tap_rtp and represents the
> analysis tap and dialog box.
> (GUI and logic still in one file, but much better seperated within)
> - rtp_stream is the logic part of the stream list and -tap (it does not
> depend on GUI stuff and could be used in tethereal as well, if useful).
> - rtp_stream_dlg is the GUI-part of the stream list.
> ALL 3 .c-files can/have to be declared as ETHEREAL_TAP_SRCs in the
> /gtk-makefile (for make-ethereal-tap) !!!
> If rtp_stream.c is delcared, the stream list tap will be registered on
> start-up.
> Otherwise it will be registered on demand. (Perhaps better this way, since
> not everyone needs the tap running on his dissections!)
>
> (Just replace tap_rtp.c with these 3 files anywhere you encounter it in
the
> makefiles - this should do)
>
> A final note:
> The development was made with some very specific user request in mind, for
a
> proprietary extension we use here at our office.
> So i provide this "as is" to whoever might it find useful.
> Decide yourself if it will be useful for a check-in for a future version
of
> Ethereal.
> Comments will be appreciated.
> Thanks go to Miha Jemec for its original code, which i took over to about
> 75% in rtp_analysis.
>
> Tested on Win32/MSVC6 only!
>
> I will continue development on this, with the following planned features:
> - Additional analysis on tagging errors, payload changes, blanks in the
> conversation, ...
> - A conversation diagramm showing packet distribution over time and
> occurence of errors.
>
> Lars Ruoff
>
----------------------------------------------------------------------------
----
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
