LIK-1200
MFIM/GS98M-5.5Gt MAY/12

LIP-8002E
SW Version: GS99P-10Bp

При внутреннем звонке аппарат отображает на экране последний звонок и не реагирует ни на какие кнопки. Помогает только перезагрузка. В повисшем состоянии State 16, Prev State 9. Если бы это были единичные случаи, то вопрос бы не возник, но из примерно 100 аппаратов хотя бы один повисает ежедневно. Что можно сделать?

такая проблема тоже помог откат на 5.5. ed

ОК. Тогда нужно будет написать про этот баг в Корею.
Можете описать проблему немного подробнее??
- Зависает именно в момент набора??
- При наборе только номера внутр. абонента?? Или при исход. вызове "на город" тоже зависает??
- Где и как именно Вы смотрели состояние телефона (State 16, Prev State 9)?? Есть трассировка??

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

Какую трассировку смотреть?

Пока не нужно снимать трассировку, т.к. снимать трассировку всех абонентов - это будет слишком большой объем "мусора", а какой абонент в след. раз зависнет - неизвестно.
Если корейцы запросят трассировку, то они скажут, что именно им нужно снять и каким образом.
Если сейчас есть какой-либо зависший телефон, то можно скачать его статус в более приемлемом для передачи корейцам виде:
в консольной программе Monitor (пароль jennie) набрать команду:
mon> s XXX <Enter>
и потом
mon> s XXX d <Enter>
где XXX - внутр. номер абонента.

Ок. Я сделал запрос в Корею. Будем ждать ответа. Если есть возможность, то пока не меняйте версию 5.5Gt.

Да, возможность есть - клиент хоть и придирчивый, но с пониманием относится. Тем более, что в подавляющем большинстве случаев все работает стабильно. К сожалению (или к счастью?) пока ни один аппарат не повисал. Но все на страже.

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

Уважаемый ADv!
Прошу проверить на телефонах LIP-8002E следующее:
1) Выполнить внутренний вызов между абонентами А и В, при этом абонент А говорит через трубку!! (state : 9 - это Intercom Talk)
2) Абонент В первым отбивается (первым кладет трубку, разъединяя вызов). Абонент А слышит Error Tone (state : 16 - это Error Tone)
3) После этого абонент А тоже кладет трубку. С этого момента телефон А "зависает"
Проверьте, пожалуйста, действительно в вашем случае такая процедура приводит к зависанию LIP-8002E или нет???
После этого я пришлю Вам новый софт для LIP-8002E.

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

ОК. Я Вам отправил письмо в личку.

Вчера установил на удаленном участке LIP-8002E при той же прошивке 8 штук и точно такая же картина..
Ситуацию еще усугубляет последовательное включение ПК после телефона и вынужденый выход из сетевой программы 1С..

Наконец удалось поймать ситуацию. SW Version: GS99P-10Bq. Линия находится в состоянии "[1135:Use] ". State 16. Prev State 9.

ОК. Отправим это в Корею.

Еще одна трассировка. SW Version: GS99P-10Bq. Линия находится в состоянии "[1116:Use] ". State 16. Prev State 19. Любопытно, что повисают одни и те же аппараты.

Когда можно ожидать ответ из Кореи?

И есть ли способ передернуть порт на станции? Пока я удаленно перезагружаю аппараты, входя на на них через web.

Присоединяюсь!!
У меня ситуация становится угрожающей - сотрудники собрались писать претензию!

Ответ из Кореи есть, но толку от этого мало.
Они проблему смоделировать не могут. Нужно точное описание событий, действий пользователей перед тем, как телефон зависнет. Если есть телефон, который зависает наиболее часто, то можно снять его трассировку. Если есть такой телефон, то сообщите мне.

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

Кстати, от чего питаются телефоны?? От адаптера питания или от POE?? Если от POE, то какие именно коммутаторы используются??

Стас! Не надо угрожать!!
На это ведь можно ответить просто - обращайся к поставщику!!

Только не это, шеф!!

У меня независимо:
и с питанием по сети и с адаптерами зависают..
И в этой же сетке и за шлюзом...

10 телефонов в одной сети с атс и 10 в удаленной через шлюз..

Был не точен в предыдущем посту..
Только что созвонился с сотрудниками обоих участков: в основном зависания на удаленном участке, на аппаратах которого прописан шлюз и питание которых обеспечивается по PoE

Сейчас еду туда - включу им адаптеры от эл. розетки.. посмотрим - изменится ли ситуация.. потому как на ближнем участке у всех от адаптеров запитаны..

Все телефоны питаются по PoE. Точную модель коммутаторов смогу сказать попозже. Вообще, я тоже сначала грешил именно на коммутаторы, но я ими не управляю и не могу посмотреть нагрузку по портам. Пока решили "болезненные" телефоны переключить в другие порты.

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

Можно ли опросить этих "болезненных" пользователей: что именно предшествовало зависанию?? Какой был вызов, какие действия они выполняли??

Шлите инструкцию. Пользователей обязательно опрошу. Когда наберется полный комплект информации - отпишусь.

Да - с некоторыми телефономи разница по количеству зависаний на порядок различается.. даже при подключении к одному свитчу..

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

