Качество связи: мониторинг и интерпретация данных

Введение

Используйте функцию Мониторинг качества соединения (Monitor Connection Quality) для сбора статистики по качеству аудио во время звонка и определения, какое соединение и в каком направлении передачи звука может испытывать проблемы из-за сети. Отчёт разделяет данные по вызывающему и вызываемому абонентам, что позволяет администратору проверить подключение конкретного пользователя или SIP-транка.

Включайте мониторинг до воспроизведения проблемы или запускайте его, пока проблемный вызов еще активен. Открытие старого вызова в журнале вызовов (Call Log) покажет только ту статистику, которая уже была собрана для этого звонка; функция не собирает недостающие данные задним числом.

Настройка и запуск мониторинга

Перед началом работы

• Используйте актуальную версию приложения 3CX или веб-клиент, подключенный к вашей АТС.
• Для мониторинга другого пользователя или просмотра административных отчетов войдите в систему с учетной записью, имеющей соответствующую роль и доступ к отделу (department). Используйте учетную запись Владельца системы (System Owner) или Системного администратора (System Admin) при расследовании проблем в масштабах всей системы.
• Определите проблемного пользователя, примерное время звонка, участников разговора и симптомы. Запишите, кто именно слышал проблему и затронула ли она одно или оба направления звука.

Если нужная опция отсутствует, проверьте права учетной записи и область видимости отдела. На странице Команда (Team) прокрутите до самого низа меню из трех точек пользователя, прежде чем делать вывод, что функция Мониторинг качества соединения (Monitor Connection Quality) недоступна. Вам не нужен пароль пользователя или доступ к его аппаратному телефону, чтобы включить мониторинг из вкладки Команда (Team).

Мониторинг пользователя в течение выбранного периода

Используйте этот метод при периодических проблемах, чтобы можно было исследовать вызовы, совершенные в течение определенного времени.

• В веб-клиенте откройте вкладку Команда (Team) и найдите нужного пользователя.
• Откройте меню пользователя (три точки) и выберите Мониторинг качества соединения (Monitor Connection Quality).

• Выберите 1 день, 3 дня, 5 дней или 7 дней в выпадающем списке На период (For Period).
• Попросите пользователя совершать или принимать звонки, чтобы воспроизвести проблему, и фиксируйте время каждого проблемного вызова.
• После завершения каждого тестового звонка открывайте отчет о качестве вызова, как описано ниже.

Повторите эти шаги для каждого затронутого пользователя. Мониторинг одного добавочного номера не является глобальной системной настройкой. Выберите период, который охватывает время вашего расследования, и просмотрите или отключите мониторинг в том же меню после завершения проверки.

Разрешение пользователям мониторить собственные вызовы

Пользователь может включить мониторинг для своего добавочного номера аналогичным образом. В веб-клиенте нажмите на аватар профиля в правом верхнем углу и выберите Мониторинг качества соединения (Monitor Connection Quality).

В софтфоне для Windows откройте меню аватара добавочного номера; в приложениях для Android и iOS откройте главное меню. Выберите Мониторинг качества соединения (Monitor Connection Quality).

После завершения отслеживаемого звонка пользователь может просмотреть результат в истории вызовов. Для получения подробного отчета откройте Вызовы (Calls) в веб-клиенте и выберите Показать отчет о качестве вызова (Show call quality report) для нужного звонка.

Запуск мониторинга активного вызова

Пока проблемный звонок еще активен, откройте Панель (Panel), найдите активный вызов в разделе Все вызовы (All Calls) и откройте его контекстное меню. Выберите Мониторинг качества соединения (если опция доступна для вашей учетной записи). Сохраняйте вызов активным достаточно долго, чтобы воспроизвести симптом, затем завершите его и изучите отчет.

Если мониторинг запущен в середине разговора, он охватит только отслеживаемую часть.Для повторного теста включите мониторинг для пользователя до совершения следующего звонка.

Пользователь может инициировать Мониторинг качества соединения во время активного звонка прямо из программных клиентов:

• Софтфон (Windows): Кликните правой кнопкой мыши по имени звонящего и выберите Мониторинг качества соединения.
• Мобильные приложения: Нажмите на таймер длительности текущего звонка и нажмите ОК в диалоговом окне подтверждения.

Чтение отчетов и устранение неполадок

Открытие отчета по завершенному вызову

• В качестве администратора перейдите в Консоль администратора > Отчеты > Журнал вызовов (Admin > Reports > Call Log) и найдите вызов по времени и участникам.
• Откройте меню действий для вызова и выберите Показать отчет о качестве вызова (Show call quality report). Пользователи могут открыть это же действие для своих собственных вызовов в разделе Вызовы (Calls) веб-клиента.
• Убедитесь, что вызывающий, вызываемый и указанная продолжительность соответствуют вызову, который вы исследуете.
• Прочтите сводку (Summary), затем сравните оба направления звука для каждого участника.

Неактивная кнопка отчета означает, что отчет для этой записи недоступен. Убедитесь, что вы просматриваете нужный сегмент вызова, особенно если звонок переводился или проходил через очередь.

Сначала изучите сводку (Summary)

