Не уверен в правильности термина "Линия", но да ладно.


Есть некоторое количество MG и LDK, соеденены по IP. Периодически на MG(100, 300) и LDK(Было на 60, 100, 300, 300e) зависают линии. Причем выглядит это следующим образом. На консоли АТС(Впрочем как и в терминале) линии на LDK и MG обозначены как свободные. При звонке на/с LDK односторонняя слышимость при занятии поврежденной линии. Причем от Voib интерфейса MG в сторону LDK летит большое количество UDP пакетов(Сниф). Наблюдал на MG как версии 1.7, так и 2.0, 2.1. Версии LDK 3.8, 3,9. Версии плат Voib также различны. Лечится перезагрузкой платы Voib на mg. Вообще проблема возникает редко и спонтанно, выявить систему не смог.

P.S.Тема скорее для информации, если кто столкнется, т.к. не представляю как поймать начало проблемы.

Да. На эту проблем уже были жалобы. Заявка на устранение этой проблемы уже отправлена в Корею, и разработчики уже приступили к поиску причины. Сейчас собираем допол. трассировки, которые потребовались корейцам.

Уваж-му vldmr каким-то случайным образом удалось смоделировать эту проблему на своей тестовой станции. Но как именно - осталось неясным. Он "игрался" с отключением VOIB от сетки во время текущего разговора.

Могу поучаствовать, АТС много, может "повезет". Только что попробовать сделать?

ОК. Буду иметь ваше предложение в виду. Но пока вроде не требуется. Есть станция, на которой проблемка возникает пару раз в день. Там обещали снять трассировки.

У меня такая же проблема на одной из Ipecs MG, voib линии используются только для звонков через sip, и 2-3 раза в неделю зависают, лечится перезагрузкой. Причем симптомы не всегда одинаковые: чаще всего sip не работает в обе стороны, но иногда по-другому - входящие звонки проходят, а исходящие - нет.

Причем у нас есть два ipecs MG, не связанные между собой, но практически идентичные по конфигурации сети и выходу в город. И данная проблема наблюдается только на АТС, на которой установлена дополнительно VOIB8, на другой атс используется только встроенные 4 линии MB и всё работает стабильно, тьфу-тьфу-тьфу) Отпишитесь пожалуйста есть ли сдвиги по этой проблеме.

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

Проблема с зависанием каналов устранена на версии B[2].1Bl

Замечательно!
А вы ее не выложите?

Где взять данную версию??? Если у Вас есть, вышлите на почту(в личку адрес послал)

https://dl.dropboxusercontent.com/u/78896209/xB.1Bl.zip

Дня доброго.

Поставил IPECS MG 100

iPECS-MG/GS55MxB.1Bl JUN/13 (на данный момент)
Boot Version-1.1Ab AUG/11
OS Version-1.1Ab AUG/11

Используется в качестве VOIB только:
VOIB8 -1.0 HA

Станция за NAT.

После установки (с ноля) с версией B.0 De , начали зависать IP каналы раз в сутки.
Поднял до GS55MxB.1B, станция начала стабильно работать, почти обрадовался, но - прошла неделя и те же "фаберже".
С чем может быть связано и какие тесты в момент "висяка" снять?
Станция ребутилась вчера, надо было срочно поднять связь (не было возможности экпериментировать) - думаю у меня есть еще неделя

Прошло почти 3 месяца. Есть ли решения по данной теме? Думаю всё ещё актуальна! Может не в теме, но у меня, mg300 в связке с астериском. 4 канала VOIP. Виснет это дело (слышимость только в одну сторону, как с астериск, так и наоборот) только когда включаю т38. Факс тестировал и по G711 (с астера на mg300) И снова висим. Лечится ребутом станции, до момента как факс пойдет.

Доброго времени суток Игорь.
А можно озвучить, в чем заключалась проблема с зависанием, т.е. симптомы.

Как я писал выше

В моем случае станция подключена к "городу" по SIP, проблема следующая - раз в неделю- исходящая и входящая связь прекращается. Понимаю требуемость "трейсов". Какие и когда снять?

Но, обновление прошивки на B.1Bl, было выполнено (ох не помню уже числа) в понедельник 10-11 часов утра, после этого зависание проявилось ровно через неделю - в понедельник с 10 до 11 часов утра. Перезагрузил станцию - все ОК
Для "теста" - на следующий понедельник(уже смешно - да), в 6:30 удаленно ребутнул станцию, проблема не проявилась.
Следующий понедельник - ребут 6:30 - стабильная работа.
А в следующий понедельник - не было ребута.
В 10:20 позвонил клиент - "нет связи" - удаленный ребут - и все опять хорошо.

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

Самое смешное, в напоминалке каждый "понедельник" - "ребутнуть <company name>", и того ребут еженедельный и 3 месяца работы "без нареканий" в мою сторону.

Собственно вопрос - что мониторить в случае зависа(wireshark вызова наружу естественно).

Странно, как то! Это что ж, строгая периодичность в 7 суток?

Я тут вспомнил. У меня на MG были прописаны аккаунты с SIP сервера, установленного на ноуте, для тестов. Ноут был выключен и VoIP на MG закисал периодически (периодичность я не помню, но, не чаще раза в неделю точно). Лечилось перезагрузкой. Т.е., MG пыталась регистрироваться на SIP сервере, который был недоступен и, в итоге, VoIP зависал. После удаления аккаунтов больше зависаний не было.
Может, нечто подобное?

Ну у меня 8 номеров с регистрацией на одном сервере, но разными учетками, думаешь проверить все ли они регистрируются?
Думаю еще в сдедующий раз не ребутить станцию, а во время "зависа" попросить ребутнуть роутер, затем свитч или наоборот и посмотреть результат.

С этим прояснилось, админ в первую очередь это проверил, не помогает.
Более того если станция загружается раньше чем появился инет, тоесть нет доступа до сип сервера, то станция больше не делает попыток зарегится.

У меня инет был, сервер был недоступен.

Переодичность определялась таймером
371, таймер регистрации, при увеличении до максимума ”аптайм” возрос до 2,5 недель.
Решение оказалось на поверхности.
Каждую СО линию(371 ид) привязал к своей учетке в 373.
До этого в 371 для всех 8 СО указывал диапазон(1-8 из пр 373).
Что и до сей поры считаю правильным подходом, но...неработает данный метод.
Думаю пожет кому, не утыкаться в подобные грабли.

на сайте новый софт с исправлениями по SIP в части стабильности регистрации.

Спасибо, за информацию.
Испытаю, но на следующих станциях