Ethereal-dev: Re: [Ethereal-dev] RTP analysis. Same SSRC for several streams causes problems
please send changes in as diff instead of entire files.
it makes it much easier ti review them.
ethereal is slower when it needs to evaluate filter strings.
this is a feature since this makes filtering work.
faster ways to filter like
"check if it is NFS by verifying that the network order 32 bit integer at
position x in the frame has
the value 100003" does not work since it will not catch NFS over ICMP
nor will it catch any packets where one of the headers have changed in size
making that style of filtering useless.
redo the test by also having a colorfilter or display filter active.
this is a realistic scenario and will show how much slower its gets by
using rtp_tap filter.
maybe your test only shows how much slower ethereal gets by calling the
filtering
subsystem compared to when it can skip filtering completely.
----- Original Message -----
From: "Miha Jemec"
Sent: Wednesday, March 12, 2003 4:26 AM
Subject: Re: [Ethereal-dev] RTP analysis. Same SSRC for several streams
causes problems
> Hi,
>
> here are some proposal for modifications:
>
> 1. Instead of filtering the frames with the filter passed to the
> register_tap_listener( , , filter, , ) I putted the check for the IP
> values inside the rtp_packet() routine (not yet about port values or
> icmp packets). It is doing the same but there is a big performance
> impact: with a VoIP conversation over half an hour and approx. 126000
> RTP packets it takes about 90 s to do the decoding with the filter
> expression and about 45 s with the condition inside the rtp_packet(). I
> don't know why but there is a warning inside README.tapping that the
> filter passed to tap listener should be avoided.
>
> 2. Like Tomas proposed I changed the packet-rtp.c. It now always (not
> dependant on condition that if (tree) must be TRUE) returns the length
> of the RTP data, the length of padding bits and offset, even if extra
> fields for extension, padding or CSRC are enabled. The beginning and
> the length of the RTP data is calculated like:
>
> cfile.pd (not yet with tvb)+ (pinfo->fd->pkt_len - pri->info_payload_len
> - pri->info_padding_count)
>
> so the current frame + the whole packet length - padding bits (if any) -
> the RTP data
> Since the length of different possible headers can vary, I don't know
> how to pass the beginning of the RTP data but from the end.
> If the padding count is bigger then the whole RTP data, then this is an
> error and we stop saving in a file.
>
> 3. Now the first packet get the indication SET if marker bit is set.
>
> I did some quick testing with extension and padding but since I need
> some more time to modify my RTP generator to send padding bits any test
> results would be grateful.
>
> Regards,
>
> Miha
