Всем спасибо за ответы, ситуация решилась очень просто оказалось, что провайдер принимает формат unknown, если к передаваемому 10-значному номеру дописать 8-ку
Хм, попытались переделать тип сигнализации в TG на ISDN all countries, транк группа вообще не захотела подниматься... Killall sipmotor, естественно делали... Или там надо QSIG выбирать? Хотя ведь в доке четко написано для SIP TG выставлять ABCF...
Коллеги, бьемся над проблемой уже не один день. Может кто подкинет правильное решение... Ситуация следующая... Есть 2 узла АТС Omnipcx Enterprise между которыми настроен IP ABC-F. На первом узле имеем платформу Genesys подключенную по SIP, на втором имеем поток Е1. Задача, с Genesys делать исходящие звонки на городские номера через Е1 второго узла. На первом узле транковая группа Е1 второго узла прописана как Remote TG. Набор на первом узле в эту транковую группу сделан через ARS. В ARS прописан свой NPD c Calling Numbering plan ident. + NPI/TON Isdn National, Called numbering plan ident. + NPI/TON Isdn Subscriber, т.к. это требует провайдер второго узла. Проблема заключается в том, что звонок в транковую группу Е1 второго узла через SIP упорно идет с форматом Calling - Unknown, хотя called идет как и требуется в формате Subscriber. Провайдер не воспринимает формат Unknown и отбивает звонки. Хотя при этом звонки просто с аппаратов первого узла через удаленную транк-группу Е1 проходят абсолютно нормально, закрываясь нужным форматом и АОНом. Получается, что при звонках с Genesys через SIP TG, не принимается NPD прописанный в ARS. Самой SIP транк группе первого узла автоматом назначен NPD 2, в нем calling и called в формате unknown. Пробовали менять этот NPD, на другой с calling - National и called-subscriber, после этого перестают проходить исходящие звонки в SIP TG. Так же в SIP TG прописан Remote Network : 2, если посмотреть в Network routing table 2 там прописан свой Numbering Plan Descriptor Id : 11 в котором тоже calling и called в формате unknown, пытались его менять, не помогает... в чем может быть затык?
Да вот и странно, что особо критичных инцидентов, больше нет... проскакивают еще такого плана, но на сколько я понял они не значительны: 08/07/11 12:30:04 000000M|---/--/-/---|=3:2873=PH:Update seq synchro:Src=49 #(exp=2 rcv=3) waitDelay=41 s 08/07/11 12:30:11 000000M|---/--/-/---|=3:2873=PH:Update seq synchro:Src=54 #(exp=2 rcv=4) waitDelay=55 s
Динамич. роутинг отключен в netadmin, да и адресов из 172.30.0.0 нет...
Не можем пока победить проблему с кратковременным падением линков... скажите такое поведение может быть из-за некорректной работы процев (система с дублир. процессорами, перегружали, переходили с одного на другой, не помогает)? Хотя инцидентов связанных с жалобами системы на нехватку ресурсов или некорректной работе процев не наблюдаем, только по линкам. При этом пинги между узлами идут стабильно, без прерываний, потери пакетов 9 из 10000. Проверяли сетевое оборудование, тоже стабильно все, потерь маршрутов нет. Ну и в добавок к инц. о падении линков идут еще такие: 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=59 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=60 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=61 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=62 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=63 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=32 ap=0 lcn=64 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=55 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=56 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=57 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=58 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=59 08/07/11 11:45:50 000000M|---/--/-/---|=3:2813=PH: incident X25: diag=27806 apc=9 ap=0 lcn=60
Скажите в данный момент колбасятся гибридные линки... это может быть связано с неработоспособностью данной INT-IP платы, хотя помимо ее есть еще 2 нормально работающие INT-IP? Не совсем понимаю виртуальные INT-IP связаны с конкретными реальными INT-IP платами?
Пример 07/07/11 11:27:05 000000M|019/04/0/001|=2:2868=PH:IP Hybrid Link to 11 is broken (type 5 access 1 sig Main 07/07/11 11:27:06 000000M|019/04/0/001|=3:2867=PH:Hybrid Access (11 1 Main) goes down 07/07/11 11:27:06 000000M|0-11 |=2:2826=PH:Local link [0 11] is down 07/07/11 11:27:06 000000M|---/--/-/---|=3:2832=PH:Node 11 is unreachable 07/07/11 11:27:09 000000M|019/04/0/001|=3:2865=PH:PLL 0 is down on Hybrid Access (11 1 Main) 07/07/11 11:27:36 000000M|019/04/0/001|=5:2862=PH:Hybrid Access (11 1 Main) is up 07/07/11 11:27:36 000000M|019/04/0/001|=3:2866=PH:Estab Req for PLL 0 on Hybrid Access (11 1 Main) 07/07/11 11:27:36 000000M|019/04/0/001|=5:2864=PH:PLL 0 is up on Hybrid Access (11 1 Main) 07/07/11 11:27:54 000000M|0-11 |=5:2827=PH:Local link [0 11] is up 07/07/11 11:27:55 000000M|---/--/-/---|=5:2846=PH:Node 11 is reachable
Приветствую всех гуру по Алкателю! Странная ситуация произошла... плата INT-IP2 перестала видеть платы компрессоров (2хGIP4-4)... В процессе загрузки выдает : No daughter board is present 00000030-0000205F: Loader: Identity Requested (Binary 0) ERROR : Unknown daugther board pluged on intip in HPII::DaughterBoard_type - value =171
после этого загружается в IN SERVICE, но без компрессоров
на OXE-ке соответственно инциденты: 05/07/11 15:26:19 000000M|000/00/-/---|=0:4402=Compression state 8 (10-13 INFO, other ERROR); daughter board 0,DSP 0" 05/07/11 15:26:19 000000M|000/00/-/---|=3:4421= 2 GIP4_4 registered, but 0 plugged
Пытались поставить дочерние платы с другой INT-IP, все равно не видит... При этом дочерние платы 2хGIP4-4 взятые с этой INT-IP норм. работают на другой плате.
Вопрос следующий, лечится ли INT-IP2 софтово или ей уже хана на железном уровне? ТИп платы - INTIPA, при подключении консольником говорит
Configuration menu not available on INTIPA board !
Да вот, клиент собирал,собирал статистику по звонкам и возжелал такой метод борьбы, но обломится значит vad спасибо за ответ,приятно также встречать ваши каменты на unleashed
Приветствую всех Алкателеведов! Гуру, может подскажете есть ли возможность на OXE ограничить входящие вызовы на конкретную хант-группу по времени? Насколько я понял Special Services-Temporized Call Release в Транк группе распространяется только на исходящие? Ограничить надо входящие по потоку Е1. Заранее спасибо.
День добрый! Странная ситуация однако Есть OXE MG R9.0 патч 31... Клиенты хотят отправлять короткие сообщения с аппарата на аппарат, цифровики 4029. Собственно, сообщения то отправляются, но только на инглише... При этом переключение на клавиатуре на кириллицу работает, но только для набора по имени, а вот при отправке сообщений не прокатывает... набор дает делать только латиницей... в доке про языки в текст. сообщениях ничего не нашлось... в 9 релизе это вообще работает?
ясно. вобщем на данный момент оператор решил сам поделать тестовые звонки на этот номер,снять трассу, может и анализатор поставят...по результатам отпишу...
звонки делал по разному и через междугородку из Москвы и через этого же оператора, который поток дает, результат одинаковый. Кстати, вот заметил в трассе различия между переадресацией по "нет ответа" и "немедленной", в том что в первом случае, после отправки SETUP с мобильным номером и получения в ответ CALL PROCEEDING и ALERT, наша ОХЕ не отдает транзитом ALERT в стор. звонящего, и мы слышим информатор, в то время как при "немедленной" она пробрасывает ALERT звонящему и мы слушаем КПВ. Это видно из трассы в предыдущем сообщении. Поковырялся в настройках станции, отмены транзита сообщения ALERT не нашлось
To Dmitry Ryzhakov: да про эту галку, знаем, если посмотрите мое первое сообщение, но в данном случае она не работает, ибо не получаем от оператора сообщений PROGRESS.