RTCP as a telephony admin tool
Everyone who was involved in the organization of telephony, faced with the phrase "Bad communication!". What is a “bad connection”? On the one hand, this is a subjective parameter, on the other hand, these are quite specific figures. We will not rely on the user's subjective evaluations, because this is not “true.” Let's try to assess the quality of communication quite specific figure.
So, as it turns out, everything has been thought up for us, we just need to take the tool in our hands and adapt it to ourselves. We need Asterisk version older than 11 and the ability to program a little. Quick reference from wiki:
Starting with version 11, the asterisk via AMI sends the RTCPReceived and RTCPSent events. The most interesting for us is RTCPReceived, since it carries important information for us.
It looks like this:
Interesting fields for us:
RTCP packet walking scheme:
Of course, it is interesting to get the final quality of the channel in the form of%. There are two options for this:
R-factor and MOS. For more information take off here .
We cannot calculate them exactly, of course, but we can make our own lite-version.
The general calculation algorithm may look like this:
At the moment, "playing" with it. A program for visual assessment was written.
In addition, there are plans to calculate automatically for each call and put an additional field in the CDR, which will allow assessing not only the quality of a specific call, but also directions in general in the context of time periods.
Link to the program
It is checked for Asterisk 13 whether I will work in younger versions - I don’t know.
UPD:
In fact, everything is easier than it seems. No need to do the integration in your script or program with the database and do UPDATE. After each calculation of the R-factor, it suffices to set the channel variable through the same AMI interface:
And if in the CDR table, there is an r-factor column, it will fill with this value. It is over, it is better to put the average value for the entire call into this variable.
So, as it turns out, everything has been thought up for us, we just need to take the tool in our hands and adapt it to ourselves. We need Asterisk version older than 11 and the ability to program a little. Quick reference from wiki:
RTCP (Real-Time Transport Control Protocol) is a protocol used in conjunction with RTP. The protocol is described in RFC 3550, [1]. RTCP is based on the periodic transfer of control packets to all session participants using the same distribution mechanism as for data packets.
')
RTCP protocol is used to transmit information about the delays and losses of media packets, jitter-buffer, sound signal level. It also transmits the Call Quality Metrics and Echo Return Loss.
Starting with version 11, the asterisk via AMI sends the RTCPReceived and RTCPSent events. The most interesting for us is RTCPReceived, since it carries important information for us.
It looks like this:
Event: RTCPReceived
privilege: reporting, all
sequencenumber: 23177
file: manager.c
line: 1696
func: manager_default_msg_cb
channel: SIP / MainAsterisk-0000113f
channelstate: 6
channelstatedesc: Up
calleridnum: 79914099
calleridname: RC
connectedlinenum: unknown
connectedlinename: unknown
language: ru
context: TO_REGION
exten: 680000130
priority: 1
uniqueid: 1481711487.11714
linkedid: 1481711487.11714
to: Asterisk address: 12611
from: Peer Address: 14555
rtt: 0.0272
ssrc: 0x73f52b22
pt: 200 (sr)
reportcount: 1
sentntp: 1481712636.17532474232832
sentrtp: 9159680
sentpackets: 57246
sentoctets: 9159360
report0sourcessrc: 0x3098e4b3
report0fractionlost: 0
report0cumulativelost: 0
report0highestsequence: 7177
report0sequencenumbercycles: 1
report0iajitter: 3
report0lsr: 2726085614
report0dlsr: 0.0590
Interesting fields for us:
channel - the name of the associated channel
from - remote peep IP
rtt - “delay”, more precisely, circular delay
sentpackets - the number of sent packets
sentoctets - number of bytes sent
report0cumulativelost - the number of lost packets from the beginning of the session
RTCP packet walking scheme:
R-Factor lite
Of course, it is interesting to get the final quality of the channel in the form of%. There are two options for this:
R-factor and MOS. For more information take off here .
We cannot calculate them exactly, of course, but we can make our own lite-version.
The general calculation algorithm may look like this:
- We consider the maximum delay (RTT) on all shoulders and take it as an axiom that the problems with audibility begin at 1000 ms.
- We consider the percentage of losses (maximum) and take for an axiom that at 40 percent the quality of communication is not acceptable.
Total, the calculation of the R-factor may look like this:
R = 100- (MaxRTT / 10 + 2 * MaxLostPackets)
Rating:
80-100% - good sound quality
60-79% - satisfactory
<60% - The sound quality is terrible
Where to apply?
At the moment, "playing" with it. A program for visual assessment was written.
In addition, there are plans to calculate automatically for each call and put an additional field in the CDR, which will allow assessing not only the quality of a specific call, but also directions in general in the context of time periods.
Link to the program
It is checked for Asterisk 13 whether I will work in younger versions - I don’t know.
UPD:
How to put the calculated value in the CDR?
In fact, everything is easier than it seems. No need to do the integration in your script or program with the database and do UPDATE. After each calculation of the R-factor, it suffices to set the channel variable through the same AMI interface:
Action: Setvar
Channel: The name of the channel for which the R factor was calculated.
Variable: CDR (r-factor)
Value: The value that was calculated
And if in the CDR table, there is an r-factor column, it will fill with this value. It is over, it is better to put the average value for the entire call into this variable.
Source: https://habr.com/ru/post/317746/
All Articles