нет - вызов через DID транслятор направляем на номер (не номер аппарата!!!).
Соответственно этот номер прописываем в разделе фильтруемых номеров и указываем куда идти, если АОН не определен (например на номер аппарат абонента)

Далее создаем ячейки SD (в разделе by range) - где говорим куда отправить вызов если АОН определен. А куда отправить номер, чтоб никого не беспокоить - это дело техники (например на виртуальный номер)

Как всегда - через Caller / called filtering (System doc/ general applications/ caller/called filtering). Звонок на КОНКРЕТНЫЙ номер организуете через фильтрацию - т.е. известные АОН в одно место, не известные в другое. Естественно не автоматически

Тут не много не то - я так понял - пишем лог заказа переадресации, а надо было лог отмены переадресации.
При заказе - передается заказ переадресации по основному номеру, но помнится если состояние потом посмотреть - переадресация присутствует и в основном и в дополнительных номерах.

Надо для начала встать каким-то сниффером (типа WireShark) и посмотреть.
Когда мы получили Alert (с Progress Id 80 88) - я так понимаю, прогресс 80 88 - означает, что что-то есть в разговорном тракте. Сниффер покажет - есть ли там голос (типа "вызываемый абонент в настоящее время не доступен).

А кстати - а что такое "вызываемый абонент сбрасывает вызов"? Поднял/положил трубку? Тогда где CONNECT?

У вас какой релиз точно - были вроде проблемы с Alert в котором есть Progress Id, устранялись в каких-то патчах.

А зачем вам SD #*100 с префиксом IP_TG?
Не добавляйте в ARS #100, а SD сделайте - #*100, Call number Prefix_IP_TG+#100, Displayed name пусто (или 0).
Ну как то так в целом

Просто всегда интересно - чего люди ожидают там увидеть. УПРАВЛЯТЬ аппаратом (программировать кнопки, смотреть состояние железа) вроде особо нельзя. Есть нюансы работы в безопасном режиме/ сбросе в заводские настройки (отменить пароль на аппарате) - но это отдельный вопрос.

Чего нет второго, тикета? Почему бы и нет - откладываются тикеты соответствующие настройкам в аккаунтинге - транковая группа может быть указана как нетарифицируемая, некоторые звонки (типа в QSIG TG, или ISDN TG отмеченную как private, где ОХЕ мастер), звонки бывают разного типа - public, private. Может звонок по сети шел, а у вас не откладываются сетевые звонки.

Где второй тикет - вам виднее. Если это связано с конкретным аппаратом - смотрите разницу в настройках. Естественно при проверках - переадресацию заказываем на один номер, звоним тоже с одного конкретного номера.

То что звонок пришедший и ушедший по переадресации выглядит как два тикета - это нормально. При трансфере - будет вообще три тикета - входящий, исходящий и транзитный.
На тему отображения номера вызывающего - в общем случае - отображается номер переадресовавщего (его номер в исходящем setup в поле calling number - он заказал, он будет платить за звонок).

В свежих релизах, если удастся договориться с городом - можно пользоваться функцией Redirect - когда АТС у города запрашивает соединение, не занимающее каналов во внешней TG - тогда будет calling number (кто заказал переадресацию) и redirecting number (кто звонит) - и на принимающей стороне МОЖЕТ быть отображен номер звонящего.

В целом - за АОН при внешней переадресации отвечает пункт System/ other system/ external signalling param - NPD for external forwarding (-1 - отдается АОН переадресовавшего аппарата).

Ну и в догонку еще наверное последний вопрос - как у вас со свободным местом на диске (по соотношению с размером базы данных), и тогда может кто-то что-то посоветует  

Т.е. проблема с полной синхронизацией ВСЕХ станций?
Тогда вопрос по 4760:
- это было с самого начала или началось со временем.
- версии станций/ версия 4760?
- если перегрузить 4760 - ничего не меняется?
- если запустить ручками частичную синхронизацию с какой-то станцией - проходит удачно?

Я так понимаю, что с ОСТАЛЬНЫМИ станциями все хорошо?
Проверяли что со СТАНЦИЕЙ (инциденты, доступ по ftp, проблемы с паролями)?

На моей памяти - все это связано с использованием round trip delay request. В свое время Алкатель и Циско кивали друг на друга (что проблема с противоположной стороны). Потом в Алкатель появилась возможность выключения данного пункта.

Больше проблем такого плана с Циско не встречалось.

По сути - измерение времени прохождения пакетов - некоторый аналог ping.

Как работает ABC-F (VPN overflow - звонки внутри ОДНОЙ сети между РАЗНЫМИ узлами):
1) исходная позиция - есть обычная IP TG, ходят H323 звонки через SD.
2) станции (процессора) договариваются по IP о желании позвонить.
3) входящая сторона сообщает, а исходящая отзванивается на номер VPN префикса. При этом понимаем - что сигнализация идет отдельно (например IP между процессорами), а голос отдельно (ОБЫЧНЫЙ VoIP звонок на VPN overflow префикс).

Соответственно - ничего особого в IP TG нет (в отличии от Т2 - когда важна сигнализация в TG - ABC-F, QSIG, ISDN и т.д.)