Ivon, сделай
CLI>load chan_h323
Астериск выполнит молча, но на самом деле не загрузит его,зато ответ на свой вопрос ты сразу увидишь в
var/log/asterisk/full

:)
Действительно... грит нету ooh323.conf
А h323.conf тоже должна присутствовать? А то затер я ее...

Теперь любой входящий или исходящий звонок по h323 роняет аст.
кстати, а команда dial также выглядит в этом случае? т.е. ooh323/XXXX

вот мой конфиг:
cat ooh323.conf

[general]
port = 1720
faststart=yes
bindaddr = 111.222.333.444
dtmfmode=rfc2833
gateway=no
gatekeeper = DISABLE
context=from-internal
dtmfmode = h245signal
jbenable = yes
jbforce = no
jbmaxsize = 50
jbresyncthreshold = 1000
jbimpl = fixed
jblog = no
disallow=all
;allow=g729
;allow=g723
allow=ulaw
;allow=alaw
;allow=gsm





[ldk_1]
type=friend
faststart=no
h245tunneling=no
h245inSetup=no
context=from-internal
ip=111.222.333.444
port=1720
canreinvite=no
disallow=all
allow=ulaw


[ldk_2]
type=friend
faststart=no
h245tunneling=no
h245inSetup=no
context=from-internal
ip=111.222.333.444
port=1720
canreinvite=no
disallow=all
allow=ulaw



[goldentelecom_in]
type=friend
context=from-pstn
ip=111.222.333.444
port=1720
canreinvite=no
disallow=all
allow=ulaw

Вобщем, я долго колупался, пока оно у меня со всеми тремя объектами заработало одновременно нормально...
В какую сторону копать, чтобы устранить падение аста?

asterisk-addons.i386 1.2.4_1.2.12.1-1.294 installed

# yum install asterisk-addons
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages from CentOS-4 - Updates
Finished
Excluding Packages from CentOS-4 - Base
Finished
Excluding Packages from CentOS-4 - Addons
Finished
Excluding Packages from CentOS-4 - Extras
Finished
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package asterisk-addons.i386 0:1.2.8-1 set to be updated
--> Running transaction check
--> Processing Dependency: asterisk >= 1.2.26.1 for package: asterisk-addons
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package asterisk.i386 0:1.2.26.1-48 set to be updated
--> Running transaction check
--> Processing Dependency: zaptel >= 1.2.19 for package: asterisk
--> Processing Dependency: libpri >= 1.2.5 for package: asterisk
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package zaptel.i686 0:1.2.22.1-1 set to be updated
---> Package libpri.i386 0:1.2.7-1 set to be updated
--> Running transaction check
--> Processing Dependency: zaptel = 1.2.10 for package: zaptel-modules-2.6.9-34.0.2.EL
--> Processing Dependency: zaptel = 1.2.10 for package: zaptel-modules-2.6.9-34.0.2.ELsmp
--> Finished Dependency Resolution
Error: Missing Dependency: zaptel = 1.2.10 is needed by package zaptel-modules-2.6.9-34.0.2.EL
Error: Missing Dependency: zaptel = 1.2.10 is needed by package zaptel-modules-2.6.9-34.0.2.ELsmp

Ночами ставил эксперименты на живой системе:
Пошел в сторону компиляции всего нужного софта из исходников на Etch.
Собрал zaptel-1.4.11, asterisk-1.4.21, freepbx-2.4.1. Конфигурить пришлось вручную, чтобы исключить возможность косяков. Первоначально все завелось нормально, час ровного полета придал уверенности. В ходе проверки связи, на предмет ошибок в конфигурении, нашел причину завала сервера:
Дело в том, что у меня на самом астериске всего десяток voip абонентов. Все остальные - это в транскрипции freepbx - "custom extensions" с dial rules вида: zap/g1/0001100. Есть несколько очередей, обслуживать которые написал эти самые custom extensions. Дык вот в одной из них 8 extensions, стратегия вызова - hunt. Остальные очереди с такими же параметрами, но с одним - двумя абонентами. Начинается все неплохо, но с увеличением количества пиров в очереди, load average растет как на дрожжах. В общем, после минуты обработки очереди всеми 8-ю custom extensions, load average доходит почти до 2-х (естественно отваливается overlapdial; MOH и anoncements жевались...) Как и на Эластиксе... Правильно... Сервак вис в основном как раз во время обеда, когда отдел продаж сваливал весь до одного по кафешкам и трубу некому было взять... А еще не заработала DISA - не распознавла DTMF (как и на триксбоксе).
Вобщем, даунгрейдил астериск раза три, даунгрейдил заптел до 1.4.9, проблема не решилась. Потом даунгрейдил freepbx до 2.3.1. Даунгрейды делал путем перестановки оси и всего начисто. Конфигурил руками для чистоты эксперимента. Так проблема тоже не решилась.
Потом собрал свежайший asterisk 1.2 и freepbx 2.4.1 - тут с таким же конфигом проблема отсутствует (как и на триксбоксе 2.0). Накосячил где-то с mysqlcdr (уже разобрался), и покачто не поддается к сборке ни один из h323 каналов. на 1.4 собирается без проблем, а тут нужно шаманство. Пока откатился на ТБ 2.0.
Сегодня гугл вывел на блог by IgorG о том, что в новых версиях аста и заптела профиксили много багов, но все записи про сип, и про ядро линукс. Завтра почитаю оригинал.