Использовал до текущего момента долгое время asterisk cvs и oh323 (до последнего обновления было oh323-0.7.2-pre1) и кроме проблемы со сборкой всего этого других проблем не было. Звонки осуществлялись и по SIP и по oh323.
На днях обновил и asterisk с cvs и собрал oh323-0.7.3 с pwlib_Mimas_patch2 и openh323_Mimas_patch2.
На моё удивление собралось всё прекрасно и не потребовало обработки напильником.
НО!!! При звонке по клиент_SIP -> SIP_asterisk -> oh323_asterisk -> h323_aqua перестал слышать один голос со стороны aqua.. tcpdump показал что от астериска идёт rtp поток на второй сервер (h323), а вот обратно ничего не идёт..
Тоже самое при звонке с другой стороны.
Сигнализация и всё прочее работает правильно... кроме одного rtp потока.
Настройки сервера (aqua) не менялись (он вообще не мой). Таким образом остаётся только мой сервер. НО ПОЧЕМУ???
логи приводить нечего.. oh323 debug toggle выдаёт до смешного мало инфы..
Буду благодарен любой помощи/совету.

В Н.323 определено несколько вариантов проксирования: 1) нету такого, 2) проксировать сигнализацию только и 3) полное проксирование и сигнализации и rtp медии.
Соответственно информация об этом забивается в Акве с одной стороны (при звонке на Н.323 юзера и на Н.323 астериск) и передаётся при звонке. Судя по tcpdump у тебя работает вариант 2), но при установлении соединения, когда Аква передаёт хостам инфу на какой ИП:порт передавать ртп, она или получает неправильную информацию об этом от Астериска, или вовсе не получает. В схеме клиент_SIP -> SIP_asterisk -> oh323_asterisk -> h323_aqua нет последнего пункта -> h323_client. Вот тут и надо смотреть кто с кем пытается соединить ртп. По вариантам 1)-2) клиент_SIP -> h323_client, а по 3) это скорее SIP_asterisk -> h323_client.

Скорее даже 3) oh323_asterisk -> h323_aqua такое замыкание.

на стороне аквы стоит железка для выхода на город.
из вышенаписанного я понял всего лишь что астериск не передаёт информацию о том, на каком порту будет слушаться rtp поток..

Вот таки немного лога от звонка:

-- OH323/299801@172.16.128.4-b5032aba is ringing
-- OH323/299801@172.16.128.4-b5032aba answered SIP/demon-f855
Channel OH323/299801@172.16.128.4-b5032aba (call 'ip$localhost/29513') TX byte count is 1000.
Channel OH323/299801@172.16.128.4-b5032aba (call 'ip$localhost/29513') TX byte count is 2000.
Channel OH323/299801@172.16.128.4-b5032aba (call 'ip$localhost/29513') TX byte count is 3000.
Channel OH323/299801@172.16.128.4-b5032aba (call 'ip$localhost/29513') TX byte count is 4000.
Channel OH323/299801@172.16.128.4-b5032aba (call 'ip$localhost/29513') TX byte count is 5000.
-- H.323 call 'ip$localhost/29513-b5032aba' cleared, reason 4 (Cleared by remote user), established (5 sec)
-- Hungup 'OH323/299801@172.16.128.4-b5032aba'

меня смущает: call 'ip$localhost/29513' причём тут localhost.. но я не помню как это выглядело в работающем варианте.
Повторю, что поток от астериска на акву идёт успешно... обратно rtp данных вообще не видно :(

Так что можно проверить в данном случае?
Это вообще неработающий билд? Руки у меня кривые вдруг стали?

посмотрел на netstat -nap | grep udp
при звонке asterisk держит открытым два UDP порта на нужном IP.. один из которых используется для rtp от asterisk к аква.
По второму видимо должны слушаться данные... которых нет.

Мы работаем с NuFone h323 channel, но синтаксис дебага выше я бы понимал однозначно. localhost всегда транслируется в 127.0.0.1 и ip$localhost/29513 это и есть информация для Аквы - посылать РТП поток на 127.0.0.1:29513
Что она, вероятно, со всей дурью и делает, то есть замыкает на свой локальный loopback интерфейс. А ты ждёшь на своём локальном интерфейсе 127.0.0.1 :))