BK
Слава, у меня на самом деле вопрос больше не в том, каким механизмом воспользоваться, а все же нафига такой замут в диалплане? может есть какой-то подводный камень для чего именно api_hook нужен
Size: a a a
2020 February 22
BK
Слава, и интересный у тебя конечно набор недоязыков :) С учетом того, что сами разрабы рекомендуют именно lua
С
Слава, и интересный у тебя конечно набор недоязыков :) С учетом того, что сами разрабы рекомендуют именно lua
Для внутреннего скриптования конечно Луа, потому что его интерпретатор - самый быстрый из существующих.
С
А если писать внешний сервис, который слушает события через ESL, то лучше использовать что-то более надёжное.
IO
Ребята, во-первых с наступающим/пившим
А во вторых - продолжаю скрещивать Fusion с Bitrix. Чтобы информация о звонках, прошедших через fusion прилетала в bitrix. И вот возник такой вопрос. Вариант первый - сесть на events с помощью LUA handler. Минус - вариант не сильно понятен не слишком продвинутому админу. Вариант второй - все таки делать вставки в диалплан fusion. И вот тут, начав с ним детально разбираться, не совсем понял зачем так сделано. А именно - есть у них ext под названием local_extension, где стоит:
hangup_after_bridge=true
и
api_hangup_hook=lua app.lua hangup
Нафига? В чем был тайный смысл? Почему нельзя было поставить hangup_after = false и уже в app.lua failure_handler сделать нужные проверки?
А во вторых - продолжаю скрещивать Fusion с Bitrix. Чтобы информация о звонках, прошедших через fusion прилетала в bitrix. И вот возник такой вопрос. Вариант первый - сесть на events с помощью LUA handler. Минус - вариант не сильно понятен не слишком продвинутому админу. Вариант второй - все таки делать вставки в диалплан fusion. И вот тут, начав с ним детально разбираться, не совсем понял зачем так сделано. А именно - есть у них ext под названием local_extension, где стоит:
hangup_after_bridge=true
и
api_hangup_hook=lua app.lua hangup
Нафига? В чем был тайный смысл? Почему нельзя было поставить hangup_after = false и уже в app.lua failure_handler сделать нужные проверки?
Были и такие и такие варианты. В смысле в разных версиях. По какой-то причине именно через api оказался более надежным. Я подозреваю, что в разного рода сценариях.
BK
но правды, чую, ни когда не узнаем
ладно, тут столкнулся с другой проблемой
оказывается и A и B ноги шлют независымые события
а есть какое-то поле и переменная, по которой можно их связать? Что-то вроде session_uuid какой-нибудь? А то пока не могу найти, ни один id не совпадает
ладно, тут столкнулся с другой проблемой
оказывается и A и B ноги шлют независымые события
а есть какое-то поле и переменная, по которой можно их связать? Что-то вроде session_uuid какой-нибудь? А то пока не могу найти, ни один id не совпадает
IO
Кстати именно для таких вещей я дописал возможность делать коллбэки из обработчика CDR.
BK
Такс, ну ка с этого места подробнее
IO
У меня свой форк :)
BK
печально.... свой форк плодить уж точно не хочется
IO
Марк ну очень тугой на приём патчей
BK
это да... логика некоторых вещей у него конечно удивляет
IO
но правды, чую, ни когда не узнаем
ладно, тут столкнулся с другой проблемой
оказывается и A и B ноги шлют независымые события
а есть какое-то поле и переменная, по которой можно их связать? Что-то вроде session_uuid какой-нибудь? А то пока не могу найти, ни один id не совпадает
ладно, тут столкнулся с другой проблемой
оказывается и A и B ноги шлют независымые события
а есть какое-то поле и переменная, по которой можно их связать? Что-то вроде session_uuid какой-нибудь? А то пока не могу найти, ни один id не совпадает
Посмотрите uuids
IO
И bridge_uuid
BK
увы, в событии hangup_complete его нет
BK
но вы меня навели на мысль, я правильно понимаю, что на каждый звонок он вызывает /var/www/fusionpbx/app/xml_cdr/v_xml_cdr_import.php ?
IO
Да.
АХ
Ребята, во-первых с наступающим/пившим
А во вторых - продолжаю скрещивать Fusion с Bitrix. Чтобы информация о звонках, прошедших через fusion прилетала в bitrix. И вот возник такой вопрос. Вариант первый - сесть на events с помощью LUA handler. Минус - вариант не сильно понятен не слишком продвинутому админу. Вариант второй - все таки делать вставки в диалплан fusion. И вот тут, начав с ним детально разбираться, не совсем понял зачем так сделано. А именно - есть у них ext под названием local_extension, где стоит:
hangup_after_bridge=true
и
api_hangup_hook=lua app.lua hangup
Нафига? В чем был тайный смысл? Почему нельзя было поставить hangup_after = false и уже в app.lua failure_handler сделать нужные проверки?
А во вторых - продолжаю скрещивать Fusion с Bitrix. Чтобы информация о звонках, прошедших через fusion прилетала в bitrix. И вот возник такой вопрос. Вариант первый - сесть на events с помощью LUA handler. Минус - вариант не сильно понятен не слишком продвинутому админу. Вариант второй - все таки делать вставки в диалплан fusion. И вот тут, начав с ним детально разбираться, не совсем понял зачем так сделано. А именно - есть у них ext под названием local_extension, где стоит:
hangup_after_bridge=true
и
api_hangup_hook=lua app.lua hangup
Нафига? В чем был тайный смысл? Почему нельзя было поставить hangup_after = false и уже в app.lua failure_handler сделать нужные проверки?
если не ошибаюсь, второй вариант не проканает если абонента А первый положит трубку.
нужно zombie exec вешать на канал
нужно zombie exec вешать на канал
АХ
если абонент А положит трубку - больше некому идти по диалплану. поэтому вешается хук
BK
Ага, понятно
Спасибо всем, цели на завтра ясны. Пойду спать :)
Спасибо всем, цели на завтра ясны. Пойду спать :)