Система: FreeBSD 6.1, Asterisk собран из портов, версия 1.2.13 (только он не собирался по умолчанию, пришлось обновить порты Curl, libpri, spandsp, прописывать некоторые патчи руками и в ручную ставить asterisk-addon для писания логов в mysql).

Конфигурация h323 (h323.conf)

[general]
port = 1720
bindaddr = 0.0.0.0
dtmfmode=rfc2833
gatekeeper = DISABLE
fastStart=yes
h245Tunnelling=yes
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;allow=g729
;aloow=gsm

[phone202h]
type=friend
host=192.168.196.71
disallow=all
allow=alaw
allow=ulaw
allow=gsm
callerid=h323test

phone202h это SJ Phone 1.60.289a
Конфигурация sip:

[general]
context=default ; Default context for incoming calls
bindport=5060 ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=yes ; Enable DNS SRV lookups on outbound calls
domain=<ну тут имя домена> ; Set default domain for this host
disallow=all ; First disallow all codecs
allow=alaw ; Allow codecs in order of preference
allow=ulaw ; Allow codecs in order of preference
language=ru ; Default language setting for all users/peers
; да, понятно, что ru не будет работать
...

[phone202]
context=local-phones
type=friend
;username=202
;secret=202
host=dynamic
mailbox=202

phone202 это X-lite 3.0 34025

При звонке с SJ Phone на X-lite получаю следующее в логе (h.323 trace 1, h.323 debug):

vgw3*CLI> h.323 debug
H323 debug enabled
-- Registered SIP 'phone202' at 192.168.196.68 port 39344 expires 3600
-- Saved useragent "X-Lite release 1006e stamp 34025" for peer phone202
vgw3*CLI== New H.323 Connection created.
-- Setting up Call
-- Call token: [ip$192.168.196.71:3851/4096]
-- Calling party name: [Test]
-- Calling party number: [203]
-- Called party name: [202]
-- Called party number: [202]
--Received SETUP message
Allowed Codecs:
Table:
G.711-uLaw-64k <1>
G.711-ALaw-64k <2>
UserInput/hookflash <3>
UserInput/RFC2833 <4>
Set:
0:
0:
G.711-uLaw-64k <1>
G.711-ALaw-64k <2>
1:
UserInput/hookflash <3>
2:
UserInput/RFC2833 <4>

=-= In OnAnswerCall for call 4096
- Progress Indicator: 0
- Inserting PI of 0 into ALERTING message
19:02:12.541 H225 Answer:86cb100 h323ep.cxx(2582) Codec Could not open default sound channel "" for recording:
19:02:12.542 H225 Answer:86cb100 channels.cxx(1147) LogChan Transmit thread aborted (open fail) for G.711-ALaw-64k <2>
-- Transmitting RFC2833 on payload 101
-- Executing Dial("H323/ip$192.168.196.71:3851/4096", "SIP/phone202|20") in new stack
-- Called phone202
-- Received Facility message...
-- Received Facility message...
19:02:12.627 H225 Answer:86cb100 h323ep.cxx(2582) Codec Could not open default sound channel "" for recording:
19:02:12.627 H225 Answer:86cb100 channels.cxx(1147) LogChan Transmit thread aborted (open fail) for G.711-uLaw-64k <2>
19:02:12.629 H225 Answer:86cb100 h323ep.cxx(2582) Codec Could not open default sound channel "" for recording:
19:02:12.630 H225 Answer:86cb100 channels.cxx(1147) LogChan Transmit thread aborted (open fail) for G.711-ALaw-64k <1>
-- SIP/phone202-086f9000 is ringing
Sending alerting

