Есть какие-то средства мониторинга канала для IP-телефонии?

Question

[ChemAli]

Компания с небольшим колл-центром на 20 операторов в Ростове-на-Дону. Провайдер ip-телефонии с дата-центром в Питере. Звонки делаются с ПК посредством софтфонов. Периодически возникают необъяснимые проблемы с голосовым трафиком (остальное работает штатно). Канал — кабель 10 мбит/с вверх и вниз.


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

Answer 1

[JDima]

Канал — кабель 10 мбит/с вверх и вниз.

А теперь смотрите (в случае, если по кабелю пускается не только голос). Один из пользователей со скуки открывает habrahabr.ru. На какую-то долю секунды происходит резкий всплеск загрузки канала, он полностью забивается трафиком, HTTP пакеты выталкивают несколько RTP пакетов, наблюдается кратковременное снижение качества связи. Другой сотрудник запустил на скачку торрент? Голос уже радикально испорчен.
Диагностика? Любой нормальный софтофон показывает статистику по качеству RTP потока. Потери, jitter. Надо наблюдать за этими цифрами.

В общем, если нет возможности применить QoS в любом виде на обеих сторонах канала, либо емкость канала не превышает реально необходимую в десятки/сотни раз — выделите отдельный канал строго под голос. Тот ведет себя порядочно, ровно, без всплесков.

В идеале следует избегать запуска голоса по интернету.

Comments

[JDima]

Минимум два хабражителя — абсолютные ламеры в вопросе организации каналов до КЦ и не знают банальнейших вещей…

Рассказываю на конкретном примере. Есть L2 канал от ЦОДа (в нем вся голосовая инфраструктура и стыки с операторами) до КЦ. Выглядит как очень длинный патч-корд, промежуточные устройства провайдера невидимы. Ширина канала — 30мб/с, в среднем за 30 секунд трафика — 5мб/с, из них 2мб/с голос в 729-м кодеке. Есть продвинутая мониторилка, которая собирает с телефонов RTCP и строит графики качества связи в реальном времени.

Эксперимент №1. Никакого QoSа, просто маршрутизация. Результат — около 50% телефонов постоянно жалуются на потери пакетов и вызванное этим небольшое снижение MOS. Напомню, в среднем загрузка канала данными — где-то 3мб/с, т.е. 10% от ширины канала.

Эксперимент №2. Убогая реализация QoS — полисер в сторону КЦ, рубящий все кроме голоса до 25мб/с и таким образом резервирующий под голос полосу в 5мб/с. И — есть срабатывания полисера (убиваются пакеты, превышающие установленный порог), при этом ни один телефон не фиксирует деградации качества, все графики зеленые.

Эксперимент №3. Красивая реализация QoS. Исходящий шейпинг до 30мб/с, в нем LLQ (абсолютно приоритетная очередь) для RTP трафика. И снова идеальная доставка голосовых пакетов, никаких проблем.

Как только убираю service-policy, потери тут же снова появляются.
А это — L2 канал, через инфраструктуру одного провайдера, с отличным SLA, на сети провайдера потерь нет. Чего не скажешь про интернет, где возможно всё, и никто ничего не гарантирует.

Надеюсь, объяснил доступно. Прежде, чем искать проблему у провайдера, надо устранить ее у себя.

[ChemAli]

Спасибо что разжевали. Мы не обращали внимания на QoS, так как получили заверения провайдера интернета, что они сами дают голосовому трафику более высокий приоритет.

[JDima]

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

Заверения зафиксированы документально? DSCP RTP пакетов в процессе пересылки по интернету не бьется? (тут wireshark подскажет)
Обычно если канал — интернет, то QoSов у провайдера не будет.
Можете провести эксперимент. Как только начнутся жалобы — сразу заблокировать на шлюзе любой исходящий трафик кроме RTP и SIP (если именно он задействован).

[ChemAli]

Конечно не зафиксированы, теперь будем меньше доверять словам.

Не могли бы вы порекомендовать железку, которая могла бы помочь нам в данной ситуации? Сейчас трафиком рулит Apple Airport Extreme, лишенный QoS в каком-либо виде, но в целом справляется. Он также раздает wifi (иногда) и хотелось бы остаться с его поддержкой.

[JDima]

Исходящий канал QoSить не проблема. Проблема — с входящим.
Для начала зарубите на канале все кроме голоса и смотрите, помогло ли. Если помогло — просто берите отдельный канал на 2мб/с, через него пустить голос и SIP.

[ChemAli]

Понятно, большое вам спасибо!

Answer 2

[motl]

sipqos

Comments

[ChemAli]

Спасибо! Пробовали, не принял имена пользователей (у нас со звездочками) и требует аккаунта у другого sip-оператора, пока отложили. Попробуем подсказанное выше — поработать над QoS.

Answer 3

[Никита Павлов]

winmtr

Answer 4

[nikitac]

voipmonitor.org