On Thu, Nov 6, 2014 at 8:30 AM, Nir Simionovich <nir.simionov...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev