Hi list,
In the context of the RTP analysis module which i helped to develop, i
thought of ways to increase performance of the stream analysis.
The context: I often work with *large* capture files with *many* RTP
communications.
Currently, when you analyse a pair of RTP streams, a redissection of all
packets is made, and the rtp_analysis tap is called for each in order to do
the analysis computations on those packets of the selected stream.
This i consider a waste of time in the case where you have a large capture
file and the stream in question is made of only let's say 1% of the packets
from the file.
The notable thing about this is that *all* packets have already been
dissected once by the rtp_streams tap and this information could potentially
be used to flag the packets belonging to a particular stream and to limit
dissection/analysis to those packets.
So the question is:
Would it be worthwhile to build a list of (offsets to the) RTP packets of
each stream and speed up the analysis part by calling the dissection only
for those packets??
especially:
* Is it feasible to redissect just a part of the packets, with only the file
offset of each packet known? How to start? I'm not an expert on this.
(what about tap initialisation, packet dissector initialisation,
other taps would only see part of the packets and get mangled up?, etc...)
* This solution requires some memory to be used permanently for keeping the
packet list of each RTP stream. (Typically only a few bytes per packet for
storing file offset of the packet - that's not much compared to the amount
of memory that is used for each entry in the packet CList).
As always this is a choice between memory and speed - what should be
favoured? i tend towards speed.
* Alternatively, only offsets to the RTP data itself (i.e. UDP payload)
could be stored in the list and the rtp_analysis would work directly with
these, instead of using the tap mechanism. (i.e. packets will not be
redissected at all)
What do you think about these questions/ideas?
best regards,
Lars Ruoff.
