клинеты одни и теже?
просто там такие странные ошибки что пипец
первые две наводят на мысль об ошибках в asn синтаксисе
либо о неуспеваемости отработать мульти задачность

сокок процоц в железке?

самая последня ошибка насчет веитинг треад - тоже самое
наводит мысль об неуспеваемости обработки процессов

уж незнаю что у вас там как
но глюки точно не в астериске и не в стеке

как вариант
попробуйте перейти на oh323 стек

да

ddkprog:

просто там такие странные ошибки что пипец
первые две наводят на мысль об ошибках в asn синтаксисе
либо о неуспеваемости отработать мульти задачность

ну, звонки роутятся по айпи, через макросы
а насчет мультизадачности - так что, asterisk должен падать, если проца не хватило?
Я, бывает, компилю что-то или еще что-то делаю при текущих ~30звонках - процессора 0% idle в течение длительного (более получаса, скажем) времени - asterisk не падает.
А, бывает, падает просто так - когда и процессора много свободного и звонков мало.

ddkprog:

сокок процоц в железке?

Один, celeron-2.4, 1024мб RAM. Правда, понавешано уже и веб серверов штуки 3, и sql штук 5 серверов запущено, но свободная память есть - можно грубо считать что 512 для asterisk остается.

ddkprog:

самая последня ошибка насчет веитинг треад - тоже самое
наводит мысль об неуспеваемости обработки процессов

Этой не было вообще до недавнего времени ни разу - все время было стабильно первые две строчки Assertion fail. Иногда перед этим они сопровождаются сообщением Avoiding H.323 destory deadlock, но редко.

ddkprog:

уж незнаю что у вас там как
но глюки точно не в астериске и не в стеке

Вот пойми его знай в чем. Я допускаю - что asterisk падает от какого-то конкретного звонка с какими-то "недопустимыми" для него (для chan_h323 или же для pwlib/openh323) значениями/ситуацией. Так, как звонки приходят-то от одних клиентов, но у этих клиентов звонки также транзитные и всякое быть может. Падало бы оно каждые 5 минут - можно было бы посидеть над трейсами/tcpdump/etc. А так ждать иногда неделями - не получится. Как еще искать эту ошибку я не знаю :(

ddkprog:

как вариант
попробуйте перейти на oh323 стек

Думал об этом, но как-то боялся. Сейчас посмотрим, что получится на "правильных" версиях pwlib/openh323, пока пол дня - полет нормальный. Если упадет, буду ставить ooh323
ooh323 или oh323 ? их вообще сколько бывает в природе? :)

Всего три, все перечислены. h323 - самый стабильный.

вариант собирать с отладочной информацией
но тогда pwlib и openh323 будут многовато весить
+ еще астериск с дебагами во всех модулях что тебе надо

но по другому ошибку точно не выявишь
ну и потом man gdb
и ищи где там что не так

а насчет мультизадачности - так что, asterisk должен падать, если проца не хватило?

может и памяти
есть секундные пики
в которые может не хватить
ты в top это даже можешь не словить

Повторилось падение :(
---
[May 28 NOTICE[65543]: chan_h323.c:2109 setup_incoming_call: Anonymous call from 'xxx@<local_h323_ip>' rejected
[May 28 NOTICE[65543]: chan_h323.c:2109 setup_incoming_call: Anonymous call from 'xxx@<local_h323_ip>' rejected
[May 28 ERROR[65543]: ast_h323.cxx:225 void PAssertFunc(const char*): Assertion fail: Null pointer reference, file h225_1.cxx, line 431, Error=36
[May 28 ERROR[65543]: ast_h323.cxx:225 void PAssertFunc(const char*): Assertion fail: Invalid cast to non-descendant class, file h225_1.cxx, line 431, Error=36
---
Вот эти setup_incoming_call: Anonymous call from xxxxxx rejected иногда выскакивают непосредственно перед Assertion fail. Но не всегда после setup_incoming_call: Anonymous call from xxxxxx rejected идет Assertion fail и падение.
И вообще - откуда эти Anonymous call from левый_номер@локальный_айпи берутся? Мой asterisk сам себе не должен звонить, вроде :(

Из портов:
pwlib-1.10.0,1
openh323-1.18.0_6
может тоже версии некошерные?
в README не указано, какую именно 1.18.0 лучше всего использовать, то же самое касается pwlib.
кто на FreeBSD использует Asterisk с хоть какой-то нагрузкой и чтобы он не падал ? Какие вы версии pwlib/openh323 используете? Какой канал (h323 ?)

Буду, наверное, другой канал пробовать :(

Нехорошие сообщения -
Setup_incoming_call: Anonymous call from 'xxx@<local_h323_ip>' rejected
Может это попытки звонков peer-to-peer, хорошо бы увидеть ИП откуда, и вас просто могут просто хакать в порт 1720.
Могу выслать адский бинарник, который генерит малюсенькие UDP пакеты, но со страшной силой, занимая весь доступный канал. Ушибают 53-й порт например легко! Потом вымогают деньги с интернет-магазина.

Подумал - а легко from 'xxx@<local_h323_ip>' rejected - может сам Астериск себе звонить!
Если ошибка в диал-плане - и сам себя задушит!
Если входящий по Н323 направить на выход по Н323 - будет как раз такоая ситуация.

Благодарю за содействие!
У меня ВСЕ H323 идут peer-to-peer, без gatekeeper. Порт 1720 закрыт фаерволом для всех, кроме тех, с кем идет H323 соединение.

ded:

Подумал - а легко from 'xxx@<local_h323_ip>' rejected - может сам Астериск себе звонить!
Если ошибка в диал-плане - и сам себя задушит!
Если входящий по Н323 направить на выход по Н323 - будет как раз такоая ситуация.

Dialplan примерно такой:
[peer_name1]
exten => _12345.,1,Macro(to_another_peer)
exten => _567.,1,Macro(to_another_peer)
exten => s,1,Hangup()
exten => i,1,Hagnup()
exten => t,1,Hangup()
[peer_name2]
....
....

[macro-to_another_peer]
exten => s,1,Set(CALLERID(num)="1111111")
exten => s,n,Dial(H323/peer-gw/123${MACRO_EXTEN},120)
exten => s,n,HangUp

h323.conf:
gatekeeper = DISABLE
AllowGKRouted = no
AcceptAnonymous = no
UserByAlias=no


[peer-name1]
accountcode=peername1
type=friend
host=1.1.1.1
fastStart=yes
h245Tunnelling=no
silenceSuppression=no
context=peer_name1
disallow=all
allow=g729

[peer-name2]
accountcode=peername2
type=friend
host=2.2.2.2
fastStart=yes
h245Tunnelling=yes
silenceSuppression=no
context=peer_name2
disallow=all
allow=g729

Не-не-не, пока абстрактные 'xxx@<local_h323_ip>' и _12345 понять неможно, и голова не хочет обрабатывать все эти макросы, конфиги, диал- и другие планы Барбаросса.