При инсталляции станции, ее абонентам была задана номерная емкость диапазона 72xx через DID Service Attributes(145) и Flexible DID Conversion(231).
Входящие вызова по PRI и H.323 например 7200 прилетали на внутренний номер 7200 и все было замечательно и красиво.
Но из-за того что номера 72xx имеют городскую нумерацию а станция используется чисто для конференцсвязи, было решено поменять номера 72xx на 73xx.
Так и сделали. Поменяли в Flexible Station Number(105) и в Flexible DID Conversion(231) в дополнении к index 200-299
200 STA 7300 STA 7300 STA 7300 STA 7300 OFF N/A Refer CO Hold 0
дописали в index 300-399
300 STA 7300 STA 7300 STA 7300 STA 7300 OFF N/A Refer CO Hold 0
Проверили работает входящая связь и при наборе 72xx и 73xx замечательно.
На некоторое время было решено оставить так и не убирать привязку 72xx.
Но однажды было замечено что вызов по PRI на номера 73xx приходить отказывается, в тоже время на 72xx приходит прекрасно. Отлуп идет уже при наборе 73.
В тоже время по H.323 вызова и на 72xx и на 73xx приходят нормально.
Была сделана попытка рестартовать модуль PRIM, после чего все заработало нормально.
Через некоторое время все повторилось.
В Device Port Num Change(101) был нажат Seq модуля PRIM и в Device Delete / Port Num Change была нажата кнопочка SAVE.
Опять все заработало нормально.
В общем такое случается практически каждый божий день и мне уже надоело с этим бороться.
Убрать в Flexible DID Conversion(231) привязку к index 200-299 по той же причине пока не совсем правильно.
Собственно вопрос. Как может модуль PRIM влиять на эту ситуацию и какое ему до этого дело?
Ну и вечный русский вопрос. Что делать?
Спасибо.

Это все хорошо! А, собственно, о чем речь то? Какое железо, версии прошивок?
И, неплохо бы, посмотреть конфиг.

Да без проблем.
========================================
MFIM/GS95M-5.5Ed AUG/11
Boot Version-1.0Bf MAY/10
Kernel Version-5.5Dd
H/W issue-3
LIK-MFIM100.STG
MULTI FUNCTION IP GATEWAY MODULE (100 PORT)
========================================
LIK-MCIM.STG
MULTIMEDIA CONFERENCING GATEWAY MODULE
4.0Mb
========================================
LIK-VOIM8.STG V4.2B
VOIP GATEWAY MODULES (8 CHANEL)
6.0Bb
LIK-VOIM8.STG V4.2B
VOIP GATEWAY MODULES (8 CHANEL)
6.0Bb
========================================
LIK-PRIM.STG
PRI GATEWAY MODULE
6.0Be
========================================
LIK-SLTM4.STGBK
SINGLE LINE TELEPHONE GATEWAY MODULE (4 PORT)
4.0Ne
========================================
LIK-PSU.STG
POWER SUPPLY UNIT
BOM REV 1.2
PCB Issue 1.0
========================================

А куда у вас смотрит PRI?

73ХХ прилетают с АТС 5ХХХ??

А PRI у нас смотрит на станцию CS1000 от LG.
За нее я уверен.

Да я пока хочу понять что у вас, да как.
А почему нет этой станции в 324 программе? Вернее, почему там не прописали?
Это от нее 72ХХ?

Игорь. Мы с Вами уже не раз общались на тему этой станции.
На CS1000 прописаны транк ацесс коды 72 и 73. Все что начинается на эти цифры она тупо посылает в поток на Ipeks.
Набор номеров других станций в том числе и CS1000 на Ipeks почти не нужен(использовать ее по другому кроме как для конференции не удолось из-за ее глюков), но тем не менее доступ на внешние номера прописан через LCR. И он прекрасно работает.
Попытки прописать через 324 программу набор внешних номеров, всегда заканчивались тем что переставал работать доступ к конференции из вне.
А 5xxx я прописал когда тестировал связь по H.323 на транзите. Хорошего из этого ничего не получилось (с транзитом) хотя доступ с IPEKS на прописанную станцию работает.
Не обращайте на этот префикс внимание, при первом удобном случае я его потру.
Проблема с входящими вызовами на 73xx. C исходящими проблем по PRI нет.

