та не
ничего я не переделывал

дайте мне кто нибудь нормальный h323 pcap
в котором нормально устанавливаеться соединения и нормально идёт звук
?

отчет по логу h323log2.dat

212.33.19.196 -> OpenLogical(212.33.19.196: RTCP 14047) -> 212.33.19.195

212.33.19.196 <- OpenLogicalAck(212.33.19.195: RTP 32086, RTCP 32087) <- 212.33.19.195
212.33.19.196 <- OpenLogical(212.33.19.195: RTCP 32085) <- 212.33.19.195

212.33.19.196 -> OpenLogicalAck(212.33.19.196: RTP 14046, RTCP 14047) -> 212.33.19.195


212.33.19.196 -> RTP g711 (src 212.33.19.196:14046, dst 212.33.19.195:32084) -> 212.33.19.195
212.33.19.196 <- (dst 212.33.19.196:14046, src 212.33.19.195:32084) g711 RTP <- 212.33.19.195

вывод:
астерисковский chan_h323.so тупит

решение:
- попробуйте другие версии openh323+pwlib(мне разбираться в ошибке лень, может это и кривость в самом chan_h323.c)
либо
- попробуйте chan_oh323.so

либо еще вариант
поищите на алькателе можно ли где то в capability отключить bi-direction
или что то в похожих синонимах в конфигурации алькателя

ssh# pwd
/usr/local/lib/asterisk/modules
ssh# ls -1
app_adsiprog.so
app_alarmreceiver.so
app_amd.so
app_authenticate.so
app_cdr.so
app_chanisavail.so
app_channelredirect.so
app_chanspy.so
app_controlplayback.so
app_dahdibarge.so
app_dahdiras.so
app_dahdiscan.so
app_db.so
app_dial.so
app_dictate.so
app_directed_pickup.so
app_directory.so
app_disa.so
app_dumpchan.so
app_echo.so
app_exec.so
app_externalivr.so
app_festival.so
app_flash.so
app_followme.so
app_forkcdr.so
app_getcpeid.so
app_hasnewvoicemail.so
app_ices.so
app_image.so
app_lookupblacklist.so
app_lookupcidname.so
app_macro.so
app_meetme.so
app_milliwatt.so
app_mixmonitor.so
app_morsecode.so
app_mp3.so
app_nbscat.so
app_page.so
app_parkandannounce.so
app_playback.so
app_privacy.so
app_queue.so
app_random.so
app_read.so
app_readfile.so
app_realtime.so
app_record.so
app_sayunixtime.so
app_senddtmf.so
app_sendtext.so
app_setcallerid.so
app_setcdruserfield.so
app_settransfercapability.so
app_sms.so
app_softhangup.so
app_speech_utils.so
app_stack.so
app_system.so
app_talkdetect.so
app_test.so
app_transfer.so
app_url.so
app_userevent.so
app_verbose.so
app_voicemail.so
app_waitforring.so
app_waitforsilence.so
app_while.so
app_zapateller.so
cdr_csv.so
cdr_custom.so
cdr_manager.so
chan_agent.so
chan_dahdi.so
chan_h323.so
chan_iax2.so
chan_local.so
chan_mgcp.so
chan_oss.so
chan_sip.so
chan_skinny.so
codec_a_mu.so
codec_adpcm.so
codec_alaw.so
codec_dahdi.so
codec_g726.so
codec_g729.so
codec_gsm.so
codec_lpc10.so
codec_speex.so
codec_ulaw.so
format_g723.so
format_g726.so
format_g729.so
format_gsm.so
format_h263.so
format_h264.so
format_ilbc.so
format_jpeg.so
format_pcm.so
format_sln.so
format_vox.so
format_wav.so
format_wav_gsm.so
func_audiohookinherit.so
func_base64.so
func_callerid.so
func_cdr.so
func_channel.so
func_curl.so
func_cut.so
func_db.so
func_enum.so
func_env.so
func_global.so
func_groupcount.so
func_language.so
func_logic.so
func_math.so
func_md5.so
func_moh.so
func_rand.so
func_realtime.so
func_sha1.so
func_strings.so
func_timeout.so
func_uri.so
pbx_ael.so
pbx_config.so
pbx_dundi.so
pbx_loopback.so
pbx_realtime.so
pbx_spool.so
res_adsi.so
res_agi.so
res_clioriginate.so
res_convert.so
res_crypto.so
res_features.so
res_indications.so
res_monitor.so
res_musiconhold.so
res_smdi.so
res_speech.so

в данной конфигурации канал ooh323 вообще не установлен.

ssh*CLI> core show channeltypes
Type Description Devicestate Indications Transfer
---------- ----------- ----------- ----------- --------
SIP Session Initiation Protocol (SIP) yes yes yes
MGCP Media Gateway Control Protocol (MGCP) yes yes no
Local Local Proxy Channel Driver yes yes no
H323 The NuFone Network's Open H.323 Channel no yes no
----------
4 channel drivers registered.

Ну чем тогда объяснить что с ТТК то все нормально звонки проходят без проблем.Можем выложить pcap общения с TTK ?

выкладывайте нормальный pcap, посмотрим

bindaddr= ? в h323.conf ?
IMHO - это ip$localhost/24844 не верно, там должно наблюдать ip$212.33.19.195/24844

та то не принципиально
вот на 2 странице он показывал лог и конфиги

там другая проблема
алькатель хочет bi-direction канал
а астерис с ним не умеет
из за чего берет похоже не правильный RTP порт

ssh# cat /usr/local/etc/asterisk/h323.conf
[general]
port = 1720
bindaddr = 212.33.19.196
disallow=all
allow=alaw
allow=ulaw
h245tunneling=no
faststart=no
directrtpsetup=yes
dtmfmode=rfc2833
AcceptAnonymous = yes
context=office
incominglimit=4
canreinvite=no

[alcatel]
type=friend
context=office
host=212.33.19.195
port=1720
disallow=all
allow=alaw:20
allow=ulaw:20
h245tunneling=no
faststart=no
canreinvite=no
incominglimit=4


[ttk]
type=friend
context=office
host=172.16.6.17
port=1720
disallow=all
allow=alaw
allow=ulaw
h245tunneling=no
faststart=yes
canreinvite=no
directrtpsetup=no
incominglimit=4
ssh#
Завтра выложим pcap с ТТК.

Из учебника :"Рекомендацией Н.245 предусмотрена возможность создания логических каналов двух видов: однонаправленных (unidirec-tional), т.е. открывающихся в направлении от источника к приемнику информации, и двунаправленных (bidirectional), открывающихся сразу в двух направлениях - от источника к приемнику информации и в обратном направлении......"
То есть как я понимаю алкатель открывает двунаправленный канал с разными портами для RTP ,а астериск такое не могёт в принципе ,поэтому тупит шлет RTP не по тому каналу то есть не на тот порт вы это имели в виду?

да это и имею ввиду
либо нужно заставить алкатель не открывать логический канал в сторону астериска(хотя по той же спецификации логический канал как раз должен открывать алкатель и не открывать астериск)

либо это глюк в openh323 и вам стоит его просто обновить
но нет гаранитии что это глюк именно в openh323
может это кривизна в самом модуле астериска


поэтому как вариант попробуйте альтернативный chan_oh323
может он умеет в бидирекшинал каналами работать

вообщем вариации разных каналов + конфиги + pcap смогут точно прояснить ситуацию