Можно ли опросить этих "болезненных" пользователей: что именно предшествовало зависанию?? Какой был вызов, какие действия они выполняли??

Может "болезнь" зависит не от питания, а от конфигурации сети??? Зависают ли телефоны, которые находятся в одной сетке с MFIM??? Или только удаленные телефоны (в других сетках)??

Все аппараты находятся в одной сети с MFIM, физически отделенной от офисной сети. Удаленный телефон только один - мой, и он ни разу не повисал.

Коммутаторы D-Link DES-3028P.

ОК. Отправил в личку.

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

ОК. Это всегда происходит именно в момент ОТВЕТА на вызов??

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

ОК. Понятно... Значит в ближайшее время нас (точнее тебя) ожидает конфликт с ответственным лицом-Сисадмином...

Сегоня первый завис после вызова на 8002Е с атс другого участка по сетевой нумерации..
С сисадмином мы в одной связке - до сих пор у меня проблемы были по причине сетки..
Пока еще до счета 1:1 телефония:сетка далеко.. Косяков в сетке больше.. Сегодня у них вообще электричество на сервере отключилось со стороны энергетика..
Но с 8002Е первый большой косяк - такого еще не было по причине большого количества этих аппаратов в работе!!

Повисают в момент установления соединения и при входящих и при исходящих с абонентами LDK через сетевую нумерацию. На экране надпись "вызов от (или на) .." так и остается и далее в этом положении тел аппарат перестает реагировать до перезагрузки.. Голос в одну сторону (может не каждый раз - все по описанию абонентов) с 8002Е голос слышно, с LDK - нет..
Может, что то, сязанное с rtp траффиком? и соответствующими настройками..

Не очень часто, но все же повисают та и в другом участке сетки.. где ее настройки другие совсем и между станцией и аппаратами только свитч 3-го уровня..
Помнится - периодически и не редко повисала платта VOIB на LDK300 при плохом канали между станциями, но после смены прошивки перестала зависать..
Телефоны могут глючить - это одно.. но глухо зависать и причем все и в различно настроенных разных сетках - это рецидив.. т е болезнь самих телефонов на фоне не зависающих, стоящих рядом семитысячников, привязанных к той же миниАТС..

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

А есть способ удаленно "передернуть" порт на станции?

Можно попробовать через консоль Maintenance, командой reset XX, где ХХ - слот (Seq. Number).
Например:
maint> reset 17
Sends RESTART commad to device 17...

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

Хорошо - если блоки питания вопрос решают, потому как блоки питания снабжение хоть с опозданием, но приобрело..
Но я так понял, что это точно не выяснено пока..

И потом - зависание в любом случае не очень хорошо, даже и в случае падения напряжение по сети.. надо все равно вылечить..

Сегодня уточнил на том участке, где с самого начала телефоны 8002Е были подключены через адаптеры электропитания. Такие же зависания во время установления соеднинения с голосом в одну сторону там случались вначале.. Сейчас - нет. Значит, дело не в адаптерах. Сетка, конечно, влияет.. Но зависания на других моделях нет - значит, устранение зависания - возможно и при тех настройках сетки..

Блин, ну настройте уже мониторинг аппаратов!

wareshark смогу позже только включить параллельно телефону.. Участок от меня удаленный.. Там хаба нет - надо пропуск с этого участка - у нас это долго.. И работы навалом - нет даже полчаса свободных ближайшую неделю..

Сегодня 8002Е завис наглухо - даже перезагрузка его не помогала - станцию перезагружал.. Очень не хочется с версии 5.5Gt MAY/12 откатываться, а, похоже, придется..

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

Хватит ныть! И включить голову! Нет материала для анализа - не будет и решения!
З.Ы. switch`а на вас нет!:)

Аппарат недоступен по ip, но порт станции занят [1213:Use]. Посылка команды maint> reset 29 (номер посмотрел в Device Port Num Change(101), столбик Seq) не перегружает аппарат и не разблокирует порт.

У меня с lip 8002ae такая проблема, есть поток Е1 все работает хорошо, на фирме все телефоны lip 8002ae, с недавних пор один телефон стал неккоректно работать, при выходе в город, строго через раз телефон не принимает звук, то есть я не слышу ни гудка, ни человека с той стороны линии и это только на одном телефоне и только при выходе в город...

Версия PRIM?

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

да)

У Вас висит сам телефон, в этом случае, ИМХО, команда reset Seq.Num ничем помочь, ИМХО, не может.
По команде reset сбрасываются текущее соединение и устройство перводится в свободное состояние.
В вашем случае отсутствует взаимодействие между MFIM и телефоном, т.е. команда не отрабатывается.

А удалось ли получить трассировки??

Удаленные телефоны снять с зависания получилось перезагрузкой MFIM.. Я им адаптеры электропитания поставил - а они также перезагружали коннектором RJ45. Объяснил, что и разьем питания надо одновременно передергивать..

Кто-нить откатывался - до предыдущей версии - помогало?

Иван! мне на хаб для того участка неделю пропуск ждать.. Зависают 1-2 раза в день и все по разному.. Это надо на весь день Wireshark запускать.. У нас любой прибор, на который металлоискатель реагирует - надо показывать на проходной.. Хорошо - нетбук у меня в пропуске стоит..