[asterisk-dev] Asterisk MoS and RTCP data [pardon the directness and language :-)]

[Matthew Jordan]

On Thu, Nov 6, 2014 at 8:30 AM, Nir Simionovich
<nir.simionovich at gmail.com> wrote:
> Hi All,
>
> So, if there is one thing I really like about PJSIP and WebRTC (specifically
> with mobile) is the ability to produce meaningful MoS scoring for calls in
> real time. Now, Asterisk doesn't have that capability, at least, not during
> the actual call - but only after.

Well, you can get real-time RTCP statistics over AMI - the events of
which in 12+ do contain the channel information (thanks to Olle and
Jaco Kroon's patches). So you can correlate quality with channels
(albeit in an external system).

> In itself, not an issue - it's good enough.
>
> If you were to look up the calculation for how to get your MoS, the
> following is the most common
> algorithm that I've found:
>
> effectiveLatency = rttMs + averageJitterMs * 2 + 10
> R = 93.2 - (effectiveLatency/40)
> R = R - (fractionLost * 2.5)
> MOS = 1 + (0.035)*R+(0.000007)*R*(R-60)*(100-R)
>
> My primary question is this: I can't find what rttMs in Asterisk terminology
> is. There is an rtt value,
> but its value is several orders of magnitude than I would expect. So, I
> thought it may be in microSec, not miliSec - but that doesn't make much
> sense either.

Where are you getting the RTT from? It *may* differ, depending on
where you read it from.

In AMI (in 12+, at least), the RTT is in seconds. The following
RTCPReceived event is taken from the log of the hep/rtcp-sender test
in the Asterisk Test Suite (and is documented on the wiki here
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_RTCPReceived):

Event: RTCPReceived
Privilege: reporting,all
Channel: PJSIP/ast2-00000000
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: 1000
CallerIDName: <unknown>
ConnectedLineNum: <unknown>
ConnectedLineName: <unknown>
AccountCode:
Context: default
Exten:
Priority: 1
Uniqueid: 1415331776.5
To: 127.0.1.1:0
From: 127.0.0.1:11007
RTT: 0.0333
SSRC: 0x39f81562
PT: 200(SR)
ReportCount: 1
SentNTP: 1415331786.17547983142912
SentRTP: 80160
SentPackets: 501
SentOctets: 80160
Report0SourceSSRC: 0x6ed0a094
Report0FractionLost: 0
Report0CumulativeLost: 0
Report0HighestSequence: 59911
Report0SequenceNumberCycles: 0
Report0IAJitter: 0
Report0LSR: 3192234347
Report0DLSR: 5.0000

The RTT is calculated as:
  current_time - received last SR time - received last delay since last SR time

This matches what RFC 3550 recommends:

{quote}
 Let SSRC_r denote the receiver issuing this receiver report.
      Source SSRC_n can compute the round-trip propagation delay to
      SSRC_r by recording the time A when this reception report block is
      received.  It calculates the total round-trip time A-LSR using the
      last SR timestamp (LSR) field, and then subtracting this field to
      leave the round-trip propagation delay as (A - LSR - DLSR).
{quote}


> So, on one hand I have a shit load of information, on the other hand, it is
> formatted in a very hard way to manage.
>
> Any idea how we can make this better? On another notion, I think that adding
> RTCP reading capabilities to the channels module in ARI may probe extremely
> useful.
>

You're in luck! That's actually possible already using the CHANNEL
function. Try:

http://localhost:8088/ari/channels/12345/variable?variable=CHANNEL(rtcp,rtt)

(There's a few variants of RTT to retrieve - you may want to play
around with a few of them)

See:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_CHANNEL

(Although I admit we *still* need to tweak the formatting of that
documentation. It's a hard one to get right.)

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org