Як я побудував моніторинг якості голосового зв’язку в Укрпошті

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

У великій телефонній мережі недостатньо знати, що сервер працює і відповідає на ping.

Виклик може встановитися успішно, але користувач буде чути затримки, уривання голосу або тишу в одному напрямку. Також виклик може проходити лише через один сервер, хоча система показує, що всі компоненти доступні.

Тому звичайного контролю стану серверів було недостатньо. Потрібно було бачити весь шлях телефонного виклику та контролювати якість передавання голосу.

Початкова ситуація

Телефонна інфраструктура складалася з кількох компонентів:

• Cisco CUCM;
• Asterisk;
• Kamailio;
• SIP-транки операторів;
• внутрішні телефонні сервери;
• системи контактного центру;
• мережеве обладнання в різних регіонах.

Для моніторингу серверів уже використовувався Zabbix. Він перевіряв доступність вузлів, навантаження процесора, використання пам’яті, дисків і мережевих інтерфейсів.

Але Zabbix не показував повну картину телефонного виклику. Він міг повідомити, що Asterisk працює, проте не показував, чому конкретний виклик завершився помилкою або чому в розмові зник звук.

Для розв’язання цієї задачі я вирішив окремо контролювати:

1. стан телефонних серверів;
2. проходження SIP-сигналізації;
3. передавання RTP-трафіку;
4. затримку та втрати пакетів;
5. стан SIP-транків;
6. результат тестових викликів.

Моніторинг серверів через Zabbix

Першим рівнем залишився Zabbix.

На серверах контролювалися:

• стан служб Asterisk і Kamailio;
• доступність SIP-портів;
• кількість активних викликів;
• стан SIP-пірів і транків;
• навантаження процесора;
• використання оперативної пам’яті;
• вільне місце на дисках;
• мережеві помилки;
• затримка та втрата пакетів.

Для частини перевірок стандартних елементів Zabbix було недостатньо. Тому я написав Bash-скрипти, які збирали потрібні дані та повертали їх у зрозумілому для Zabbix форматі.

Наприклад, окремий скрипт перевіряв стан SIP-пірів Asterisk. Інший скрипт збирав результати мережевих перевірок до віддалених телефонних серверів.

Це дозволило бачити не тільки факт доступності сервера, а й стан конкретного телефонного напрямку.

Контроль затримки та втрат пакетів

Для голосового зв’язку важливий не лише факт підключення до мережі.

Навіть невеликі втрати UDP-пакетів можуть бути помітними під час розмови. Користувач починає чути уривання слів, металевий звук або короткі паузи.

Для перевірки мережі я використовував ping і mtr.

Результати перевірок збиралися за розкладом. Після цього Zabbix отримував:

• середню затримку;
• відсоток втрачених пакетів;
• стан маршруту до віддаленого вузла.

Для затримки та втрат були створені тригери. Якщо значення перевищувало допустимий рівень, Zabbix формував подію.

Це допомагало швидко відрізнити проблему телефонного сервера від проблеми в мережі.

Наприклад, якщо SIP-реєстрація була активною, але між вузлами з’являлися втрати пакетів, причину потрібно було шукати не в конфігурації Asterisk, а на мережевому маршруті.

Аналіз SIP-викликів у HOMER

Наступним етапом стало впровадження HOMER.

HOMER використовується для централізованого збирання та аналізу SIP-сигналізації. Він дозволяє знайти конкретний виклик і побачити всі SIP-повідомлення між серверами.

У системі можна було переглянути:

• INVITE;
• 100 Trying;
• 180 Ringing;
• 200 OK;
• ACK;
• BYE;
• CANCEL;
• коди помилок;
• адреси серверів;
• напрямок проходження виклику;
• заголовки SIP;
• SDP з параметрами медіа.

Це значно спростило діагностику.

Раніше для аналізу потрібно було підключатися до кількох серверів, запускати sngrep або tcpdump, а потім порівнювати результати вручну.

Після впровадження HOMER інформація про виклик стала доступною в одному інтерфейсі.

За ідентифікатором Call-ID можна було знайти виклик і побачити його повний маршрут.

Передавання даних до HOMER

Для передавання SIP-повідомлень використовувався протокол HEP.

Kamailio передавав у HOMER інформацію про виклики, які проходили через нього. Для Asterisk також було налаштовано передавання SIP-сигналізації.

Кожному джерелу був призначений окремий Capture ID. Це дозволило розділяти інформацію за системами та напрямками.

У HOMER були створені окремі групи та панелі для різних частин телефонної інфраструктури.

Наприклад, можна було окремо переглядати:

