Извините, что повторно. Хотел поднять прежнюю тему, но не нашел (удалили?).

Есть две мини-АТС:
1) ipLDK-100 OFFICE - GS90P-3.7Ce JUL/07
2) ipLDK-300 OFFICE - GS30P-3.7Ce JUL/07
Установлены на удалении друг от друга. Подключены к локальным сетям (ЛВС), соединенных маршрутизаторами через радиосеть (канал >=2 Мбит). Радиосеть провайдера с "серыми" IP-адресами, тем не менее, дополнительно между маршрутизаторами налажена VPN (тоннель).

На мини-АТС включен IP-Networking (лицензия есть, активирована), общий номерной план, transit-out, transit-in (побежденный благодаря Harris'у), в общем "полный андульсиён". VoIP организовано платами VOIBE GS30H-2.1Cb , VOIB mode: H.323, кодек: G.723.1. Качество передаваемого голоса оценивается пользователями на "5".

Иногда (редко, не чаще 2 раз в день) в радиоканале возникают задержки (на канальном уровне), которые приводят либо к тайм-аутам в связи по IP (внутри VPN), либо к кратковременному отключению VPN. Кратковременный = не больше 5 минут, зачастую 10-20 секунд.

Сетевые сервисы типа терминальной сессии, электронной почты, сетевой печати реагируют на такие "пропадания" нормально: потормозят, конечно, чуток, но продолжают свою работу когда канал стабилизируется.
А мини-АТС не восстанавливает связь: после восстановления связи в канале необходимо перезапускать мини-АТС (если не помогла, то обе).
Иначе при звонке на местный номер (или при попытке использовать transit-out) сначала долгая тишина в трубке, потом короткие гудки.
В таком состоянии мини-АТС может находится несколько часов (пока не перезапустишь) -- сама связь не восстанавливает.

Это баг или фича (имеющейся прошивки)? Или кривые ручонки "настройщика"? (т.е. меня)

В прошлой теме гуру предлагали мне сделать трейс или протокол работы мини-АТС в такой ситуации.
Я уже и на это согласен, если эти действия помогут определить причину сбоя.

Конечно, если это "фича" такая, то остается смириться и придумывать что-нить типа автоматического перезапуска мини-АТС, в случае поступления сигнала от диагностической утилиты (которая следит за состоянием канала и оповещает администратора в случае проблем).

У меня три ldk-300, без нетвокинга. Платы не помню -- 2004 год еще. Прошивка 2.2Fi -- на днях буду апгрейдить.

До тех пор, пока в отдельный VLAN в сетке не вынес сетевухи (в каждом здании), VOIB регулярно подвисали твоим же макаром. Их какой-то траффик основной сетки "убивает", я думаю.

Cейчас для них по каналу отдельный VLAN в каждом здании, который заворачивается в свой собственный VPN (организовано по физическому каналу 2 параллельных VPN -- один для АТС с задранным QoS, и второй для данных), в котором чисто сами материнки, VOIB платы и доступ с моего компа через роутер -- на порулить.
Да собственно и АТС в разных IP-сетях, между ними по 2 роутера (пограничный в каждом здании) -- всё нормально уже несколько лет :-)
Канал падает редко, но иногда бывает. Всё восстанавливается.

До третьей АТС организован VPN через интернет вообще. Тоже всё нормально себя ведёт. Правда, качество чуть хуже при большой загрузке -- там несколько провайдеров по пути, и с QoS не всё просто.
Обрывы чаще. Но самовосстанавливается без проблем.

Моё imho -- нужно физически отделить АТСный траффик от остального. Должно помочь.

И еще -- при отсутствии связи дефолтгейтвей должен жестко говорить вызывающей АТС, что порт либо хост недоступен, а не тормозить, посылая пакеты кругами по роутерам и прочему, пока пакет по TTL не помрёт. Тут снифферы очень даже помочь могут.

Кстати, у меня перезапускать при подвисании приходилось только платы VOIB ресетом на оных.

- важный момент

При проведении изысканий вяснено что иногда подвисания происходят при звонке в "никуда" - т е на недоступный IP

Не совсем так.
Если при звонке возвращается сразу ICMP Host/Port Unreachable, то АТС просто пищит ошибкой, и не виснет.
А вот если пакет от АТС уходит, и через несколько десятков секунд возвращается ICMP TTL таймаут, то подвисание VoIB платы очень вероятно.
У меня было именно так.

