Да черт знает. А собственно тикеты (files for external accounting) - у вас откладываются?
Просто у вас может чего с кабелем не так, или например фильтры не указали (фильтры они для каждого раздела - внешняя, on-line  и т.п. - отдельно указываются - входящие, исходящие и т.п.).
Или кабедь плохо спаяли (я всегда путал концы прием/передача).

А не пробовали удалить лишние TM боксы (в частности с 31-го порта) раз ругается на них? (я так понимаю в shelf/board/TA чего-то прописано)

listerm для 9-й платы - на обоих процах одно и то-же показывает?

Извините что вмешиваюсь - но вы выложили вывод не сначала (вначале Alize start... ) - был глубокий смысл?

Для начала - посмотреть чего пишет в логах. Посмотреть статусы задач в шедулере.
Принудительно запустить синхронизацию ручками - опять же посмотреть чего пишет в логах и шедулере.

А я и просил ДВЕ трассировки, для сравнения. Но в данном случае - все равно имеет смысл смотреть Call manager. Для начала - если два абонента Call Manager разговаривали и один положил трубку - занято есть? Как долго?

В данном случае оставляем только с референсом 0c bc (8c bc) входящий звонок и 4c ce (cc ce) звонок в город.
Собственно прекрасно - есть трассировки, И.И.И.??? Это о чем звонок - где все хорошо или где все плохо?

По вашему первому сообщению - при звонке на занятого городского абонента пробоема. Это тот звонок?
По трассировке здесь все хорошо - из города получили:
__________________________________________________­_________­___________________
| (127656:692067) Physical-Event :
| long: 26 desti: 0 source: 0 cryst: 0 cpl: 2 us: 0 term: 1 type a5
| tei: 0 >>>> message received : DISCONNECT [45] Call ref : cc ce
|__________________________________________________­_________­___________________
|
| IE:[08] CAUSE (l=2) 8a 91 -> [91] USER BUSY
| IE:[1e] PROGRESS_ID (l=2) 82 88
|__________________________________________________­_________­___________________

Благополучно это переслали:
__________________________________________________­_________­___________________
| (127656:692068) 833: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 0 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 8c bc
|__________________________________________________­_________­___________________
|
| IE:[08] CAUSE (l=2) 81 91 -> [91] USER BUSY
| IE:[1e] PROGRESS_ID (l=2) 80 88
|__________________________________________________­_________­___________________

Правда в Progress ID цифры слегка разные (но это нормально 82 - городская сеть, 80 - user), но соединение далее заканчивается (дальнейшие сообщения с релизами).
Собственно если абонент не слышал "занято" - смотрите настройки в Call Manager.

Для начала t3 трассировку между Cisco и ОХЕ посмотреть при звонке на занятого абонента города и ОХЕ. Могут быть нюансы - например при звонке на занятого абонента ОХЕ вв получаете Disconnect. А при звонке на городского абонента - не получаете, а имеете сообщение Progress и аккустический сигнал занято в разговорном тракте (или голосовое сообщение "Абонент временно не может быть вызван"). Кто тут не проключил разговорный тракт - не известно.
Т.е. - сначала трассировки - дальше видно будет.

Чего писать французам? Вы организуйте звонок на 2990293, а ПОТОМ в DTMF все наберите. А потом если не получится - можно и написать.
Или на ОХЕ организуйте этот набор.
Ну и ествественно (просто для интереса) - почему появление H323 на ОХЕ должно привести к расширению MADA? Сколько кодеков надо  - столько и должно быть. А под что используется (SIP, H323, свои IP телефоны) - какая разница? С включенным Direct RTP - смотрим командой compvisu lio - ВСЕ кодеки в одном пуле.

А в чем-то проблемы - ввести чего-то типа (напримар) mail.intersyst.ru  - не дает?

А что такое для ОХЕ должно быть - 2990293L88557222600? В смысле как-то непривычно видеть "L".
В том виде как говорите - должен СНАЧАЛА прийти звонок на номер 2990293, ПОТОМ уже ПОСЛЕ ответа - в DTMF должно донабраться 88557222600. А у вас как-то все разом. Или у вас и раньше приходило по SIP все разом, а ОХЕ разруливала через ARS как положено?

Просто:
- при программировании новой станции - делают пустую базу, потом ставят OPS.
- при апгрейде - восстанавливают базу, ставят новые OPS.
- при восстановлении - просто восстанавливают базу.

Если смотрели - при создании пустой базы - старая (включая OPS) база удаляется.
При восстановлении - аналогично. Поэтому при восстановлении базы - предварительное создание базы и/или загрузка OPS файлов - особо положительного эффекта не дает.

этап 7 - полностью удаляет все сделанное в п. 6  
этап 8 - отменяет все сделанное в п. 6 и 7

И про работает без проблем - все работает, и нет слов про количество оставшихся дней когда заходите под mtcl?

Пользуйтесь нормальными программами менеджмента, а если работаете через mgr - и имеете такое поведение (удаляете, встаете в следующую строку - все появляется опять - например так же ведет себя при удалении инсталляционных номеров в ентити) - две возможности:
- через consult/modify - не просто удаляете, а пишите "".
- через modify - выбираете нужный параметр (например tandem), выбираете значение (например ничего) и ctrl-V.
Учите матчасть  

зайти в ПАРАМЕТРЫ абонента (например который основной) и убрать номер аппарата, который с ним в тандеме и галочку "main". Там есть раздел tandem - в котором собственно и сказано - кто с кем. Т.е. удалять абонентов не надо, просто убрать ссылку.