• внутрішню телефонію;
• операторські транки;
• контактний центр;
• тестові виклики;
• окремі групи Asterisk-серверів.

Так стало простіше працювати з великою кількістю даних.

Контроль RTP і якості голосу

SIP відповідає за встановлення та завершення виклику. Сам голос передається через RTP.

Тому успішна SIP-сесія ще не означає, що користувачі нормально чули одне одного.

Для контролю RTP використовувався RTPengine. Він обробляв медіатрафік і дозволяв отримувати статистику щодо голосового потоку.

Контролювалися такі параметри:

• кількість RTP-пакетів;
• втрачені пакети;
• jitter;
• напрямки передавання RTP;
• тривалість медіасесії;
• параметри аудіокодека;
• оцінка якості голосу.

Одним із важливих показників була оцінка MOS.

MOS дає приблизне уявлення про те, як користувач сприймає якість розмови. Чим вище значення, тим кращою має бути якість голосу.

При цьому MOS не можна розглядати окремо від інших даних. Для правильної діагностики потрібно одночасно перевіряти втрати пакетів, jitter, затримку та маршрут RTP.

Особливості збору даних

Під час налаштування з’ясувалося, що не всі компоненти однаково передають інформацію.

Наприклад, одна частина SIP-діалогу могла потрапляти в HOMER через Kamailio, а інша — через Asterisk.

Також результат залежав від того, хто завершував виклик.

Коли виклик завершував IVR або Asterisk, у HOMER зазвичай було видно повний SIP-діалог. Коли слухавку клав IP-телефон, останнє повідомлення іноді не потрапляло до точки захоплення.

Це не завжди означало, що повідомлення BYE не існувало. Воно могло пройти іншим маршрутом або не потрапити до конкретного сенсора.

Тому під час аналізу я порівнював дані з кількох джерел:

• HOMER;
• sngrep;
• журнали Asterisk;
• журнали Kamailio;
• мережевий дамп;
• інформацію з RTPengine.

Один інструмент рідко показує всю правду. Особливо в телефонії, де кожен сервер упевнений, що винен сусід.

Автоматичні тестові виклики

Для перевірки телефонного маршруту я також використовував SIPp.

SIPp дозволяє автоматично створювати SIP-виклики за заданим сценарієм.

За його допомогою можна було перевірити:

• реєстрацію SIP-користувача;
• проходження виклику через Kamailio;
• авторизацію;
• відповідь IVR;
• встановлення RTP-сесії;
• коректне завершення розмови;
• роботу системи під навантаженням.

Було створено кілька профілів тестування.

Серед них були короткі перевірочні виклики та навантажувальні тести з різною кількістю одночасних з’єднань.

Результати тестів зберігалися у звітах. У них зазначалися:

• кількість запланованих викликів;
• кількість успішних викликів;
• помилки;
• максимальна кількість одночасних сесій;
• тривалість тесту;
• підсумковий результат PASS або FAIL.

Запуск тестів був інтегрований із GitLab CI/CD. Завдяки цьому перевірку можна було запускати з інтерфейсу GitLab без ручного введення великої кількості команд.

Що вдалося отримати

Після впровадження моніторингу з’явилася можливість бачити проблему на кількох рівнях.

Zabbix показував загальний стан серверів і мережі.

HOMER показував проходження конкретного SIP-виклику.

RTPengine давав інформацію про медіатрафік.

SIPp дозволяв регулярно перевіряти роботу телефонного маршруту та проводити навантажувальні тести.

У результаті стало простіше відповідати на головні питання:

• Чи працює телефонний сервер?
• Чи доступний SIP-транк?
• Через який маршрут пройшов виклик?
• На якому етапі виникла помилка?
• Чи передавався голос в обох напрямках?
• Чи були втрати пакетів?
• Чи пов’язана проблема із сервером або мережею?
• Як система працює під навантаженням?

Висновок

Моніторинг голосового зв’язку не можна побудувати лише на перевірці процесів і портів.

Потрібно контролювати сервери, SIP-сигналізацію, RTP-трафік, мережеву якість і результат реального тестового виклику.

У цій системі кожен інструмент виконував свою задачу:

• Zabbix контролював інфраструктуру;
• HOMER зберігав і показував SIP-виклики;
• RTPengine допомагав аналізувати медіатрафік;
• SIPp виконував автоматичні та навантажувальні тести;
• GitLab CI/CD використовувався для запуску тестів і розгортання змін.

Такий підхід не усуває всі проблеми автоматично. Але він значно скорочує час пошуку причини.

Замість фрази «телефонія знову погано працює» інженер отримує конкретні дані: де виникла проблема, коли вона почалася і який компонент потрібно перевіряти.