Глюк с очередями или с переменными.
С asterisk'а перешло использование приоритетов:
exten => 123/321,1,Set(__QUEUE_PRIO=100) ; me
exten => 123,n,Dial(LOCAL/123@support-queue/n,300,gS(3600)C)

Далее в контексте support-queue вызывается:
...
exten => 123,n,Queue(support-queue,t,,,1800)
...

Так вот переменная QUEUE_PRIO в app_queue просто не видится!
Причем NoOp(PRIO=${QUEUE_PRIO}) до app_queue выводит правильный приоритет, т.е. 100!

Решилось так:
...
exten => 123,n,Set(QUEUE_PRIO=${QUEUE_PRIO})
exten => 123,n,Queue(support-queue,t,,,1800)
...

Странный глюк...

И еще проблема с очередями.
Иногда выскакивает море сообщений типа:
"Dropping non-voice (type %d) frame for %s due to long queue length" (это кусок кода).
На практике это выглядит так: вначале проговаривается меню, затем, когда я попадаю в очередь, наступает гробовая тишина.
В консоль валятся такие вот сообщения...
"reload app_queue.so" не помогает, выгружать и загружать модуль обратно не пробовал. Пока решаю перезагрузкой CallWeaver'а.
Хочется понять причину возникновения для решения проблемы...
Причитны такие: "((fin->frametype == CW_FRAME_VOICE) && (qlen > 96)) || (qlen > 128)", но от чего это происходит?

А поддерживает ли CW QUEUE_PRIO?
fgrep?

Поддерживает! Причем все работает, если сделать Set(QUEUE_PRIO=100) до входа в очередь, но не работает, если передавать переменную используя "__" через Dial.
Поэтому получается:
exten => x,1,NoOP(PRIO=${QUEUE_PRIO}) ; показывает 100 !!!
exten => x,n,Set(QUEUE_PRIO=${QUEUE_PRIO}) ; грубый хак
exten => x,n,Queue(...) ; теперь работает QUEUE_PRIO!

Очередной глюк...
Начали появляться сообщения:
"No ports available within the range 10000 to 20000. Can't setup media stream"
Т.е. CallWeaver умудряется выесть 10000 udp-портов при максимальной загрузке 30 одновременных каналов!
На asterisk'е было все нормально... Увеличивать диапазон -- маразм.
По netstat показывает кучу занятых udp-портов, в следующий раз обрачу внимание на статус. ;(

Проявилось 2 раза за 2 недели.

Я убрал CW и перевел на Asterisk обратно клиента :-)
Что-то CW медленно развивается. Я не могу ждать так долго :-)
С учетом t38 в 1.6, интереса к нему еще меньше.
разве что на самом деле стабильнее будет.

Это не клиент -- мы сами его используем (один из наших call-центров).
Т.е. я тренируюсь на кошках. ;)

У меня проблемы с 1.4 были -- напроч отказался собираться chan_h323 требуя последнюю openh323.
В свою очередь openh323 отказалась собираться хоть тресни. ;(

Проводил тут эксперимент с Yate, хотел использовать его в качестве SIP-H323 транслятора.
Эксперимент X-Lite -> Yate -> MVTS прошел на ура.
Эксперимент LinkSys/etc -> asterisk -> Yate -> MVTS -- нет звука. ;(

Без H.323 мне никуда не дется, конечно в течение месяца подъедет Quintum Border Cotroler, который и будет транслировать SIP-H323, но очень хочется запустить все-таки Yate...

Что-то с CW не то...
# netstat -natpu | grep udp | wc -l
4066

Это ж с какого перепугу?!!

Вот на в 5 раз более загруженном asterisk'е:
# netstat -natpu | grep udp | wc -l
61

Не успевают в CW фиксить баги, оставшиеся в наследство от астериска. Похожий баг с незакрытыми UDP сокетами в астериске был исправлен в начале этого года. симптомы были те же самые - кончались порты, выделенные под RTP. тем более что для каждого соединения Asterisk (и CW) я думаю в силу архитектуры открывают портов больше чем реально нужно.