On Nov 13, 2003, at 4:52 AM, Lars Ruoff wrote:
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??
You need more than an offset into the capture file to call a dissection
on a packet; you'd need the "frame_data" structure (which happens to
contain that offset).
* Is it feasible to redissect just a part of the packets, with only
the file
offset of each packet known?
No.
It *is* feasible to do so with the "frame_data" structure, however.
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...)
You'd need to duplicate what "redissect_packets()" does, but only have
it dissect the packets in that list, and somehow arrange that only the
RTP tap be called.
* 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
4 or 8 bytes per packet to store the pointer, plus list overhead. If
you use a GSList of the pointers, it's 4 or 8 bytes per packet of list
overhead, plus some probably-small amount of memory allocater overhead.
* 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)
Finding that offset might be possible, but not necessarily easy - you'd
have to find the offset of the beginning of the RTP data from the
beginning of the tvbuff for the frame, and add that to the offset of
the frame in the file.
And that doesn't work if there *IS* no offset between the beginning of
the RTP data from the beginning of the tvbuff for the frame, for
example if the UDP packet was fragmented and the RTP data is in a
tvbuff of reassembled data.
I would not recommend that approach.