Добрій день......
Существует такая проблема.....
Есть 2 АТС (обе лдк-300 )...Прошивки 3.6 Df и 3.5 Bk...
Настроена корпоративка через VOIBE с возможностью транзита...
Ver. VOIBE 2.0Ca....
Так вот , периодически, рвутся IP-каналы....Точнее не рвутся, а после разговора вдруг наступает тишина...Каналы после этого востанавливаются через 10-15 сек... Такая бяка ест-но раздражает руководство и происходит 3-5 раз в день...
Каналы мерял снифером..Канал весит 6-8 к/бит в сек...VPN с двух сторон по 2 Мбит\с..Тему о большой загрузке VPN и неккоректно настроенном шейпинге тлф. каналов со стороны циски отметаю сразу, так-как это было проверено в первую очередь....
Так вот вопросс?????
1) Может ли эта бяка происходить из-за вер. 3.5?
2) И тот проц на котором версия 3.5 имеет возраст около 3-4 лет, и соответственно ревижн 1.Хх ???
Заранее спасибо......

Бы ла такая-же проблема, пробывал различные варианты, 3,6Ah на обоих станциях, не помогло, организовал стык по PRI PRIB, проблемы ушла, кстати а факсы как работают по стыку?

2 sendi..
Вы не поверите ,но факсы гуляют замечательно...Причём что не характерно факсы занимают полосу в канале меньше чем разговор...У меня несколько таких вариантов уже давно в работе, и никаких проблем...Поэтому говорить что это глюк ЛЖ - нельзя..

Не знаю, я пробывал и платы менял 8 портовую на 12, и прошивку ставил GS30H-2.0Ca, проблема не уходила, пока не заменил стык

Вечер... А может и ночь...
Попробую выразить свои соображения по этому поводу...
Вообщем сменить прошивку MPB на одинаковую для обоих станций не мешало-бы - советую на 3.6Df - боль-мень "устаканенная". На вашей плате она станет. Также рекомендую сменить прошивку VOIBE на более свежую 2.1, которая лежит на этом же сайте (с 2.0 у меня были кое-какие проблемы). Все таки плата относительно новая и доработки хоть и не существенны, но важны.
А как быстро устанавливается сессия и что говорит трейс?
По какому протоколу работаете - SIP или H323?
В каком режиме - с гейтом или без?
Поставили в ПГМ320 галочку - работа с VPN?
Я так понимаю - кодек выбран 723! Если так, попробуйте перейти на 729.
Но это все мелочи!
Главное, чтобы ваш VPN обеспечивался QoS-ами!
Не будет выполнено это условие - будет рвать ... и никто вам не поможет.

Уважемый Alex_Q! Если не сложно поясните, какие у Вас были неприятности с версией 2.0? Поверьте, я спрашиваю без задней мысли (и без передней ). Мне просто необходимо знать. А в остальном с тем, что Вы написали, я полностью согласен.

Больших наверное там не было - не до конца ее исследовал! Но тот факт, что не состоялось корректное сопряжение с Гейткипером, заставил меня перейти на более свежую версию.
И от нее я не в восторге!
То ли перепрограммирование транзитки, то ли перепрошивка VOIBE на оконечке под 2.1Bb не дали мне возможность посылать длинные номера через транзитку. Впечатление такое, что на оконечке не корректно начал работать Digit Repeat. Хотя понимаю, что это от версии прошивки VOIBE никак не должно зависить.
Хотя ... уже н и в чем не уверен

Понял. Спасибо.

День добрый....
Признателен Вам за ответ ....
1) Я не фанат перепрошива на всё что только выпущено коррейцами, потому как возможны варианты.. Кроме-того есть реально работающие обьекты на в. 3.6 мпб и 2.0 воиба....
2) Сессия устанавливается мгновенно, в том то и дело что трейс ничего не говорит....Конект и всё тут, а голоса нет....
3) H323.....покрайней мере - пока...
4) Если Вы под гейтом имеете ввиду гейткипер - то - нет...
5) Кодеки чесно говоря я не менял.....и стоит 723.....но...не понимаю какое это имеет отношение к данной проблеме...
6) Что Вы подразумеваете под QoS, приоретизация выполняется,...проверено несколькими доступными вариантами....по крайней мере мне известными....а как проверить на проф. уровне.....чесно сказать не знаю...

