Что-то последнее время абоненты стали жаловаться на некоторые надписи на телефоне (типа "Перегрузка" или "Отправить D..."). 10 лет всех устраивало, а тут завредничали... Я точно не уверен, но сдается мне, что видел я здесь (на форуме) обсуждение того, как можно изменить эти слова/символы... Вроде как есть какой-то файл с этими самыми словами (который при старте грузит телефон), который можно подредактировать...
ЗЫ Хотя, возможно, я путаю с какой-нить другой PBX-ой...
vad пишет: МАС адрес платы прописан в shelf/board/ethernet parameters?
да, конечно...
К тому же, несмотря на эти ошибки, плата (и полка) становится в работу, но, как я уже говорил, отваливается при трафике и, как выяснилось, недавно, при установке интерфейсных плат на "горячую" (опять же, не всегда, а через раз)...
Экспериментировать на живой полке мне, конечно, не позволили, но была возможность собрать дополнительную тестовую полку, что я и сделал. В результате, вот что:
1) INTIP3 загружается, но в логе загрузке есть вот такое безобразие:
Код
Downloading /DHS3bin/downbin/intip3/binintip3 from 10.65.87.113
/etc/rc.d/init.d/binipmg_download: download_binary binintip3 failed
/etc/rc.d/init.d/binipmg_download: download of binintip3 failed: file not found on server or bad transfer or file corrupted
/etc/rc.d/init.d/binipmg_download: sleeping 5s then retrying...
Downloading /DHS3bin/downbin/intip3/binintip3 from 10.65.87.113
/etc/rc.d/init.d/binipmg_download: download_binary binintip3 failed
/etc/rc.d/init.d/binipmg_download: download of binintip3 failed: file not found on server or bad transfer or file corrupted
/etc/rc.d/init.d/binipmg_download: sleeping 5s then retrying...
Downloading /DHS3bin/downbin/intip3/binintip3 from 10.65.87.113
/etc/rc.d/init.d/binipmg_download: download_binary binintip3 failed
/etc/rc.d/init.d/binipmg_download: too many retries, givin
C1drvDownloadBinary
C1drvDownloadBinary 0x0
C1drvIrqRequest
idx_hist 2
idx_hist 2
C1drvIrqEnable
C1drvRemoveReset
start ok
Как мне кажется на других платах, при загрузке, я такой ошибки не видел.
2) Полка живет и не "дергается", как в первом посте. Полагаю, нужен трафик, но я его на пустой полке, конечно, организовать не смогу..
3) При установке в полку (на горячую) интерфейсной платы вываливаются те же нехорошие инциденты
Цитата
22/09/15 09:52:51 000001M|021/01/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:e1,46[Time],HostFlg:bf,7d,HstST:4,LINE:2, 22/09/15 09:52:51 000001M|021/01/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:e1,46[Time],HostFlg:0,e1,HstST:5,LINE:3,f 22/09/15 09:52:51 000001M|021/01/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:e1,46[Time],HostFlg:0,e1,HstST:5,LINE:4,e 22/09/15 09:53:15 000001M|021/01/0/254|=2:0379=Inter ACT link HS: 23,(19,1),10.65.87.11,00:80:9f:d7:68:24 22/09/15 09:53:15 000001M|021/--/-/---|=2:2043=Loss of the 21 CRYSTAL 22/09/15 09:53:15 000001M|021/01/-/---|=2:2042=Loss of a INTIPB/INTIP3B type cpl 22/09/15 09:53:15 000001M|021/03/-/---|=2:2042=Loss of a UA type cpl
... и INTIP3 рестартует...
В общем-то, вопросов у меня больше не осталось. Плату отсылаем поставщику, - благо гарантийная... Надеюсь, мои изыскания помогут ребятам разобраться с этой железкой чуть быстрее...
Тогда, конечно, замена их без снятия планки - задачка нетривиальная... Хотя - выполнимая...
Но меня еще немного сбивает тот факт, что этот свист, хоть и в разной степени, но появился одномоментно. Так бывает, что бы кучка конденсаторов одномоментно испортилась?
Здравствуйте, Накопилось с десяток побитых плат eZ32. Хотим попробовать починить хоть что-нибудь из них. Хорошие паяльники есть, "некривые" руки тоже найдутся, а вот ни каких схем, как я понимаю, найти не удастся... Поэтому надежда только на чей-нибудь удачный/неудачный опыт.
Начну с пары плат с весьма очевидными симптомами: - на всех первых портах на планках (0,4,8,12...) - сильный свист; - на всех последних портах на планках (3,7,11,15...) - все ОК; - на остальных (средних) - на некоторых свист, на некоторых легкое но очевидное подвывание (как серена), на некоторых ОК. Все порты "запели" одновременно.
Может у кого-нибудь есть опыт борьбы с подобными симптомами? Прошу помочь советом...
- переставить местами (6 и 20), убедиться что проблема переползла с платой,
- переставить местами с платой из другого ящика (не забыв поправить MAC адреса в менеджменте.
Я, конечно, думал об этом, но это немного проблематично, блин... Там уже много абонентов поселилось и чтоб хоть на 10 минут полку затормозить, - согласовывать неделю надо... А в ЗИПе INTIP3 у меня, увы, нет...
(ОХЕ R11.0) Есть новая полка (АСТ28) с двумя платами INTIP3 (поз. 6 и 20). Одна из плат (20) работает стабильно и без вопросов. А вот со второй (6) прям беда какая-то...
Прописали подключили - она заработала, но через некоторое время (от полу-часа до 3-4 часов) станция вываливает инциденты:
16/09/15 14:56:32 000001M|014/06/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:10,0[Time],HostFlg:bf,7d,HstST:5,LINE:3,0 16/09/15 14:56:32 000001M|014/06/-/---|=2:2042=Loss of a INTIPB/INTIP3B type cpl 16/09/15 14:56:32 000001S|014/06/0/254|=2:0379=Inter ACT link HS: 23,(14,6),Unused,00:80:9f:d7:68:24 16/09/15 14:56:37 000001M|014/06/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:10,0[Time],HostFlg:0,ec,HstST:5,LINE:4,ee 16/09/15 14:57:01 000001M|019/01/-/---|=3:0747=Config error or Loss of IP connection: 3,(14,6),Unused,00:80:9f:d7:68:24
после чего, плата начинает циклично перезагружаться:
16/09/15 14:58:00 000001M|014/06/-/---|=4:0740=Beginning of an INT/IP downloading @:00.80.9f.d7.68.24 (binintip3) 16/09/15 14:58:00 000001M|014/06/-/---|=5:0741=End of downloading of an INT/IP board @:00.80.9f.d7.68.24 (binintip3)
Вернуть ее в работу получается только после полной ее остановки (кнопочкой). После чего вся история повторяется...
Подскажите, пожалуйста, в чем может быть проблема? Где-то здесь (на форуме) находил упоминание инцидента 3720, - говорилось о проблеме с железом, так ли это?
error пишет: у вас на IVR sip-транк с авторизацией или нет? видел многие IVR на которых sip-транк без авторизации принципиально не работает
Да, там стояла аутентификация, но после включения Рефёра почему-то перестала работать (или я чего накрутил). Включил Рефер, выключил аутентификацию и случилось чудо...
Изначально она была сделана, как ABC-F, типа только она поддерживает REFER. Но нашел такую фразу в доке, что, если TG настроена как ISND, то трансфер происходит внутри ОХЕ, - и я подумал, что это как раз то, что мне нужно. Но пока на ISDN-TG даже до адресата дойти не могу - где то запарился...
ЗЫ Выдержка из русской доки: Магистральная группа ISDN SIP обеспечивает только прямую передачу RTP (Direct RTP). Передача и разветвление выполняются внутри системы Alcatel-Lucent OmniPCX Enterprise CS: метод REFER, метод, содержащий заголовки "Referred-by" ("Направлено") или "Replaces" ("Заменяет") или отклики 3xx не отправляются оператору.
Внимание : Если оператор применяет каноническую форму, не следует использовать магистральную группу ABC-F. Произойдет сбой при выполнении разветвлениях или передачах.
Андрей, (или может еще кто знает детально SIP) просьба помочь разобраться...
REFER отправить получилось, но соединение с его помощь пока не выходит. Т.е. пока все хуже, чем было... Вот что у меня получается (всю портянку трассы приводить не буду... )
( Абоненты А и С - это ОХЕ, абонент В - IVR)
A -> B INTITE A <- B 100 A <- B 180 A <- B 200 OK A -> B ACK (здесь отрабатывает IVR) B -> C INTITE B <- C 100 B <- C 180 B <- C 200 OK B -> C ACK A <- B REFER A -> B 407 Proxy Authentication Required
В общем, не могу врубиться, кто и где здесь не может аутентифицироваться...