Да, у нас при отключении канала тайм-ауты идут, а не сразу "узел недоступен".
----
Вот и "направление копания" обозначилось. Спасибо вам, vldmr и grey73!

P.S. Не висло бы оно в таких слачаях...

Ну так на роутере нужно роутинг при отсутствии канала прописать в Unreachable ЯВНЫМ образом.
У меня добавочная строчка с анричиблом прописана с заведомо большой метрикой. Если интерфейс падает, то это правило и начинает работать:

192.168.152.0/22 via 192.168.2.226 dev tun2
unreachable 192.168.152.0/22 scope host metric 255

то есть в моем случае если tun2 упадет, то пакеты в 192.168.152.0/22 будут возвращаться с анричиблом, а не уходить на дефолтгейтвей роутера, и там теряться

У нас роутер -- это сервер, который работает под управлением Win2003 cо службой RRAS (он и VPN-туннели делает). При кратковременном обрыве связи VPN-туннель не рвется сразу, просто тайм-ауты возвращает. Если перерыв в связи (в базовом канале) кратковременный, то после восстановления связи туннель продолжает свою работу (без переподключения заново). Конечно, когда тоннель "совсем отключается", то получаем unreachable.
RRAS так тонко не регулируется (второй вариант: у меня не хватает знаний ), и менять эту систему на "аппаратный" роутер (или *nux-based ОС) ради обхода ситуации, при которой VoIP-подсистема УАТС "завешивается", пока никто не будет. Это тупик. Пока перегружаю вручную (если УАТС близко, то перезагружаю reset'ом VOIBE, если далеко, то удаленно всю УАТС).

удаленно VOIBE ребутится через Update

В смысле, заливать прошивку для того, чтобы перезапустить только плату VOIBE?
Я ни разу еще не заменял firmware на плате VOIBE (предстоит это сделать) и не знаю сколько это по времени занимает.
Но вообще да.. прикольно. Тем более, что другого способа и нет.

да нет не так надо просто войти в настойки viob через pcadmin и ничего не меняя нажать update

Это к сожалению до сегодняшнего дня остается "фичей" АТС, сами ждем недождемся когда же наконецто выйдет новая прошивка в которой эта "фича" будет исправлена. вот кстати с RSG таких проблем нет, потеряля коннект? невопрос, на тебе реконнект, ничего не висит, прекрасно все
А вот тут остается только ждать
Виснет исключительно во время разговора. Если сеть пропала вне активности то ничего страшного не произойдет естесственно, но вот по непонятно каким причинам у нас в офисе всегда канал идет на Retrain именно во время разговора примерно в одно и тоже время суток, причем приходится перезапускать сразу 3 АТС (точнее делать Update платам VOIBE.)

К сожалению, мне доступен только краткий перечень новых "фич" прошивки 3.8 (типа анонса краткого). Не могу удостовериться в том, что разработчики собираются новой версией исправить эту особенность.
Существует ли уже "общедоступный" перечень исправлений версии 3.8?
(Или Вы имеете в виду новую прошивку VOIBE, а не ПО самой мини-АТС? )

P.S. Я сейчас перезапускаю 2 АТСки. В ближайшей перспективе еще 3 штуки будут подключены к IP-Net...

Честно говоря, я так и не понял, что Вы хотите от версии 3.8? Начнем с того, что этой версии вообще не существует! Есть, конечно, бета, но там в контексте Вашего обсуждения ничего нового нет. А что будет в официальной и когда, так этого пока никто не знает (ну кроме самой LG).

у меня 3 я уже за......лся вовсю полная Ж.....!!!



Что нового будет в 3.8 приблизительно понятно, думаю даже много чего интересного добавится, ждем с нетерпением новую версию прошивки. Насколько я вкурсе отчет об данной ошибке (о которой сейчас идет тема) AXEL (дай бог ему здоровья, чтобы мы делали без него) еще в ноябре по моей просьбе отправил производителям в корею.
Сейчас Март, ну думаю уже какнибудь задумался производитель об исправлении этой ошибки, раз о выпуске первой беты было известно еще в Сентябре 2007.

Не факт!

значит это будет очередное разочарование...

Я хочу, чтобы ipLDK не падала в "обморок" после кратковременных неполадок в IP-сетях.
Offtopic
Еще чего ожидаю очень: возможность указать перевод внешнего вызова на Net-номер прямо в PGM144.

Еще немножко оффтопика.
Скачал бесплатный telnet-клиент, который умеет выполнять скрипты (который можно "заавтоматизировать"): Tera Term (http://hp.vector.co.jp/authors/VA002416/teraterm.html)
На его скриптовом языке написал скрипт:



И можно такой скриптик либо по расписанию запускать, либо по событию (например, от программы мониторинга канала поступило сообщение об обрыве).

Но к сожалению таким образом перезапускается же вся мини-АТС...

делайте тоже самое через ком порт VOIB`а

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

Глюки с SIP'ом меня не пугают. Пугает то, что "может ещё вылезет" Есть ли примерный список надежных исправленний (разницы) от версии 2.0 к версии 2.1?
Чтобы это что-то не стало новым компромисом (типа, "да, вот это перестало работать, зато ж каналы не виснут!" ).
Сегодня постраюсь попробовать... Спасибо за прошивку (у меня сейчас везде на VOIBE'ах Version: GS30H-2.1Cb )

вот примерно что изменилось.
в файле.

Возврат к старой прошивке (2.0Ca), похоже, устранил проблему с зависаниями VOIBE с новейшей прошивкой (2.1Cb) во время time-out'ов в канале связи!
Натурный эксперимент показал, что при одинаковых условиях 2.1Cb виснет, а 2.0Ca -- нет.

Спасибо! Похоже, нет ничего (для меня) критичного.

Ну вот, теперь есть все основания попинать корейцев, чтобы устранили проблему версий 2.1
Придется писать кляузу....

а на 2.1 делали h323 only?

делали

Вот ответьте мне, господа! Ну почему у меня все работает??? И уж поверьте не одна стация... Вот до сих пор никто не СОИЗВОЛИЛ прислать полный снифер с "неработающей станции!!!" Почему??? Да, действительно, согласен, возможно может станция зависнуть при возврате пакетов при условии VPN или других подобных делах (каналах), но ведь это редкость!! (да то же не факт!)!!! Вот лично у меня, пока, не получилось её повесить! Если у кого-то получилось, то пришлите - рассмотрим... Я последнюю версию не оправдоваю, там действительно не совсем все в порядке, с самопроизвольной перезагрузкой платы действительно есть проблемы (блин, причины отследить так и не удалось), но, только вот лишнего говорить и писать не нужно... И чего, интерестно, LG, в этом случае, будет исправлять, если даже клиентам не всё до конца понятно??? Вот к примеру, 2.0! Посадите секретаршу следить, или посмотрите в логах EzAttendanta, все-равно перезагрузка платы идет! И чем она в этом случае лучше? Тем, что не виснет при наличии VPN??? (Я так завесить и не смог, убил, блин, свои выходные...) Спорный вопрос!!!!
Ладно, извените меня. Просто вероятно, я уже устал...

Да, только H.323.

Что такое "полный снифер"?

Необходимым условием зависания является отваливание канала во время разговорва между двумя станциями, в состоянии покоя этого не происходит.
На счет прямого подключения без VPN или потока маршрутизаторов никогда не пробовал может оно и не повиснет.
Одно могу сказать точно, жостаточно многим абонентам для связи нескольких удаленных офисов компании провайдер предлагают VPN на стороне собственно провайдера, поскольку
A) По этому каналу провайдер при условии соглашения легко предоставляет возможность пропускания тагированных приоритетом пакетов (QoS) между офисами.
Б) Далеко не все проавайдервы могут предоставить подключение типа Static а не PPPoE (к вопросу создания VPN своими средствами)
В) Это просто удобно

И вообще не вижу смысла делать подный сниффер

Это тема как показал факт что не в 3.8 поошивки станции походу а в прошивке платы, а может это связано с отработкой DUAL Protocol (SIP+H.323)



Вот скажи мне нафик тебе это нужно? Это можно было до выхода 3.8 сделать легко с помощю групп я понимаю еслибы на равне с внутренними абонентами можно было одновременно ставить и NetDSS (который кстати только 1 можно ставить), вот это тема, скорее всего эту тему никто и реализовывать не будет, хотя это реально нужно. поскольку в этом случае придется писать целый алгоритм обработки который должен работать как часы. если у тебя сняли в одном офисе(станции) трубку в другую станцию мгновенно должен прийти что заняли линию, а если не придет быстро такой сигнал? Отсюда при двух одновременно поднятых трубках на двух станциях скорее всего произойдет сбой... Можно проще поступить одного принудительно отключать при получении коллизии, а если станция отключит не того абонента? Но к вопросу подвисания линий если пройдет задержка в сети, то получится что оба абонента уже используют одну и туже линию, и скорее всего оба абонента отключатся от нее после получения сигнала коллизии (восстановления IP сети) но можно и проще сделать, сатвить при снятии трубки опрос коллизии, скажем в 0.5 сек, т.е. в течении которых связь устанавливаться не будет. (но это вопрос чисто к производителю)
Единственное, что можно реализовать это отправку входящего звонка нескольким абонентам другой станции при использовании все техже групп. Отправляешь звонок на, скажем группу кооторй у тебя нет в этой станции, но есть на другой а на другой станции у тебя уже расписано куда должен идти звонок т.е. разбиться, т.е. в этом случае у тебя уже конечная станция будет отрабатывать возможные коллизии между абонентами.

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

Сейчас (прошивка 3.7) это делается так: http://forum.ipldk.ru/index.php?s=&sho...ost&p=10782 (+ перевод net transfer mode из режима REROUTE в режим JOIN)
---
По теме: да действительно "виснет" не УАТС, а платы VOIBE. Прямо сейчас (после отката на предыдущие версии прошивки VOIBE) они не "виснут", сотрудники довольны, руководство спокойно, я гребу премии лопатой (в смысле: не наказали как обычно).

Незнаю как это с PRI работает, с Analog CO все просто: входящий вызов отправляешь вечером скажем на группу *620 в которой стоиттип групп Net VM Grp там может стоять как группа соседней станции так и один абонент, никаких проблем на 3.7Df я не испытывал.
Потом посмотри? прошивка 3.8Ah уже вышла и лежит на сайте (правда глюная она)
Ничего абсолютно нового производитель не сделал в этой области в новой прошивке, все как был так и сталось, скопировали настройку эту в PGM 144 и усёёё.



А вот меня досих пор наказывают, так как мы используем как H.323 так и SIP (SIPNET.RU ибо спрашивается нафик плпта за $2100+$350 IPN) одновременно, соответсвенно 2.0 мне прошивка никак не катит.

Что именно "глючное"???

Блин, действительно, а в чем глючность? У меня достаточно давно установлена, только вот "глючность" я вероятно не заметил...

Как именно моделировали зависания во время разговора? Физически рубили канал, или как? Блин, хороший у Вас провайдер (это я насчет QoS). Не провайдер, а мечта! Нам бы такого...
По поводу снифера, так у меня просто нет слов... Станция всё-таки не утюг...

С PRI то всё работает "из коробки" еще и на 2.2Fi у меня.

А вот вышеуказанное для CO'шек -- точно проверено, и на 3.7Df работает?
Или имелось в виду 3.6Df ?
6 или 7 ?? :-)

У меня на 3.6Df такое не получилось.
Верней, эффект такой:
Звонок второй станцией принимается, но поднимаешь трубку -- тишина. В это время звонящий продолжает слышать посылки вызова. Кладешь трубку на вызываемом -- он снова начинает звонить. Ну и т.д.

У Вас точно всё отвечается и звук есть в обе стороны?

У себя проверил на 3.6Са точно не работает также, как и описал grey73.

Как сказал harris (по телефону :-) , "Net VM Grp" сделано типа для других целей -- внешняя голосовая почта или что-то типа того, точно не уверен.
Но ведь принцип то ТОТ ЖЕ САМЫЙ!
И звонок как-бы проходит!
Пусть доделают, что ли
Ау, Игорь! Напиши корейцам!
Или в 3.8 оно уже как-то реализовано, и более по-нормальному?

Просто жду вот MPBN на апгрейд -- заработает или нет? и какой механизм?

Да, принцип тот же самый. Но кто именно это заказывал (страна-заказчик), для каких целей, какие были доп. требования - неизвестно. Посему неизвестны и детали, как это реализовано.
ИМХО, возможно проблема в лицензиях (Net Enable) + Join/Reroute...

В версии 3.8 сделано уже по нашему запросу: в ПГМ 144 добавлена возможность назначить вызов на Net Number (номер, прописанный в ПГМ324. А уж за этим номером может стоять как конкретный абонент другой станции, так и Hunt-группа). При этом вызов должен быть назначен только на Net Number и более никуда.
При этом станция не замыкает шлейф СО линии, пока нет ответа от сетевого абонента.

Перестал работать Mobile Extention через SIP:
сейчас работает так на релизе 3.8:
Станция B --> H.323 --> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention
это очень важная фукция, как правда потом выяснилось что ее не заявили официально в 3.8.

Должно быть так:
Станция B <--> H.323 <--> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention

На одной версии точно работало (не совсеми провайдерами SIP) например с Zebra Telecom эта функция отрабатывала наура, даже говорить было отлично (может из-за кодека g.711 хотя я непомню использовали мы его на тот момент уже или еще нет т.е. был g.729).
А вот с sipnet.ru связь устанавливалась нормально в таком режиме
Станция B <--> H.323 <--> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention
Но абоненты друг друга уже не слышали, гдето несовместимость с кодеком выходила (G.729 использовали)

Я еще неуспел проверить работу Firewall Usage ON/OFF (болел, но на неделе постараюсь)
На счет других глюков пока не буду ничего говорить, пока не буду полностью уверен, но похоже что пока все нормально.

Моделяция шла обрывом линии DSL на бридже, соответсвенно бридж стоит за основным шлюзом который прописан в станции. Отсюда получается что станция в сети, основной шлюз тоже в сети с бриджом, станция видит основной шлюз, станция посылает пакеты, но пакеты не могут просто дойти до конечной станции поскольку из-за физического обрыва линии дальше пакеты не идут пока бридж не выйдет на связь.
Да просто ломает снифать линию, она находится в другом VLAN в котором не выделялось отдельных портов для сниферов, можно конечно и основным шлюзом снифать, да разбираться неохота, в целом и так пока поянтно что проблема в прошивке VOIBE

Я уже писал, и вроде даже в этой ветке, правда, не про VOIBE, а про VOIB.

Делаете VPN на роутер поближе к другой станции, и проблема решается.
В смысле DSL падает, VPN почти мгновенно тоже падает.
Соответственно, станция начинает получать не таймауты, а Unreacheble.
Помогает от зависов VOIB на 100%.
Как сделал VPN, так проблема больше не повторялась.

Ломает делать VPN поверх VPN

Замечательно! Молодцы!
Но по телефону было сказано, что там "не всё гладко" -- что, всё-таки есть проблемы?

И еще интересует проброс в обратную сторону -- я делал с помощью добавления в пгм324 кода выхода на PSTN.
Но при этом любой на любом телефоне независимо от COS может набрать этот самый код выхода, и получить доступ к СО. Как бы это заблокировать? И оставить только выход с внешней станции через этот код доступа?

Или в 3.8 по-другому сделано?
Или вообще в принципе есть ещё механизм, а я про него не знаю?

Фсяко!

Лучше параллельно второй сделать, чтоб АТС с основной сеткой вообще не пересекались. В VLAN их, и персональный VPN им. И этому VPN'у выставить QoS правильно -- еще и качество связи вырастет.

Ну АТС и так в одельной VLAN+QoS (писал выше), а вот VPN предоставляет провайдет (3го уронвня) поверх этого VPN не вижу смысла вешать еще один VPN специально для АТС.

Здравствуйте! Есть ли уже прошивка для VOIBE новее чем 2.1Cb?
А я бы её проверил на предмет работы на обрывающемся канале...

пока нет

...А то ж у версии 2.0Са своих "глюков" хватает.

Например, беспричинное выключение сетевого интерфейса и/или пропадание VOIBE из списка плат УАТС -- если смотреть через telnet командой bs, то в списке плат её не видно; помогает с переменным успехом или перезапуск платы, или перезапуск УАТС, или выключение питание УАТС. Пока наблюдаю это на двух УАТС, установленных в разных местах (городах), подключенных к разным типам сетевого оборудования.

сегодня на сайте выложим новую версию платы VOIBE
Проверили немного, подвисания вроде нет.
2.1Dc
а пока держите на форуме.