Где-то стянул, уже не помню - да простят меня авторы сией заметки за невозможность на них сослаться - но лучще не скажешь 2-мя абзацами:
«Хорошее качество звука достижимо при времени ожидания и задержке пакета не более 80 мсек. С увеличением этого времени качество падает, но все еще остается в приемлемых пределах до 180 мсек. Некоторые системы пытаются преодолеть это узкое место при помощи распределения трафика по приоритетам (DiffServ, 802.1 p/q, IP ToS), но это имеет смысл только до определенной степени: от повышения приоритета пропускная способность канала не увеличивается. Требуется собственная выделенная полоса с интеллектуальным управлением, по которой будет двигаться только VoIP-трафик, разложенный по приоритету.

Если случайные задержки пакетов будут последовательно превышать 20-30 мсек или потери превысят 3%, качество звука может серьезно ухудшиться. При помощи инструментов управления полосой пропускания и QoS можно добиться оптимальной работы VoIP без дорогостоящих модернизаций пропускной способности канала.»

А вот кодек 729 как раз менее критичен к задержкам, чем 723.
Исходя из выше приведенного - вы чем гарантируете качество канала, кроме приоритетов?
И вообще - какая у вас задержка?




И ее одно забыл - в догонку:
Если у вас на обоих сторонах VOIBE и вы работаете через глобальній интернет, то переходите на SIP - уверяю, разницу вы почувствуете сразу. Наверное, это и будет для вас сиюминутное решение.

день добрый....

Ну... По поводу кодеков...могет быть, могет быть....Будем считать что Вы меня убедили что уровень и качество кодирование\декодирования голоса имеет место быть в данной проблеме....

"Требуется собственная выделенная полоса с интеллектуальным управлением, по которой будет двигаться только VoIP-трафик, разложенный по приоритету" - допустим, но есть ли возможность со стороны прова такое далать - раз.......и я не допонимаю смысла, тоесть если разговоров нет пользователи локальной сети передачи данных будут ограничены своей полосой , и траф не будет использоваться на 100%...конечно, если ВПН по 10 метров , то оно как-бы и не критично...в моём же случае из 2 М под ОБЩИЙ межофисный обмен отдано 256 К и плата стоит на 24 канала..Даже если считать, что 1 канал - это 6-7К/сек, проведя несложные арифметические действия можно с уверенностью ВЫРЕЗАТЬ 144К под голос а ещё лучше взять ещё один ВПН, отдельный...
Если учесть что пока в среднем занимается 2-3 канала, можно вырезать под голос и меньше...НО офис быстро развивается, и где уверенность что через месяц каналов будет не 40...А при всех данных манипуляциях дёргать будут меня и прова..Так не проще ли изначально строить ДИНАМИЧЕСКИЕ сети через приоритезацию....Дело как-бы и не в скорости а корее наоборот...Поймите меня правельно, обьекты на растоянии 400км, и представте сколько стоит ВПН такого уровня,,да-да именно ВПН а не через глобальные сети.....И перед тем что-бы убеждать заказчика взять канал потолще я толжен доказать свою правоту и УВЕРЕННОСТЬ что ВСЁ прекратится....Как Вы сами понемаете, уверенности у меня нет и сильно тут не поэксперементируешь...
Оптимизация трафа, одновременное и 100% использование - вот на что давилось продавая технику...


а как Вы думаете, разность версий может влиять...???
Дело в том что я пробывал залить 3.6 неа,, максимум 3.5......Сильно старый проц...Ему около 4 лет а Вы прекрасно понимаете что о МПБЕ тогда ещё не слышали.....


Заранее благодарен за ответ........

И в догонку сказанному....

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

Кроме того как я и говорил есть реально работающие обьекты, через Н323 и с виртуальным тунелем через глобальную сеть.....И небыло таких бяк...А тут реальный ВПН......Поэтому я и склоняюсь к проблеме железа ( вот только узнать какого именно и на какой стороне )

[size=2]Не буду уже говорить о рыбке...
Из изложенного выше вытекает, что вы человек бывалый как для компьютерного пользователя и все прекрасно понимаете о сути вещей и суете мирской.
Наверное когда решение принималось в выборе платформы, оно принималось не безпочвенно, а на основании каких-то достигнутых результатов, о коих вы тут и упомянули.
А почему-бы вам не обратиться напрямую к счастливым обладателям "реально работающих обьектов" за помощью в растолковании - как они достигли таких результатов!
Глядишь - и мы тут чего-нибудь поднаторили! Если будет на то добрая воля ...
И тут все без шуток. Тема то новая. Ни в каких учебниках не найдешь.

