Delay metric for RTP

[Carter Bullard]

Hey Reynum,
Glad to see that you’re getting something out of argus.  The VoIP/RTP support
is one of those few really cool things, that gets past a lot of users.

You calculate one-way delay using multiple argi, and by bringing the records
from say two systems to a single analytic, you can calculate a deltaStartTime
and deltaLastTime for each call, if you have the end systems time synchronized,
and they generate unique argus source id’s.

Because argus can generate multiple status records for a long lived VoIP
call, there is an opportunity to calculate multiple one-way delay values for
a single call.  In our commercial argus sensor, we have sensor self synchronization
logic, so that all of the records that 2 argi generate for the same VoIP call
can be compared to generate one-way delay metrics.  Without that support,
you will be able to get at least 2 good one-way delay values per RTP session,
from the first and the last record.

If you use NTP to synchronize the clocks for your 2 argi, we recommend that
the 2 systems are synching to the same NTP server, but generally not
multiple servers.  While this may not give the most accurate sync, it does
provide the most precise sync, which is the most important thing for one-way
delay.

Practically, this means that you will want to aggregate all the records for each
call, using racluster, and then do the diffs on the start and last times for the
records that match.  You can see this in ratop.1 in simple cases.

  ratop -r traffic_phone_1.out traffic_phone_1.out

ratop.1 will display the aggregated voice calls.  You can add the scrid to the
sort list, so that all the same calls will be displayed together:

  “:P srcid saddr daddr proto sport dport”

and then display the stime and dtime values, which will give you the values
needed to calculate the two one-way delays that you can generate from
generic argus data.

ratop.1 is just an example.  to automate it, you will use racluster.1:

   racluster -r traffic_phone_1.out traffic_phone_1.out -w - | rasort -m srcid saddr daddr proto sport dport

and the output should be pairs of VoIP calls that can be compared.

A lot of people discover with this technique that their time synchronization
methods suck, so you’ll have to play with it to get good results.

Hope this is helpful !!!

Carter

> On Dec 18, 2014, at 8:02 AM, Reynum <reynum2 at free.fr> wrote:
> 
> Hello,
> 
> I begin with Argus and I have to get some information on a RTP and SIP flow.
> 
> For the moment I have two VoIP client on two distinct computers with the command
> 
> argus -P 561 -d launch on it
> 
> On a third machine I have
> 
> ra -S ip1:561 -w trafic_phone_1.out
> ra -S ip2:561 -w trafic_phone_2.out
> 
> At the moment I generate graphs with
> 
> ragraph sjit djit -M 1s -r trafic_phone_1.out -t time1:time2 -title
> "jitter1" -w jitter.png -- rtp
> 
> ragraph sloss dloss -M 1s -r trafic_phone_1.out -t time1:time2 -title
> "loss1" -w loss.png -- rtp
> 
> ragraph sploss dploss -M 1s -r trafic_phone_1.out -t time1:time2 -title
> "ploss1" -w ploss.png -- rtp
> 
> ragraph sload dload -M 1s -r trafic_phone_1.out -t time1:time2 -title
> "load1" -w load.png
> 
> For both VoIP stations.
> 
> It works but I need the delay metric and I don't find on the wiki how to get it.
> 
> Another  question : is it possible to get SIP information with ra ?
> 
> Could you help me, plz?
> Regards.
> 
> 

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