-- SIP/phone202-086f9000 answered H323/ip$192.168.196.71:3851/4096
vgw3*CLIAnswering call ip$192.168.196.71:3851/4096
=-= In OnConnectionEstablished for call 4096
-- Connection Established with "Test [192.168.196.71]"
== Spawn extension (default, 202, 1) exited non-zero on 'H323/ip$192.168.196.71:3851/4096'
Jan 18 12:12:55 ERROR[1519]: cdr_addon_mysql.c:159 mysql_log: cdr_mysql: Unknown connection error: (2006) MySQL server has gone away
vgw3*CLI-- Sending RELEASE COMPLETE
-- ClearCall: Request to clear call with token ip$192.168.196.71:3851/4096, cause EndedByRemoteUser
19:15:08.946 H225 Answer:86cb100 h323pdu.cxx(1297) H225 Read error (0):
-- ClearCall: Request to clear call with token ip$192.168.196.71:3851/4096, cause EndedByRemoteUser
19:15:08.969 H323 Cleaner h323.cxx(1757) H323 Connection ip$192.168.196.71:3851/4096 terminated.
-- Test [192.168.196.71] has cleared the call
== H.323 Connection deleted.
Поиск в тырнете сказал, что ошибки:
LogChan Transmit thread aborted (open fail) for G.711-uLaw-64k <2>
и
Codec Could not open default sound channel "" for recording:
Вызываются проблемами со звуковой картой на машине с Asterisk'ом, НО(!!!) отродясь её там нет и быть не должно!!! При установке большего уровня trace ни чего дополнительного не видно. Что ещё можно посмотреть, что бы понять в чём "косяк"?
P.S. да ещё, самое странное и что меня очень сильно смущает, это пустота при h.323 show codecs

Ну вообщем с проблемой разобрался (после того как пересобрал 3 версии h.323), оказалось всё просто. Эта "гениальная" софтина не понимает запись вида bindaddr = 0.0.0.0 в h323.conf!!!! Что самое интересное ТАЖЕ САМАЯ запись в sip.conf работает?
Может ли мне кто-нибудь мне объяснить этот какзус? Или как только в теме есть h.323 все сразу же перестают её видеть?
Да кстати, если таки кто-нибудь глянет, не ответит ли на такой вопрос, а если мне нужно будет повесить h.323 на несколько интерфейсов (ну например для целей проксирования RTP)? А да, ещё, а тут как только проксирование RTP трафика или можно как-нибудь заставить * направлять его напрямую или я вообще ни чего не понял?

>0.0.0.0 в h323.conf
Известная грабля - кривость реазизации канального драйвера h.323 - его сдедали по остаточному принципу - лишь бы что-то как-то. Хотя h.323 хорошо страндартизован, это практически сигнализация ISDN только по ethernetу.
А насчёт нескольких интрефейсов - отвечу как ответили бы все - юзай gk + *
Сам так мучусь.

Mike_A, проблема с 0.0.0.0 - это не проблема реализации chan_h323. Всё гораздо глубже и сложнее.

Так, H.323 по определению поддерживает 3 типа вызовов, которые могут сочетаться в произвольной форме:
1) end-to-end, когда два H.323 устройства говорят напрямую, RTP между ними бегает тоже напрямую;
2) gatekeeper-routed, когда сигнализация ходит через гейткипер, а RTP - напрямую;
3) gatekeeper-proxied, когда и сигнализация, и RTP бегают через гейткипер.

Плюс бывают различного рода NAT'ы (в любой из вышеприведенных схем) и т.д.

Далее, мы с адреса X получаем запрос на открытие RTP канала с адресом Y. Вопрос - какой локальный адрес при этом мы должны использовать? Правильно, а фиг бы его знал, особенно с учетом того, что Asterisk (почему-то) до сих пор не имеет никакого API для того, чтобы сходить в системную таблицу маршрутизации и посмотреть, с какого интерфейса уйдет пакет на адрес Y. Отсюда вся и беда.

Если кто не поленится и откроет баг на bugs.digium.com, то я может сделаю какую-нить доп. опцию для user/peer типа mediaaddr, который и будет использоваться в качестве локального адреса при создании RTP-каналов.


(подсказка - скоро в Астериске будет свой собственный гейткипер!).


WBR,
Paul.