Это из серии криворукости персонала оператора или конвертера сигнализации. Для отлавливания этих багов периодически ездит девушка с чемоданом АПУС(или как он там сейчас называется)  и проверяет правильность тарификации.
В ТУ на R1.5 прописан защитный интервал 3 с. после приема линейного сигнала "Ответ абонента" для этого случая. Поэтому исторически на наших сетях не тарифицировались разговоры длительностью  менее 3 секунд.  Кстати, на 4400 это отлично видно - если звонить по исходящей R1.5 - отсчет времени разговора четко начинается после 3-х секунд после ответа абонента.
И еще раз подчеркну - по СЛМ нет процедуры передачи-приема АОН (см. SDL-диаграмму у Гольдштейна). Поэтому надо смотреть, что фактически происходит привходящем вызове на канале  - с помощью протокол-тестера или трассировки.

Отлично. Особенно радует то, что оператор что-то сделал. Последнее время от тех.поддержки операторов добиться изменения чего-либо просто невозможно.
По поводу АОН - проблем быть не должно - вряд ли кто-нибудь будет тарифицировать 1.5 секунды, которые максимально длится запрос АОН. И чисто теоретически - ну не  может быть запроса АОН на входящем м/г (см. Б.С.Гольдштейна). Интересно было бы встать тестером (только где его найти сейчас?)  или, в крайнем случае, завести трассу.  

С вероятностью 80% -  работало, как и сейчас, не обращали внимания.
С вероятностью 20% - провайдер что-то поменял, и теперь голосовой тракт не проключается  до OXE, или где-то теряется PROGRESS INDICATOR и вызывающий не слышит зуммер.

Там по алгоритму - только "Отбой" (при м/г занятости) или  "Вмешательство" (при местной занятости) со стороны телефонистки.

Потому что ЦПУ знает состояние абонента Б локальной АТС после приема всех цифр номера абонента и выставляет  линейный сигнал "Абонент Б занят" ( с зуммером "Занято" или нет, не помню).

Коллеги, как уже писалось, центральная АТС всегда будет посылать линейный сигнал "Абонент Б свободен" при вызове на сетевого абонента, занят он или нет. В автомате работы м/г  сигнализации R1.5 нет состояния перехода от линейного сигнала "Абонент Б свободен" к линейному сигналу "Абонент Б занят". Даже если что-то получится с overflow на виртуально занятого абонента возможности подать линейный сигнал "Абонент Б занят".нет. Максимум - подключится зуммер "Занято", если его не было (в чем я сомневаюсь).
Оптимально (но маловероятно) - перейти на ISDN и забыть весь этот геморрой с отрыжками "ручной" сигнализации. Также маловероятно - договориться с провайдером проключать голосовой канал, чтобы вызывающий абонент слышал зуммер "Занято".

А что в трассе ABC-F видно между узлами при вызове на занятого абонента на узле Б?


Кроме этого, в R1.5 была тонкость. При входящем вызове на центральный узел ЦПУ не знает состояние абонента Б и всегда посылает линейный сигнал "Абонент Б свободен", но в случае занятости он должен проключать зуммер "Занято" при наличии линейного сигнала "Абонент Б свободен". Неплохо бы тестером ИКМ посмотреть и послушать. Предположу, так как оборудование провайдера не ловит зуммер "Занято", а, скорее всего, отслеживает только линейный сигнал, то оно и считает, что идет вызов.

Для начала проверить наличие патчей и установить последние - для 8770 они регулярно выпускаются.

Да, похоже на маркетинг. В лабе на CS1 несколько SIP ТГ работают. Что будет под реальной нагрузкой - не знаю.
C сайта производителя
Так что использование CPU6 и CS-1 с SIP'ом - на свой страх и риск.

ОК.  Поcледуем рекомендации Vad'a.
По поводу Fast Start'a - топикстартер может выбрать время и отключить Fast Start на одном узле OXE и проверить работоспособность.

Не надо вводить в заблуждение почтенную публику этого форума своим непониманием оригинала H.323.
- в 680-м пакета трассы этого нет, там есть Normal Call Clearing.

Это обнаружил Андрей. Все благодарности ему.
Уважаемый error, 0x5a это не причина, а код сообщения RELEASE COMPLETE.

Есть немалая вероятность того, что и с ГК будут такие же проблемы.
Проблема, по-моему мнению, в том, что C40 не использует Fast Start и  H245 tunneling (это видно в Flow Sequence в Wireshark)

Было бы неплохо проверить, когда оба конца настроены на FastStart/Tunneling либо оба конца работают без   FastStart/Tunneling.

Бинго!
Не получив OpenLogicalChannelAck OXE  с чистой совестью по истечении таймера 10 секунд завершает вызов.
Почему Cisco ведет себя по-разному в удачном и неудачном сценарии - вопрос к Cisco/Tandberg'у.

Ну вот, становится теплее.
Это не сегментированные пакеты и не служебные пакеты. Это H.245, что-то  вроде SDP в SIP - определение media capabilities и пр., очень важная часть при установлении соединения по H.323.
Прсоединяюсь к Андрею В приведенном удачном  скриншоте курсор вообще стоит на roundtripdlayresponse (то есть keep-alive процедура), а на неудачном openlogicalchannel masterslavedetermination. То есть из приведенных картинок невозможно ничего понять.

По этой ссылке поддержка G.729 для H.323 появилась в версии TC 6.2.0, возможно, надо firmware на С40 обновить.
http://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/software/tc6/r­elease_notes/tc_software_release_notes_tc6.pdf. Хотя не факт, может там программно транскодинг делается (как на CUCM).

Проблема все равно в том, что соединение должно устанавливаться или нет. В wireshark-трассе надо смотреть.

Да, с G.722 в OXE как-то не очень. То есть он поддерживается для 2-х IP-устройств на одном узле, при условии, что оба устройства его поддерживают. Как понимаю, функцию транскодинга (для TDM-оборудования) для G.722 OXE не делает.