Я не Игорь.
Ок. И 72ХХ, и 73ХХ по потоку с CS1000.
Я и не ломаю голову с исходящими... Я понял, что с входящими проблема из первого вашего поста.

Значит попутал. Извините.

Я вот сомневаюсь по поводу связки MFIM/GS95M-5.5Ed и PRIM 6.0Be. У меня такой связки нет ни у кого.
Кстати, вы пишите, что ни для чего, кроме как для конференций не смогли использовать из-за глючности. Это что, она совсем не работоспособная??

Есть еще момент. В MSN Table(202) [N] для номеров 7249 и 7349 я бы указал один индекс в 231 таблице, а не разные. Хотя и в 249, и в 349 одно и то же, конечно, но, я бы так не сделал. Ну, это мысли вслух...
И, вообще, смущает дублирование индексов 200-249 и 300-349.

Мы с harris общались по этой теме.
Станция изначально бралась для работы в режиме конференции. Это ее основное назначение.
Попытки год назад задействовать ее для транзита PRI <-> H.323 окончились неудачно, переставал работать доступ к конференции по PRI.
После обновления на версию 6 были попытки опять побороться с этим делом и кое что получалось, но глюк в этой версии с режимом конференции вынудил опять откатится на версию указанную выше.
В данный момент на станции прописано порядка 23 LIP аппаратов которые участвуют в конференции. Расширять пока ее нет необходимости. Больше 32 участников в конференцию не подключить, а номерной емкости на объектах и так хватает.

А, так проблемы с конференцией были. А я то подумал, что она у вас совсем "не умная".

В MSN Table(202) я делал эти записи в период, когда экспериментировал с транзитом и приходилось включать в DID Service Attributes(145) Use "as is".
Можно все это убрать в принципе, как и дублирование индексов.
Только как я думаю, проблемы это не решит.

Потер все в MSN Table(202) и вычистил все индексы на 2xx кроме
249 CONF ROOM 1 CONF ROOM 1 CONF ROOM 1 CONF ROOM 1 ON 1 Refer CO Hold 0
Но чет мне кажется что тут все сложней. Отлуп идет еще до анализа номеров только при занятии транка и посылки префикса 73.
Было бы логично если бы станция после набора говорила что неправильно набран номер и тд.
А тут такое.

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

Кстати, а точно LIK дает отлуп? Что в трассировках?
Вы, конечно, пишите, что после перезагрузки все начинает работать...

Рестарт платы DNIC в CS1000 проблемы не решает.
А PRIM да.
Трассировки я не снимал.
В CS1000 делал это давно, не было такой необходимости, а в Ipeks еще не приходилось.
Глюк проявится буду делать.
Всем спасибо.

Да, в общем то, не за что благодарить то. Ничем и не помогли...

Доверяй но проверяй.
Как выяснилось, при прописывании кода 73 на CS1000 на поток, ответственным товарищем были прописаны все 30 транков, в то время как на IPEKS из-за ограничений прописано только первые 20.
Судя по всему после сброса PRIM, выбор транков был последовательный начиная с первого и все работало. Ну а через некоторое время выбор падал на 10 незадействованных.
Вот такая история с грустным финалом.

Как часто бывает, причина в простом...
Почему ж грустный финал?!Все разрешилось. Причина обнаружена.

Наверно потому что это самая простая из всех проблем.
Остальные связанные с глюками ПО версии 6 станции и платы MCIM в режиме конференции так просто не решить.
Идею с транзитом скорей всего придется похоронить, так как судя по всему на IPEKS нет возможности подстановки - удаления префиксов набора на транзите и модификации АОНа(добавление префикса).
А на существующей версии ПО при транзит толком не работает.