Миль пардонс!
Тут вернулся в начало темы, и понял всю глубину своих заблуждений в советах!
Вопросик то просто задавался:
"1) Может ли эта бяка происходить из-за вер. 3.5?" - Может! Все зависит от степени подготовки "цискаря" для работы с LDK.
На второй вопрос отвечу просто - на такой плате MPB, о коей речь шла - ревижн 1.хх - у меня построена транзитка, а на ней и VOIB и поток с этим справляются.
Я вас удовлетворил, "новенький"!

день добрый ....
Да.. Полностью
А почему-бы вам не обратиться напрямую к счастливым обладателям "реально работающих обьектов" за помощью в растолковании - как они достигли таких результатов! Днло в том, что это не ОНИ достигли таких результатов, а собственно я Атс настроенны идентично, но только на реально работающих атс верс. проца по 3.6.....Вот собственно почему я и упёрся в проблему железа
У меня встречный вопросс.....Alex_Q, Вы сказали что с МПБ транзиты и IP дружат, а на какой версии МПБ????? если на 3.6, как Вам удалось её туда загнать.....

Извините меня господа! Но я, что-то не верю про наличие реальных объектов чере публичный интернет! Или у них единый провайдер? Поверьте, в этом случае настройки отходят на второй план... Ну небыло такого никогда, как нет и сейчас! Через публичный инет, достойных результатов (коммерческих) нет, и не может быть при любой версии станционного ПО (даже будущего).

Мне ваш пессимизм понятен - до недавнего времени я тоже в это не верил до конца. Но практика показала, что в этом нет ничего военного - главное сократить число хопов до минимума и задержку получить не более 80-100-миллисекунд, и все у вас заколосится... Ну, при этом не забыть и оспецифических VoIP настройках.

P.S. "Очнитесь, милорд..."
На этой технологии поднялись мноие операторы мирового масштаба и при этом успешно предлагают свои услуги

Правильно, версия 3.6Df. Начинал с версии 1.хх на плате 2003 года віпуска.
Апгрейдил все версии последовательно по мере их выхода в свет... Что еще рассказать?
Может существенно, а может и нет - не доказано - работаю с первыми платами VOIB.

2 nikol:
день добрый...
Мало того что разные провайдеры, скажу больше...Разная толщина канала....Разные типы подключения ( в одном офисе АДСЛ, в другом - вообще инет подан по коаксиалу, через 2 пула по РРР )...Всё что требуется, это два внешних IP- адреса и скачаная с инета прога по настройке некоего вирт. тунеля...
Мало того отлично работают всё корейские IP-приложения ( как железные так и софтовые)..
2 Alex_Q...
Насколько я понял с ревижн тейбл МПБ и ВОИБЕ вооще несовместимы, соответственно и в.3.6 может оказаться мало...
Спасибо за участие в обсуждении проблемы....Со следующей недели начну решать исходя из вышеизложенного....О результах напишу ( если конечно интересно...)

Как обо всем этом думают другие:

"QOS: БЕРЕГА ПОКА НЕ ВИДНО
... По опыту Германии можно сказать, что ситуация в этой области оставляет желать лучшего, поскольку соответствующе биты QoS, как правило, игнорируются. Гораздо чаще оператор дает пакетам TCP более высокий приоритет, чем UDP. К сожалению, загрузка в большинстве случаев происходит по ТСР, и поэтому они могут заметно мешать параллельным телефонным разговорам по IP. На данный момент существуют два решения этой проблемы. Первое заключается в выборе провайдера, предлагающего QoS. При использовании SBC он способен обеспечит правильную сортировку пакетов, даже если входящие пакеты VoIP не маркированы битами QoS. Второе, скорее прагматическое, решение состоит в том, чтобы арендовать второй канал DSL и физически разделить голос и данные. Этот вариант функционирует очень хорошо, и при коммерческом использовании часто оправдывает себя экономически."
http://tlsgroup.ru/Doc/2005/ats/internet_t...rnet_tel08.html