rtp flow

[Carter Bullard]

Hey CS Lee,
How Argus identifies traffic as RTP or RTCP is a secret ;o)

Actually, this is one of the things that makes Argus a pretty
interesting program, but I consider the RTP/RTCP classification
logic as just an example of how Argus can do upper layer
classification, so it is again an example of how to do a whole
class of actions.

Both Argus and the ra* programs work together to decide
if a flow is RTP or RTCP.

For Argus, all UDP traffic that has a very specific pattern in the next
protocol field are tagged as RTP, and every packet that comes
by is continually tested for minimal conformance to the pattern.
If a packet that is matched to an RTP flow can't meet the minimum
criteria, we toss the RTP/RTCP classification, and the stream
is reported as just UDP (or whatever encapsulation is below the
RTP/RTCP layer).   The test is basically: 1) a constant RTP version
number in the right place, 2) a constant reasonable codec value
that is always in the right place, 3) a monotonically increasing
(with some logic for out of order packets) sequence number that
is in the right place, and packet header and data size length that
seems reasonable.

We get into some issues with sequence number rollover and
sequence numbers wildly out of order, and flow restarts sometime
cause us to recategorize the flow incorrectly, but these are simple
tweaks I'll be doing in the next few weeks.

This, I think is working very well today (and has been for a number
of years).

Argus does make a mistake, here and there, reporting non RTP/RTCP
packets, as RTP.  This is unavoidable, when the number of packets
in the flow are very low (< 5).  So the ra* programs need to decide
if there is a misclassification.   The ra* support for RTP/RTCP  
identification
is in need of repair, and hopefully I'll get to it soon.  There are a
handful of protocols that will occasionally be mislabeled as RTP or
RTCP, they include DNS, AFS and some multicast LDAP transactions.
We use to have argus() correct the flows when it wrote the flow records
out, but it became clear that it proved better to report the additional
information and let the clients decide.

The challenge is aggregation, where many RTP records are
re-enforcing the assignment to RTP, but one matching records
suggests that its not.  Hard to know what to do in this situation,
so I've played with not merging or converting the errant flow
to RTP.  This is a bit of a head scratcher.

Is this helpful?

Carter



On Jan 13, 2008, at 2:19 AM, CS Lee wrote:

> Hi Carter,
>
> I have recently navigated some network flow and interesting the  
> skype traffic(encrypted) is smartly identified as rtp by argus. May  
> I know how actually argus justifies that certain udp flow is video/ 
> audio stream and decode it as rtp, I have checked out the source  
> code but there are so many conditions so I hope to hear from you in  
> more layman term.
>
> Thanks.
>
> -- 
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080113/50855767/attachment.html>