Comments 31
1. Проблемы в webrtc из коробки зачастую просто так не заводится, требует обязательно wss
2. по мне pjsip очень не удобен, кучу конфигов для настройки и усложненный мониторинг
Хм, странно. Lua как раз и был выбран из-за его простоты и наглядности.
По поводу WebRTC — я придерживаюсь мнения, что Кесарю кесарево, а браузеру браузерово. Ну, то есть, web — это web, а voip — это voip и лучше их не смешивать.
Если же нужно web звонилку, то юзаю kamailio с rtpengine и в астериск приходит чистый VoIP. Лучше этого пока не нашел.
С PJSIP да, согласен — хотели как лучше, а получилось как всегда. Можно же было поменять движок, но оставить синтаксис тех же конфигов.
Привет землякам…
Почему не AsyncAGI? Хм, наверное, потому что это AGI контрролируемый через AMI, а это и так реализовано в lunopark'е.
Мы же можем накатать что-то типа:
ami.removeEvents('*')
ami.addEvent('AsyncAGI',function(e)
if e['SubEvent'] and e['SubEvent'] == 'Start' then
ami.Agi{channel = e['Channel'], command = 'VERBOSE "Processing inside AsyncAGI"'}
ami.Agi{channel = e['Channel'],command = 'ASYNCAGI BREAK'}
end
end)Но это, ну так себе, не красиво. Да и согласитесь с FastAGI как-то по понятней получилось.
Сравнивать с freepbx бесполезно, там большая часть ядра написана людьми не понимающими, как что работает…
А по поводу скорости с моей точки зрения на первом месте диалплан+func_odbc+ cel. Lua и AMI все же прилично грузят систему, особенно если много евентов генерится(например, куча очередей).
С чистым диалпланом не сравнивал, так как давно перешел на аналогичные системы управления.
Если тесты накидаете, могу заморочиться.
на первом месте диалплан+func_odbc+ cel
Вынужден не согласиться, CEL еще тот монстр.
Lua и AMI все же прилично грузят систему
Но не в этом случае. AMI из всех возможных подходов самый легковесный, а Lua, в данном случае, вообще вынесен из астериска во вне.
Опять-таки, luajit. Можно же lunapark через него запустить.
Вообще странно, куча штампов. Вы начинаете статью с отсылкам к скорости, и вообще ее не измеряете, как и нагрузку. Ну и «возможность описывать диалплан полноценным языком» — та еще шняга, особенно учитывая, что как языки, что диалплан, что lua — где-то на одном уровне как по понятности так и по выразительности.
Ну зато CEL можно выключить все, что не надо
В AMI то же. Только делается это не очевидными способами. Да и eventfilter еще ни кто не отменял.
и вообще ее не измеряете, как и нагрузку.
Измеряю, но не публикую, ибо смысл вне сравнения. Я могу написать, что аналогичные подходы упираются в пропускную способность сети, а никак не в производительность сервера. Но это все вода без противоположенных результатов тестов.
Основной посыл поста — это не тесты производительности в сравнении, а то, что его (asterisk) не умеют "готовить".
что диалплан, что lua где-то на одном уровне как по понятности так и по выразительности.
Хм, громкое заявление. Впрочем, тут уж кому как.
Так же на сколько я понял ваше приложение одно-поточно, а если это так то как масштабировать его? Если это не так то как консолидировать память потоков?
Измерений как таковых нет, задачи не стояло.
Да вы правильно поняли — однопоток, кооперативная многозадачность в чистом виде. То что касается масштабирования — по ка даже не задумывался.
Те же очереди заставили нас призадуматься, lua и asterisk не лучший выбор, но самый простой при небольших объемах(до 10-15 cps).
Так же хочу отметить что asterisk, к сожалению, не про скорость, как мне кажется.
Это скорее не болид, а комбайн с пекарней и магазином на борту, дает много функционала, но жертвует «скоростью».
Одна из причин модули SIP, chan_sip — deadlock при больших нагрузках, pjsip — не производителен.
Но если всё же хочется делать что-то подобное на asterisk ведь есть же GLOBAL для общей кучи, подключение к бд можно как через res_odbc с пулом, так и на каждый звонок, например lua.mysql(dba конечно спасибо не скажут).
Вы рассматривали такие варианты? Если да, то в чем минусы?
Бытует мнение что при увеличение нагрузки и усложнении логики вы можете упереться в ресурс одного ядра и как следствие замедление работы asterisk.
Бытует мнение, что настаящая многозадачность возможна только на многопроцессорных системах. Все остальное это псевдо-многозадачность, в которой накладные расходы по переключению задач куда значительней чем на переключение контекстов в сопраграммах.
Те же очереди заставили нас призадуматься, lua и asterisk не лучший выбор
Если вы под lua имеете в виду pbx_lua, то это не то, в посте/статье описывается совсем другой подход, в посте не используется астерисковский pbx_lua. А по поводу последнего я высказался в самом посте.
Так же хочу отметить что asterisk, к сожалению, не про скорость, как мне кажется. Это скорее не болид, а комбайн с пекарней и магазином на борту, дает много функционала, но жертвует «скоростью».
Вы сейчас перефразировали посыл поста. Я про то же, ни что не мешает выкинуть пекарню, магазин и прочее с борта, есть вероятность что получите скорость.
Про chan_sip — что есть то есть, тут уж ни чего не поделаешь, а вот pjsip — это вы зря.
например lua.mysql(dba конечно спасибо не скажут).
Сейчас точно уверен, что вы о pbx_lua — еще раз акцентирую внимание на том что в посте совсем другой подход. Асинхронность требует определенного подхода, вы не можете внутри асинхронного кода просто вызвать конект к базе и выполнить запрос. Точнее можете, ни кто вам не помешает, но если запрос подвиснет, то подвиснет вашь поток.
Если вы под lua имеете в виду pbx_lua, то это не то, в посте/статье описывается совсем другой подход, в посте не используется астерисковский pbx_lua.
Я не о pbx_lua, а в целом о задаче и её решении с помощью asterisk и lua/python/php/perl…
Я про то же, ни что не мешает выкинуть пекарню, магазин и прочее с борта
Конструкции несущие))
а вот pjsip — это вы зря
А можно чуть больше информации?
Сейчас точно уверен, что вы о pbx_lua
Верно.
Точнее можете, ни кто вам не помешает, но если запрос подвиснет, то подвиснет вашь поток.
А как вы решили это в своем приложении?
Конструкции несущие))
Ну как сказать. Гляньте в modules.conf, все ли там "несущие".
А можно чуть больше информации?
Встречный вопрос, какой cps для вас выше среднего?
А как вы решили это в своем приложении?
Асинхронностью, не синхронные запросы к базе и т.д. и т.п.
Ну как сказать. Гляньте в modules.conf, все ли там «несущие».
32 modules loaded
если отключить что-то еще то комбайн не заработает как надо.
Встречный вопрос, какой cps для вас выше среднего?
Тут всё зависит от версии астера, модуля SIP, и функционала.
Очень примерно от 30 до 70. После этих пределов SIP стэк астера не успевает на тайминги и далее разного рода проблемы как снежный ком.
Асинхронностью, не синхронные запросы к базе и т.д. и т.п.
А что вам помешало реализовать в pbx_lua?
Мне интересно в чем именно «killer feature», ведь роутинг не требует асинхронности, а статистику можно собрать другими способами, более простыми.
AMI который парсится постоянно
Так ARI то тоже парсится постоянно, ну, разве что в JSON и только подписанные события. А если вам нужны ВСЕ события, кроме скажем десятка из тысячи, вы оформляете подписку на нужные. Тоже прекрасно реализовывается через eventfilter.
Хочу акцентировать внимание на том, что я не против ARI, я лишь топлю за то, что потенциал AGI/AMI не используется даже на 50% своих возможностей.
Интересный проект конечно, но чисто из академического интереса. pbx_lua вполне себе.
Так вот именно, что НЕ вполне. Сделайте тестовое логирование в extensions.lua, в самом начале перед формированием таблицы extensions. Сильно удивитесь при звонке.
А интерес то может быть и академический, только вот на основе такого проекта вполне себе успешно перемалывается куча voip трафика с lcr, fas detection и цепочек маршрутов.
Проблемы с пользователями, очередями и в целом с механизном realtime.
А что с realtime в астериске не так, как раз там то все вполне себе. А очереди, лично я, реализовал на основе lunaparka как voip-приложение.
Сделайте тестовое логирование в extensions.lua, в самом начале перед формированием таблицы extensions.
Не очень понял, если честно. Вы к тому что на каждый звонок дергается этот скрипт? В лучае с lunapark у вас каждый вызов это новый tcp коннект. Единственная проблема pbx_lua в том что нельзя шарить между звонками данные напрямую (например коннектор к БД. Но и тут можно найти решение. Например у меня на нагруженных системах у каждого астериска есть своя реплика postgresql с которой он читает + коннект через сокет файл.)
А что с realtime в астериске не так, как раз там то все вполне себе
Во-первых: нужно иметь определенную структуру БД(название таблиц и колонок). Если бы не view в БД, не знаю как вообще этим пользовался бы. Во-вторых: непрозрачный и не очень удобный механизм кеширования(это я про Sorcery). Ну и в целом он морально устарел(вы удивитесь сколько он делает обращений в БД). Хотелось бы более удобного механизма.
Смущает так же необходимость держать еще 1 сервис. Как вы его резервируете? Цепляете ли к одному сервису больше 1 астериска? Или 1 lunapark = 1 астериск?
Вы не подумайте, я не хейчу. Просто про этот инструмент слышу впервые. Поэтому много вопросов. Может даже соберу тестовый кластер и погоняю вызовы. Хочется знать сколько звонков и какой cps вытянет lunapark
Не очень понял, если честно. Вы к тому что на каждый звонок дергается этот скрипт?
Пример
local log, err = io.open("/tmp/pbx_lua.log","a")
if log then
log:setvbuf("no")
log:write('--- iteration ---\n')
log:close()
end
extensions = {
lua = {
["000"] = function(context, extension)
app.Verbose("---------------- Test LUA Call -------------------------")
end
}
}Один звонок и смотрим в /tmp/pbx_lua.log, удивляемся…
Лучше новый tcp коннект, чем такое.
Но и тут можно найти решение. Например у меня на нагруженных системах у каждого астериска есть своя реплика postgresql с которой он читает + коннект через сокет файл.)
Тоже решение так себе если честно. Нагруженный сервер(asterisk), база(postgre), что то еще и все на одной "бочке", я бы разнес. Прелесть lunaparka'а в асинхронности — это как nodejs и nginx(nginx скорее event driven, но не суть) с одной стороны и apach prefork с другой.
По поводу realtime'а — возможно вы правы, но мне на транзите его хватает с лихвой.
Цепляете ли к одному сервису больше 1 астериска? Или 1 lunapark = 1 астериск?
Тут как бы из архитектуры все ясно. FastAGI — цепляем кучу *, а вот с AMI — один слушатель/клиент, один астер.
Хочется знать сколько звонков и какой cps вытянет lunapark
Выше писал про тесты, на "боевых" трафик размеренный, больше 64 в cps я и не видел. Из того, что имею для тестов это учетки мультифон-бизнес, с учетом многоканала(300 каналов) отрабатывают все. И это не какой то sipp тест, а с полноценным звонком на 0500 и записью.
Один звонок и смотрим в /tmp/pbx_lua.log, удивляемся…Получил 3 записи
— iteration ---Одна на звонок, одна на hangup hook, одна на gosub в Dial. Ничего криминального и удивительного как по мне =). Или должно было быть что-то еще?
Тоже решение так себе если честно. Нагруженный сервер(asterisk), база(postgre), что то еще и все на одной «бочке», я бы разнес.
Я может не так выразился. У каждого астериска именно реплика одной базы с настройками. Тоесть нагрузка на БД размазана. Каждый астериск читает из своей копии. Нагрузки на Master базу при этом нет вообще. Если упадет база на каком нибудь из астерисков, kamailio просто попробует позвонить через другой астериск.
Одна на звонок, одна на hangup hook, одна на gosub в Dial. Ничего криминального и удивительного как по мне =). Или должно было быть что-то еще?
OK, тогда почему на не существующий экстеншен в этом контексте записей уже 4-е. Стоп, по такой логике на каждое application будет gosub. И обратите внимание, что в примере нет Dial.
Да и это все не важно — такое дерганье это же файловая операция + выполнение.
а как делается lcr? может быть вообще выложите свой конфиг на посмотреть? )
Asterisk — это болид «Формулы-1», а не рейсовый автобус