Сводка указывает на обнаруженные сетевые проблемы и проблемного участника или направление. Статус “Проблемы не обнаружены” ("No problems detected") означает, что собранная статистика не выявила проблем. Параметр “Общая оценка” ("Overall score") отражает усредненное качество аудиопотока. Однако это не гарантирует, что на протяжении всего разговора звук был идеальным.

Оценки качества потока могут быть: Отличное (Excellent), Высокое (High), Среднее (Medium), Низкое (Low), Плохое (Poor) или Неизвестное (Unknown). Оценки Medium, Low и Poor указывают на то, что поток следует исследовать. Unknown означает, что статистика, необходимая для оценки этого потока, была недоступна; это не значит, что поток был хорошим или плохим.

Статус “Неполный” (Incomplete) в сводке означает недостаток информации для окончательного вывода. Прежде чем решать, что тестировать дальше, проверьте доступные данные об участниках и направлениях. Общая оценка может выглядеть хорошо, даже если направление без отчетов остается в статусе Unknown.

Определение проблемного направления звука

Рассматривайте направление звука относительно АТС 3CX отдельно для вызывающего и вызываемого. Вызов имеет двух участников, и у каждого участника есть путь звука к 3CX и путь звука от 3CX.

• "Audio to 3CX" под вызывающим (caller): звук идет от вызывающего к АТС. Проблемы здесь могут повлиять на то, что слышит вызываемый.
• "Audio from 3CX" под вызывающим : звук идет от АТС к вызываемому. Проблемы здесь могут повлиять на то, что слышит вызывающий.
• "Audio to 3CX" под вызываемым (callee): звук идет от вызываемого к АТС. Проблемы здесь могут повлиять на то, что слышит вызывающий.
• "Audio from 3CX" под вызываемым: звук идет от АТС к вызываемому. Проблемы здесь могут повлиять на то, что слышит вызываемый.

Участник, указанный для внешнего вызова, представляет путь между 3CX и внешней стороной вызова (провайдером). Проблема на этом отрезке — повод для проверки пути транка/провайдера; сама по себе она не указывает на сбой на устройстве удаленного абонента и не доказывает, какое именно сетевое оборудование вызвало проблему.

Описание показателей

• Score / MOS (Оценка качества): оценка качества голоса, полученная на основе сетевой статистики. Перед тем как полагаться на общую оценку (Overall score), сравните рейтинги отдельных потоков.
• Packet Loss % (Потеря пакетов в %): доля голосовых пакетов, которые, согласно отчету, были потеряны в этом направлении. Потери могут вызывать пропадание звука, прерывистую речь или «роботизированный» голос. Сравните проблемный вызов с чистым вызовом с того же устройства.
• Packet Count (Количество пакетов): количество пакетов, представленных в отчете. Интерпретируйте этот показатель вместе с длительностью мониторинга; короткий образец дает меньше доказательств, чем полноценный тест.
• Jitter, ms (Джиттер, мс): колебание времени доставки аудиопакетов. Высокие колебания могут способствовать неравномерному звучанию, когда принимающее устройство не может это компенсировать.
• RoundTripTime, ms (Круговая задержка, мс): время, необходимое трафику для прохождения пути от участника до АТС и обратно. Это измерение «туда-обратно», а не односторонняя задержка от рта до уха. Ограничения отчетности конечных устройств могут сделать этот показатель недоступным или приблизительным.
• Packet Bursts / Average (Всплески пакетов / Среднее значение): количество всплесков потерь пакетов и их средняя продолжительность, заявленные для потока. Рассматривайте их в совокупности с потерей пакетов, джиттером и симптомами пользователя, а не как самостоятельное доказательство сбоя.
• Codec, Endpoint / UserAgent and Duration (Кодек, Устройство / UserAgent и Длительность): идентифицируют аудиоформат, устройство или приложение, а также длительность собранного образца. По возможности сравнивайте вызовы с одинаковыми параметрами.
• Local Address / Global Address / Tunnel (Локальный адрес / Глобальный адрес / Туннель): идентифицируют адреса, видимые 3CX для данного участника. Локальный адрес веб-клиента может отображаться как 127.0.0.1 (это WebRTC прокси); это не адрес устройства пользователя. Также может отображаться глобальный адрес. Адрес туннеля может представлять подключение SBC или приложения. Удаляйте публичные адреса перед тем, как делиться скриншотами отчетов с посторонними.

Если отображается Режим (Mode): Прокси (Proxy) означает, что 3CX ретранслировала аудиопакеты; Транскодирование (Transcoding) означает, что 3CX обрабатывала аудио. Это описание пути прохождения звука, а не предупреждения о плохом качестве сами по себе.

Используйте рейтинги и метрики в комплексе. Средние показатели вызова могут скрыть кратковременное прерывание, а отчет не способен диагностировать неисправность микрофона, гарнитуры или динамика. Если кто-то слышал плохой звук, несмотря на хорошую сетевую статистику, продолжайте проверку конечного устройства и других частей пути вызова.

Практические примеры

