Кожен, хто займався організацією телефонії, стикався з фразою «Поганий зв'язок!». А що таке "поганий зв" язок "? З одного боку це суб'єктивний параметр, з іншого боку це цілком конкретні цифри. Покладатися на суб'єктивні оцінки користувача ми не будемо, тому що це не «тру». Спробуємо оцінити якість зв'язку цілком конкретною цифрою.
Отже, як виявляється, за нас вже все придумали, нам лише потрібно взяти інструмент в руки і адаптувати його під себе. Нам знадобитися Asterisk версії старше 11 і вміння трохи програмувати. Коротка довідка від віки:
RTCP (англ. real-Time Transport Control Protocol - протокол управління передачею в реальному часі) - протокол, який використовується спільно з RTP. Протокол описано в RFC 3550, [1]. RTCP базується на періодичній передачі керуючих пакетів всім учасникам сесії, використовуючи той же механізм розсилки, що і для пакетів даних.
Протокол RTCP використовується для передачі інформації про затримки і втрати медіа-пакетів, джиттер-буферу, рівень звукового сигналу. Також передаються метрика якості сигналу (Call Quality Metrics) і Echo Return Loss.
Починаючи з 11 версії, астериск через AMI надсилає подію RTCPReceived і RTCPSent. Найцікавіше для нас RTCPReceived, оскільки воно несе важливу для нас інформацію.
Виглядає воно так:
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: Адреса астериска:12611
from: Адреса піру: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
Цікаві для нас поля:
channel - назва асоційованого каналу
from - IP віддаленого піру
rtt - «затримка», точніше кругова затримка
sentpackets - колічество надісланих пакунків
sentoctets - колічество байт відправлених
report0cumulativelost - кількість втрачених пакетів, з початку сесії
Схема знаходження пакунків RTCP:
R-Фактор lite
Звичайно, цікаво отримати підсумкову якість каналу у вигляді%. Для цього є два параметри:
R-фактор і MOS. Більш детально ознайомитися зніми можна тут.
Вирахувати їх точно ми, звичайно ж не можемо, але можемо зробити свою lite-вресію.
Загальний алгоритм обчислення може виглядати так:
- Вважаємо максимальну затримку (RTT) на всіх плечах і беремо за аксіому, що проблеми з чутністю починаються при 1000 мс.
- Вважаємо відсоток втрат (максимальний) і беремо за аксіому, що при 40 відсотках якість зв'язку не прийнятна.
Отже, обчислення R-фактора може виглядати так:
R=100-(MaxRTT/10+2*MaxLostPackets)
Оцінка:
80-100% - гарна якість звуку
60-79% - задовільно
< 60% - Якість звуку жахлива
Де застосувати?
На даний момент «граємося» з цим. Була написана програма для візуальної оцінки.
Крім того, є в планах обчислювати автоматично для кожного дзвінка і класти в CDR додатковим полем, що дозволить оцінити не тільки якість певного дзвінка, але і напрямків в цілому в розрізі часових періодів.
Посилання на програму
Перевірено для Asterisk 13, чи працюватиме в молодших версіях - не знаю.
UPD:
Як покласти обчислене значення у CDR?
Насправді тут все простіше, ніж здається. Не потрібно робити інтеграцію у своєму скрипті або програмі з базою даних і робити UPDATE. Достатньо після кожного обчислення R-фактора через той же AMI інтерфейс встановити канальну змінну:
Action: Setvar
Channel: Назва каналу, для якого вирахували R-фактор
Variable: CDR(r-factor)
Value: Значення, яке обчислили
І якщо в таблиці CDR, є стовпчик r-factor, воно заповнитися цим значенням. Закінчено ж, в цю змінну краще класти усереднене значення за весь дзвінок.