argus / ra handling of rtp

[Carter Bullard]

Hey Jon,
Direction for RTP uses the same algorithm as all connection-less traffic, first packet
seen defines the direction, under the assumption that the initiator will be the first
sender.   We match the return flow traffic, just like we do with other connection-less
flows, so first packet is the only rule for direction.

Now, argus has a more complex interpacket arrival time and jitter metric than most
sensors.

We do a lot of CODEC specific processing for interpacket arrival times
and jitter in RTP, to account for silence suppression.   If you were to print the
" flgs " field, with your RTP traffic, column 4 of the field will indicate the presence of
silence suppression bits in the CODEC specific header.

Argus tracks 2 interpacket and jitter metrics in each direction, one when packets are
actively transmitting (not silence suppressed) and another when packets are
idlely transmitting (during silence suppression).  These are referred to as:

           sintpktact  source active interpacket arrival time (mSec)
           sintpktidl  source idle interpacket arrival time (mSec)
           sjitact     source active jitter (mSec).
           sjitidle    source idle jitter (mSec).

           dintpktact  destination active interpacket arrival time (mSec)
           dintpktidl  destination idle interpacket arrival time (mSec)
           djitact     destination active jitter (mSec).
           djitidle    destination idle jitter (mSec).

When the protocol is something like TCP, the active metrics are measured
when the TCP is transmitting in the window, and the idle metric is when
the TCP is outside the window.

When you print out the sintpkt or sjit, you are printing the statistical mean
and stddev's that result from merging the active and idle metrics together.
So it may be important to print both of these fields to see how the metrics
are defined.  For RTP, there shouldn't be any idle stats unless there is
silence suppression.

This accounting for silence suppression could be something  that differentiates
argus's jitter values vs other monitors.

But just looking at the src and dst packet counts in your printouts, the source
( 208.70.156.25 -> 172.10.0.x ) generally looks to have the higher variations in
offered rate and load, so I would expect the jitter value to be higher.

How do your other tools define the source?  I would suspect that they
don't track the two sides of the rtp as a single flow like argus does?

Carter


On Mar 28, 2013, at 12:09 PM, jdenton <jdenton at itcglobal.com> wrote:

> Hi Carter,
> 
> Hope all is well;
> 
> We are investigating traffic loading for a particular network and had a question on how argus / ra handles rtp stream direction?
> From the example below there is high jitter from the source address of 208.70.156.25 however on other Voice tools
> our engineers are seeing the high jitter reported to the address of 208.70.156.25?
> 
> Any thoughts?
> 
> Regards,
> Jon
> 
> 
> <cehchddf.png>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130328/1b221010/attachment.bin>