В первом примере используется предоставленный тестовый отчет, в котором публичный IP-адрес заменен на пример адреса для документации. Остальные примеры используют вымышленные добавочные номера и иллюстративные значения. Эти примеры объясняют, как читать отчет; они не устанавливают жестких пороговых значений MOS.

Пример 1: Потеря пакетов в сторону вызываемого (Callee)

В тестовом звонке April May (1000) — вызывающий абонент, а Additions Support (1013) — вызываемый. Сводка определяет "Network problems from PBX to 1013 Additions Support" (Сетевые проблемы от АТС к 1013 Additions Support), а общая оценка — Poor (Плохо).

В разделе вызываемого "Audio from 3CX" оценка указана как Poor, а потеря пакетов составляет 31,58%. Остальные три направления звука имеют оценку Excellent (Отлично) с 0% потери пакетов. Это указывает на звук, идущий от АТС к вызываемому, поэтому вызываемый абонент может слышать пропуски или прерывистую речь вызывающего.

Начните с исследования пути от АТС к вызываемому. Джиттер вызываемого составляет всего 0,3 мс, а RTT — 3 мс, поэтому низкие значения задержки и джиттера не отменяют факта потери пакетов. Оба направления с пометкой "Audio to 3CX" имеют оценку Excellent; данные не указывают на проблему с загрузкой (upload) у любого из участников.

Оба устройства идентифицируются как "3CX WebRTC proxy" с локальным адресом 127.0.0.1. Используйте имена участников и направления, чтобы определить проблемное подключение. Отображаемый режим (Transcoding) лишь описывает процесс обработки звука и сам по себе не является ошибкой.

Пример 2: Вызываемый слышит прерывистую речь вызывающего

У вызывающего (201) в направлении "Audio to 3CX" указано Poor (Плохо) с потерей пакетов 6%, в то время как другие направления показывают High (Высоко) или Excellent (Отлично). Вызываемый (202) сообщает о пропаданиях звука в речи вызывающего. Начните с исследования сетевого пути вызывающего 201 до АТС: его Wi-Fi или проводное соединение, возможную перегрузку исходящего канала (uplink) и интернет-подключение. Повторите тест на проводном соединении или в другой сети и сравните показатели в этом же направлении.

Пример 3: Одно направление неизвестно

Вызывающий 201 имеет поток с оценкой Excellent, но у вызываемого 202 направление "Audio from 3CX" имеет статус Unknown (Неизвестно). Хорошая оценка одного направления не компенсирует отсутствие данных в другом. Повторите тест с мониторингом и проверьте, предоставляет ли устройство или провайдер необходимую статистику качества RTCP.

Неполные или отсутствующие данные мониторинга

• Мониторинг не был активен: включите его перед следующим звонком и воспроизведите проблему. Завершенные вызовы не подлежат измерению.
• Медиа трафик пошел в обход АТС: прямые пути аудио могут помешать 3CX собрать необходимую статистику. Если повторные тесты не дают полезного отчета, администратору следует перепроверить маршрут прохождения звука.
• Устройство не передало статистику: отсутствие отчетов RTCP может оставить статус направления Unknown. Сравните с другим поддерживаемым устройством или приложением.
• Вызов был переведен или прошел через очередь: проверьте соответствующего участника и сегмент вызова. Не стоит полагать, что один отчет описывает все этапы вызова.
• Проблема была кратковременной или произошла вне отслеживаемого периода: включите мониторинг перед следующей попыткой и точно фиксируйте время и симптомы.

Меняйте только одно условие теста за раз, например, переключитесь с Wi-Fi на проводную сеть или смените используемое конечное устройство. Сравнивайте проблемное направление до и после изменения. Если проблемы наблюдаются у нескольких пользователей одновременно, исследуйте общие сетевые ресурсы или ресурсы АТС; если затрагиваются только внешние звонки, сравните их с внутренними звонками и проверьте путь транка.

Экспорт метрик качества звука

Данные о качестве вызовов можно экспортировать через коннекторы данных (3CX Data Connectors) для создания внешних отчетов и исторического анализа. Перейдите в Консоль администратора > Интеграции > Коннекторы данных (Admin > Integrations > Data Connectors), настройте поддерживаемую базу данных назначения и включите Call Audio Metrics в список данных, выбранных для передачи. Экспорт только CDR (детализированных записей о вызовах) или системных метрик не экспортирует данные о качестве звука.

Экспортированные метрики можно использовать в таких инструментах, как Grafana или Power BI, для сравнения качества с течением времени. Обратите внимание, что для сбора статистики по вызовам функция мониторинга всё равно должна быть включена. Доступность коннекторов данных зависит от установленного обновления и типа лицензии (это отдельный функционал, не зависящий от функции мониторинга); проверьте требования к коннекторам данных, указанные в интерфейсе вашей АТС.

Дополнительная информация

•  Отчеты о вызовах
•  Подключение 3CX к локальной инсталляции PostgreSQL и Grafana
•  Настройка отчетности в Grafana
•  Отчеты и дашборды Power BI
•  Роли доступа в системе 3CX

Версия документа

Последнее обновление документа 23 октября 2026

https://www.3cx.ru/docs/monitor-connection-quality/