Как мы тестируем качество голоса: оценка каждого звонка

Канал проходит тест на throughput с запасом, а в поддержку все равно идут жалобы: робот вместо голоса, пропавшие посреди фразы слова, одна сторона, которая ничего не слышит. Throughput усредняет 40 мс jitter и пачку из 6 потерянных пакетов, которые отдельный звонок спрятать не может. Мы проводим звонки через устройство или канал под тестом и оцениваем каждый: MOS, время установления, вызовы, которые не состоялись.

Стенд

Устройство под тестом – то, через что идет голос: SBC, транковая сторона IP-PBX, NGFW с включенным SIP ALG, CPE SD-WAN, точка доступа Wi-Fi, user plane мобильного ядра. Стенд эмулирует SIP-абонентов с обеих сторон: они регистрируются, звонят и отвечают, медиа идет по RTP в вашем наборе кодеков, с интенсивностью вызовов из вашей модели трафика. Потоки данных из application mix нашего генератора делят с голосом те же очереди.

Для WAN и радиодоступа наш собственный эмулятор WANemu встает на канал доступа и добавляет задержку, jitter и пачечные потери в каждом направлении (в бете на линках 1G и 10G). Каждый звонок оценивается на стенде: E-model из ITU-T G.107 переводит измеренные потери, jitter и задержку в R-factor и MOS каждую секунду. Оценка по эталонной записи делается под проект.

Что проверяем

• Установление вызова: время от INVITE до ответа для каждого звонка на интенсивности вашего ЧНН, медиана рядом с p95
• Неуспешные вызовы: каждый с кодом ответа SIP, чтобы 503 от перегруженного устройства и 488 от несовпадения кодеков считались отдельно
• Масштаб: сколько одновременных звонков устройство держит с медиа во всех и при скольких вызовах в секунду время установления начинает расти
• Качество медиа: MOS каждого звонка, односторонняя задержка, jitter, потери и пачки потерь по направлениям
• Jitter-буфер: jitter растет по шагам, пока буфер на приеме не начнет выбрасывать опоздавшие пакеты и оценка не упадет
• Перегрузка: канал загружен данными 3:1, QoS включен, каждый звонок против того же прогона на пустом канале
• Кодеки и DTMF: например G.711, G.729 и Opus, транскодирование на SBC, цифры in-band и событиями RFC 4733
• NAT и SIP ALG: односторонняя слышимость, SDP с переписанным неверным адресом, pinhole, которые закрываются посреди разговора

В мобильном ядре те же звонки делают эмулированные абоненты через нагруженный user plane. В SD-WAN каждый звонок оценивается посекундно через brownout. У видео свои метрики: как мы тестируем QoE видео.

Что обычно ломается

SIP ALG. Типичный проект: между IP-PBX и транком оператора стоит NGFW, ALG включен по умолчанию. Звонки соединяются, время установления в норме, а часть звонков (в том прогоне 1 из 20) идет с голосом только в одну сторону: ALG переписал SDP в первом INVITE и пропустил re-INVITE. Тест на throughput не делает звонков, поэтому этого никто не видел.

Средние числа. Мониторинг показывает 8 мс jitter на канале доступа, вполне здоровое число. В разрезе звонка jitter приходит пиками от 60 до 80 мс, когда очередь забивает задание резервного копирования. Jitter-буфер на 40 мс выбрасывает эти пакеты как опоздавшие, и звонки, которые совпали с бэкапом, на эти секунды падают по MOS с 4,2 ниже 3,5. Помогла отдельная очередь для голоса на выходе: в дизайне она была, в рабочем конфиге нет.

Интенсивность вызовов. SBC держит заявленное в даташите число одновременных звонков, когда они уже установлены. На интенсивности новых вызовов в ЧНН первой насыщается сигнализация: в типичном прогоне время установления растет примерно с 200 мс до 3 с, потом новые вызовы отваливаются с 503, хотя установленные звучат нормально. Планировать нужно по вызовам в секунду при времени установления, которое устроит пользователей.

Что в отчете

MOS по каждому звонку и каждой секунде, за каждым значением потери, jitter и задержка. Время установления распределением для каждой интенсивности вызовов. Неуспешные вызовы по кодам ответа SIP. Число звонков и интенсивность, на которых устройство остановилось или замедлилось. Набор кодеков, профиль искажений и конфигурация устройства, чтобы те же звонки повторились на следующей прошивке. Каждый MOS – оценка по E-model, и отчет так и пишет.

С чего начать

Пришлите нам модель устройства, сценарии вызовов, список кодеков и интенсивность вызовов в ЧНН. Мы ответим черновиком тест-плана: пункты проверки, схема стенда и сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.