[Guy Harris <guy@xxxxxxxxxxxx>]

On Fri, Nov 14, 2003 at 09:47:53AM +0100, Lars Ruoff wrote:
> So, from within the tap routine i would have to make a copy of *(pinfo->fd)
> and store that?

No.

>From within the tap routine, you would make a copy of pinfo->fd, and
store *that*. :-)

(I.e., "pinfo->fd" points to a data structure that lives at that address
as long as the current capture file is open; you do not need to make a
copy of it, you only need to save the pointer value from "pinfo->fd".)

> > 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.
> 
> Ok, but there is another problem:
> Packet dissectors will call those col_XXX_str functions for constructing the
> entries of the packet CList.

Only if you ask for it, by passing a non-null "cinfo" argument to
"epan_dissect_run()".  If you pass null, "col_check()" always returns
FALSE, so none of the "col_XXX_str" functions will be called.

> > > * 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)
> *snip*
> > I would not recommend that approach.
> 
> Do you mean only the last alternative or the entire idea of speeding up RTP
> analysis?

Only the last alternative.