On Tue, Nov 25, 2008 at 07:26:13AM +0100, Anders Broman wrote:
> > I am using tshark 0.99.7 to filter out RTP traffic from a tcpdump trace
> > file. I have discovered that 3 DNS streams had been dissected as RTP
> > traffic.
Any particular reason that you use this old version? If not, please use
a recent version, see below...
> > I have looked through the code, including packet-rtp.c and packet-sdp.c
> > files. From what I understood, my hypothesis is that:
> >
> > Only SDPs information, which consists of source IP address and source port
> > (media port) are used to register for a RTP conversation. This registration
> > will be used to dissect subsequent RTP packets.
IIRC, there has been a patch submitted that makes the RDP dissector use
both src & dst ip & port for the conversation now. But I could be
wrong...
> > In my case, the DNS streams had the same source IP address and source port
> > as a previously registered RTP session. Hence they were dissected as RTP
> > streams.
>
> Your analysis is correct. I think conversations is set up indefinitely.
> We would need something like a last frame indication, a conversation only
> exists between frame x and y and a way to set that
> when a call is terminated.
For TCP, I recently added code to make Wireshark start a new
conversation when a SYN is encountered. As there is no connection and
therefor no connection start or termination packets for UDP, we could
just add the option of a 'UDP "session" timeout', so that when a UDP
packet is matched against a conversation, it needs to be within that
timeframe from the last seen packet to match the conversation, otherwise
it will be treated as a new conversation. The timeout value could be
made user-editable through a protocol preference.
Would that be useful?
Cheers,
Sake
