spnet - обрывы связи

[longnet]

добрый день Всем.

имеем две станции 7400
LP-1.25 MP - 4.46d MGI16- 1.26 (прошивки и настройки идентичны, кроме плана нумерации и прочего)

станции находятся в разных подсетях, друг друга видят, ограничения по портам нет, объедены по SpNet, в ммс820 стоит использование кодека G.729a
в ммс835 стоит на все кодеки Frame Count 40 mc, далее Minimum Jitter - 40, Max jitter - 200
наблюдаются бульканье и кваканье голоса через 3 минуты после начала разговора.
далее для звонков через оператора IP телефонии используется 711 кодек (стоит первый в очереди), при разговоре по IP телефонии через оператора таких обрывов связи нет. Так же пробовал в mmc820 указать 711 кодек, разницы никакой.
изменение параметров джитера с 20 до 40 эффекта не принесло.
так же иногда, в процентах 10 звонков, при звонке (входящий и исходящий) на ITP телефон наблюдается односторонняя слышимость абонента, не слышно того у кого телефон, телефон и станция находится в одной сети, в соседних портах свича, данная проблема исчезает сама секунд через 5 после начала разговора.

[LionB]

Наверняка канал используется не только под голос, но и под данные, вот и перебиваются гоолосовые пакеты другим трафиком, и тут без настройки отслеживания QoS (такой параметр имеется как на MGI, так и на ITP) на сетевых коммутаторах и роутерах не обойтись (заявы, что у нас дешевые неуправляемые свичи стоят не проходят. Если имеется VoIP, то без этого не обойтись.). У самого было точно так же сразу после установки системы, пока админы циски не крутанули. Есть целая куча программ и методик обследования статистики сетей на возможность использования VoIP, так что нужна оптимизация. Так же возможно увести весь VoIP в отдельный VLAN и для него гарантированную полосу в коммутаторах прописать, можно по MAC адрессам приоритетность VoIP трафика задать, да куча всяких решений есть, но все равно без опытного сетевого админа тут не обойтись.

[longnet]

да в канале ходят еще и данные, но мониторинг загрузки канала показывает что он занимается не более 50% ширины.
проблема в том что QoS провайдер не поддерживает, по этому поводу уже были мысли.
вообще какие оптимальные значения джитеров будут для SpNet ?
я понимаю что это дело сугубо интимное, но все же.

[LionB]

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

[longnet]

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

[LionB]

No comments.

P.S. У самого в сетке две 7400 по SPNet на 64 транка, 480 ITP аппарата, 10 SIP телефонов по регионам, 24 H323 транков. Для связи между офисами используется VPN на Cisco 38XX, 25XX, 28XX, 1841. В локальной сетке стоят Cisco 26XX, 29XX. Все работает идеально (Версии идентичны. Станции стоят с 2006 года).

[eva]

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

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

[longnet]

пока проблема в том что в том сегменте сети где находится одна из станций операторское оборудование QoS не поддерживает в принципе, пока пинаю на замену, сдвиги есть, но не скорые.
у нас такого в договоре нет к сожалению.
как вариант решил попробовать отказаться от spnet и перейти на sip, временно можно и без вкусностей посидеть

[LionB]

Оператор на неуправляемых D-Linkах. Жесть.

Ничего в плане качества речи на SIP особо не изменится..
Немного снизится трафик между узлами за счет смены сигнализации, но причина не устранится.
Все так же будет продолжать булькать. Кстати, больше чем уверен, что достаточно не на операторе QoS поднять, а на ваших VPN роутерах (или они-то оператором и админятся?) с обоих сторон. У самого оператора внутри облака полоса пропускания, как правило достаточная. Узкое место - ваш собственный канал.

[eva]

Оператор на неуправляемых D-Linkах. Жесть.

Ничего в плане качества речи на SIP особо не изменится..
Немного снизится трафик между узлами за счет смены сигнализации, но причина не устранится.
Все так же будет продолжать булькать.

)) так и будет скорее всего

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

не факт - в нашем случае как раз у оператора в облаке были проблемы - на пути следования пакетов тупо не пробивались голосовые пакеты
чтобы раздавать всем интернет особых заморочек не требуется ))
а вот над голосовыми пакетами надо думать - оператору обычно влом )

выход искать альтернативу - другого оператора и брать услугу у него ....