Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Dissecting RTP: false positives

From: Sake Blok <sake@xxxxxxxxxx>
Date: Tue, 25 Nov 2008 08:57:17 +0100
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 SDP�s 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