Настройка jitter SIP на SMG1016M и не только

[AlexeyMish]

Коллеги, прошу прощения за офтопик, но я лучше спрошу тут, чем на мейл ру каком нибудь.
Вопрос следующий.
Нужны рекомендации по настройке jitter буферов на оборудовании.
До вчерашнего дня проблем не было, но после добавления еще одной транзитной (PBX2) стали жаловаться на 2-3 сек задержку голоса при некоторых вызовах.

Cхема прохождения вызова в атаче.
Правильно ли я понимаю, что при отсутствии потерь пакетов внутри сети, джиттер буферы между станциями лучше выставить равными 0. Немного изучил теорию, и так понял, что их стоит выставлять на оконечных устройствах, либо на исходящих каналах в которых могут наблюдаться потери пакетов.
Т.е. в моем случае выставляем джиттер буферы 50-250 на PBX2 в сторону PBX3, все остальные оставляем по 0?
Внутри сети все ходит под G.711 кодеку, в сторону PBX3 используется G.729.

[CPTL]

До вчерашнего дня проблем не было, но после добавления еще одной транзитной (PBX2) стали жаловаться на 2-3 сек задержку голоса при некоторых вызовах.

Исходя из схемы, такой вопрос: появились задержки речи при звонках с/на РВХ3? Если да, оправдано ли применение РВХ2 как транзитной для трафика на/от РВХ3? Возможно ли подключить к SMG РВХ2 и РВХ3 как оконечные устройства без транзита? Были ли произведены серьезные изменения в настройках маршрутизации Router2 после добавления РВХ2, ставшие причиной роста джиттера?

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

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

Т.е. в моем случае выставляем джиттер буферы 50-250 на PBX2 в сторону PBX3, все остальные оставляем по 0?
Внутри сети все ходит под G.711 кодеку, в сторону PBX3 используется G.729.

Работу этого узкого места нужно протестировать. Есть вероятность, что ресурсов платформы, на которой крутится РВХ2, не достаточно для перекодирования речи из G.711 в G.729, отсюда большие задежки. Настройте SIP-trunk PBX2-PBX3 на кодек G.711 и сделайте вызовы во время наименьшей нагрузки.
Полученные выводы помогут действовать дальше.

[AlexeyMish]

Исходя из схемы, такой вопрос: появились задержки речи при звонках с/на РВХ3? Если да, оправдано ли применение РВХ2 как транзитной для трафика на/от РВХ3? Возможно ли подключить к SMG РВХ2 и РВХ3 как оконечные устройства без транзита? Были ли произведены серьезные изменения в настройках маршрутизации Router2 после добавления РВХ2, ставшие причиной роста джиттера?

Жалобы на задержку в голосе поступают как раз от абонентов PBX3. У меня две версии появления этих задержек.
1) большое количество транзитных АТС
2) переконвертация кодеков 711/729.
Исключить PBX2 я к сожалению не могу.
Маршрутизация на все оконечные PBX была настроена изначально с использованием SMG в качестве "центрального коммутатора". PBX2 появилась только (!) для транзита трафика от PBX1 до PBX3. Ее появление связано с некорректной работой функционала hold/unhold PBX3 при работе со шлюзом SMG1016M. Проблема зафиксирована технической поддержкой и решение обозначено ориентировочно на август месяц. К сожалению, ожидать столь длительное время нет возможности, по этой причине была придумана временная схема (на картинке).

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

Оставил небольшие значения jitter для всех узлов.

Работу этого узкого места нужно протестировать. Есть вероятность, что ресурсов платформы, на которой крутится РВХ2, не достаточно для перекодирования речи из G.711 в G.729, отсюда большие задежки. Настройте SIP-trunk PBX2-PBX3 на кодек G.711 и сделайте вызовы во время наименьшей нагрузки.
Полученные выводы помогут действовать дальше.

Нагрузка на PBX2 минимальная, не думаю что упирается в ресурсы (10-20 каналов в пике). Но не исключаю вероятность того, реализация транскодирования не самая быстрая. К сожалению отправлять трафик на PBX3 по 711 кодеку не представляется возможным, эта станция за пределами зоны моей ответственности. Ответственна встречная сторона. И они готовы работать только по 729 кодеку.

Сейчас я несколько изменил схему.
1) При поступлении вызова PBX0-SMG1016M сразу проходит транскодирование в 729 кодек. И дальше по всему маршруту вызов так и идет, в 729 кодеке.
2) Заменил SIP3-SIP4, на прямой маршрут PBX1-PBX2.
Пока наблюдаю. Субъективно -- стало лучше.

Сейчас думаю, где быстрее будет проходить транскодинг 711/729, на SMG1016 с использованием плат телефонии либо на программной АТС, с использование ЦП сервера. Может быть стоит попробовать перенести транскскодинг на PBX2. (как было раньше. Возможно субъективное снижение задержки голосового трафика связано с заменой SIP3-SIP4 на прямой маршрут PBX1-PBX2, а не переносом транскодинга с PBX2 на SMG)

[CPTL]

Исключить PBX2 я к сожалению не могу.
Маршрутизация на все оконечные PBX была настроена изначально с использованием SMG в качестве "центрального коммутатора". PBX2 появилась только (!) для транзита трафика от PBX1 до PBX3. Ее появление связано с некорректной работой функционала hold/unhold PBX3 при работе со шлюзом SMG1016M.

Абонентам РВХ3 преимущественно нужен выход на РВХ1? Может канал SIP5 запустить напрямую в РВХ1?

Нагрузка на PBX2 минимальная, не думаю что упирается в ресурсы (10-20 каналов в пике).

Может быть стоит попробовать перенести транскскодинг на PBX2. (как было раньше. Возможно субъективное снижение задержки голосового трафика связано с заменой SIP3-SIP4 на прямой маршрут PBX1-PBX2, а не переносом транскодинга с PBX2 на SMG)

Для VoIP-шлюзов каждый разговор - это 2 отдельных канала, а если их к тому же нужно перекодировать, то ресурсы исчерпываются быстро. Если есть возможность производить транскодинг на выделенном сервере с ГигаГерцовым процессором, сравнить конечно не помешает.

[AlexeyMish]

Абонентам РВХ3 преимущественно нужен выход на РВХ1? Может канал SIP5 запустить напрямую в РВХ1?

Схему несколько упрощена. Разумеется, ваш вариант оптимальнее, но нам выделено только два IP адреса из адресации встречной стороны. А в качестве PBX1 используется 9 серверов телефонии. По этой причине приходится использовать дополнительный выделенный узел для транзита.

Если есть возможность производить транскодинг на выделенном сервере с ГигаГерцовым процессором, сравнить конечно не помешает.

Попробую поэкспериментировать.

[CPTL]

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

[AlexeyMish]

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

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