При транзите с R2MF в EuroISDN и R1.5 в CDR не помещается CNI.
При звонке с R2MF на локального обонента или при транзите с EuroISDN в R2MF все работает - CLID помещается в CDR и конвертится в CNI (передается дальше по R2MF).

А при звоке R2->EURO формируется ли CLID и если да, то какой?
Т.е. транслируется ли АОН c R2 в EURO?

Нет, не передается и в CDR не попадает.

Ну тогда все просто: как же он попадет в CDR, если его нет?

1) В маршрутах EURO и R2 промты ICIS и OGIS стоят YES (если они есть)?

2) При трассировке звонка R2->EURO видно ли CNI и CLI? Если нет ни того, ни другого имеет смысл убедиться в том, что при входящем звонке по R2 АОН либо не запрашивается , либо не отдается дальней стороной. Если не отдается дальним концом - то ничего не попишешь.
Если не запрашивается, то для запроса в R2 маршруте должно быть NCNI 2, CNIE YES.

ICIS и OGIS = YES в обеих роутах.
Поставил на входящем R2MFC роуте NCNI 2 и CNIE YES.
Работает только при транзите в ISDN с ACOD, но не c ESN кодом.
CNIE YES мешает работе с ESN при любом значении NCNI !
Методом тыка нашел что при NCNI 1 и CNIE NO заработало, но не все - транзит на ISDN и R1.5 по ACOD и CDP работает, а номер начинающийся с AC1 и AC2 не работает.
Также нет CNI при транзите на R1.5.

У тебя случаем не дефолтовская таблица MFC?
Выложи R2MF таблицу для входящих звонков.

Файл прилагаю.

P.S.: если при звонке из R2MFC на локальный телефон CNI отдается, то причем здесь таблица сигналов?



3-38774-ict.txt

Попробуй поставить в таблице в LVNO 1 сигнал
15 ECNI.

Не забудь промты CNIE YES и NCNI 2.
Если не пройдет - пришли мониторинг MFC обмена.

PS: В данной ситуации все зависит от того, в какой момент Меридиан запрашивает АОН (при транзите) и как на это реагирует дальняя сторона. Отчасти это определяется маршрутизацией.

Сейчас нет возможности проверить - только в понедельник.

P.S.: А, если не секрет, на чем основаны данные параметры (CNIE yes и NCNI 2) - на личным опытом или на теории?
Вероятно, мне не помешает почитать про R2... ж)

Основаны, как ты выражаешься: "...на личным опытом...":-))))))) , подкрепленным теорией.

Сменил сигнал 15 в ICT / LEVEL1 на ECNI - заработало таки с CNIE yes и NCNI 1 (с NCNI 2 тоже).
Есть пару НО - не работает HLOC и не врубаюсь в теорию...
За то все остальное вроде работает и CLID в CDR есть! Правда, это пока на тестовых роутах, на локальной петле - как будет в реальности на потоке с другой станцией...

Спасибо большое за помощь!!!

Насчет HLOC - какая версия software на Меридиане.

Насчет теории: а что не понятно?
CNIE - разрешает Меридиану запросить АОН по R2.
NCNI определяет в какой момент обмена это сделать.

Вообще, разбираться в R2 проблемах без мониторинга - гиблое дело. Ставь прибор на R2 или включай штатный Меридиановский мониторинг, делай звоночки и рассматривай разницу в обмене. Время, конечно, потратишь. Но опыт - не имеет цены.

Привет.
Посмотрел я табличку

XMIT NEXT 1
TERM 6
COMP 3
CONG 4
CCNI 5
SCAT 5
SCNI 9

Немного непонятно, зачем два раза CCNI и SCAT. Если убрать SCAT то не работает? Может не во всех каналах стоит класс сервиса CNA.
Успехов.

Release 24.25 на 81C

На счет теории:
в литературе указано: CNIE - делать запрос после приема ESN кода (перечислены TSC,DSC,AC1,AC2), NCNI - после которой цифры делать запрос (при 0 - "запрос не зависит от числа принятых цифр").
И еще - написано, что при NCNI > 0 и CNIE YES запрос будет послан при первом подходящем условии.

Так вот - при (NCNI 1 и CNIE NO) CNI проходит при транзите с ACOD.
Не проходит только при условии NCNI >= длина(ESN код).
В последнем случае (после правки R2MF) было NCNI 1 и CNIE YES - AC2 = 6 : HLOC 600 не работает, а LOC 601 - ок.

Был бы прибор... ж( Разве Meridian умеет MFC мониторить?

2Скиталец: CNA стоит на всех MFC транках

С таблицей R2MF еще надо разобраться - ее делали давно под некую задачу