Господа, кто сталкивался с такой проблемой или в курсе...подскажите. Станция Neax7400 модель 100. Тракт R2 MFC с оператором. Проблема заключается в тарификации, оператор присылает счета на не существующие в системе номера, по внутренней тарификации можно сделать соответствие с какого номера был реальный звонок. Причем иногда этот номер определяется правильно иногда нет... Пробовал этот номер убивать и назначать по новой не помогает.... Далее стало еще интереснее пришли счета от другого оператора тоже R2 MFC. Тоже куча звонков с несуществующего номера, но в отличии от первого случая внутренние номера звонящих разные, нет чего то конкретного за что можно было бы уцепиться....

А это не может быть связано с кодом доступа, напр. кто-либо набирает код доступа и в тарификацию идет другой номер ?

Не может, тарификация отрабатывает четко, видимо не всегда правильно посылается АОН в сторону оператора, можно бы было сослаться что оператор не правильно его принимает, но 2 оператора не могут глючить одновременно.....

Скорее всего Вашим провайдерам безразлично какой идентификатор (ANI) Вы высылаете при исходящих соединенииях, ибо счета Вы оплачиваете как корпоративный клиент, которому назначены один-три номера в качестве ников.
Если Вам непременно хочется прояснить ситуацию, то почему бы не спросить у провайдеров прямо?
Думается они Вам все подробно объяснят.
Если заинтересуетесь то и протокольчики обмена на Ваших исходящих соединениях предоставят.

В том и дело что нет, тарификация до абонента, счета выставляются по каждому номеру, сбои же в АОНе не регулярны, одни и те же номера то определяются оператором правильно и в основном правильно, то выползает всякая ерунда.....

Т. Е. получается что время от времени, при исходящем соединении, NEC передает "не те" цифры идентификатора (ANI) которые прописаны Вами.
Напрашивается ответ: проверить каждый Station на "вшивость" (CM 1325, 1212, 1213 и сответственно CM 5005). Уверен Вы проделывали это не раз и не два.

Дело в том, что при исходящем соединении NEC формирует идентификатор в зависимости от ситуации.
Если организатором исходящего соединения является Station - то из его атрибутов.
Если исходящее соединение установилось после ручной переадресации или предустановленного "форварда на ружу", то NEC использует идентификатор либо аппарата, который непосредственно набрал внешний номер, либо того аппарата с которого вызвали аппарат с предустановленным переводом. Если на аппарат с предустановленным переводом поступил вызов с внешнего транка (т. е. Tandem Connection) то в качестве идентификатора NEC попытается подставить идентификатор транка. Первые цифры идентификатора транка будут взяты из таблицы на номер которой ссылается CM3503, это должны быть таблицы с 00 по 14 (содержимое таблиц естественно описываются в CM5005). Оставшиеся цифры идентификатора скорее всего NEC не сформирует. Хотя известны случаи когда подставлялись цифры номера транка из CM3019.

По этому часто приходят счета в которых указаны например только первые три цифры номера абонента.
Вообще явно в NEC не указывается количество цифр в высылаемом идентификаторе. Все зависит от того как заполнены таблицы CM5005 и параметры CM1212.
Процедура установления исходящего соединения следующая:
NEC выдает первую цифру нужного внешнего номера-адреса ( x ).
Вышестоящий регистр требует категорию вызывающего абонента ( 5 ).
NEC отвечае что абонент без приоритета ( 1 ).
Вышестоящий регистр снова требует категорию ( 5 ).
NEC передает первую цифру идентификатора ( y ).
Вышестоящий регистр снова требует категорию ( 5 ).
NEC передает вторую цифру идентификатора ( y ).

И так далее пока не кончатся цифры в идентификаторе. Тогда в ответ на очередное требование передать категорию ( 5 ) NEC выставляет ( 15 ), т. е. конец процесса идентификации.
Вышестоящий регистр просит следующую цифру номера-адреса ( 1 ).
NEC выдает вторую цифру номера-адреса.

И так до тех пор пока вышестоящий регистр не получит номер-адрес полностью.
Если все OK то вышестоящий регистр выставляет ( 6 ), адрес полный, оплата, переход в состяние разговора, если есть нюансы то ( 3 ), адрес полный переход к сигналам группы B.

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

Предлагаю отказаться от желания идентифицировать внутренних абонентов и осуществлять соединения с одним общим идентификатором ANI либо вообще без него

В противном случае все таки придется поставить тракты на мониторинг. Что бы разобраться.

Да конечно все настройки много раз проверялись, и то что сбои происходят не регулярно говорит что настройки все же правильны, раз один и тот же абонент определяется то правильно то нет... Что до переадресаций trunk to trank то их в системе быть не может так как они запрещены по 36 команде. Из чего следует что вроде как ему не с чего подставлять иденфикатор транка или что то другое.
Отказаться к сожалению от иденфикации абонента не возможно, всвязи со спецификой данной фирмы.
Спасибо за такой развернутый ответ.

for Ponomar
Да, Дима, теорию ты расписал подробно. Приятно читать. В FAQ конференции надо твой ответ прописать.
А по сути вопроса могу сказать следующее: я и сам с такой бедой сталкивался на процессорах версии J, причем как на сотках, так и на восьмидесятках.
И заметил, что случается такое в основном в ЧНН.
На одном из объектов проблема пропала после установки еще одной платы 4RSTB.
Еще одним решением м.б. требование к оператору не пропускать вызовы от неизвестного ANI.

Дмитрий Хлевной