Глюк PRIM со сменой нумерации. Опции

[vkrt]

При инсталляции станции, ее абонентам была задана номерная емкость диапазона 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 влиять на эту ситуацию и какое ему до этого дело?
Ну и вечный русский вопрос. Что делать?
Спасибо.

[Dron]

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

[vkrt]

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

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

[vkrt]

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

[Dron]

Но чет мне кажется что тут все сложней. Отлуп идет еще до анализа номеров только при занятии транка и посылки префикса 73.

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

[vkrt]

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

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

[Dron]

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

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

[vkrt]

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

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

[Dron]

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

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