Hi Anders and Sake,
Thank you very much for your useful feedback and suggestions!
I'll look into the newer version and patch.
For tearing down a conversation, i think one way to do is from the SIP/SDP dissector. When receiving a BYE/CANCEL SIP message, the SIP dissector can search for the previously registered voice conversation, and tear it down. Your idea of a timeout is also a good way to go. I'll look deeper into this when having more time.
Thanks again!
Best regards,
Thuy Nguyen.
> 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
Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline