Там есть биндинги.

Нужно что бы при событии писались данные в скуль.

В скрипте, который из диал-плана аызывпется можешь consumer создать.

mod_event_socket поддерживает подписку и фильтрацию EventConsumer только подписку

Сэмпл смотрел, ничего не понял, ткните пожалуйста пальцем куда смотреть

odbc включай

У меня postgres

Для postge тоже есть odbc

В скрипте, который из диал-плана аызывпется можешь consumer создать.

Это зачем?

Как в базу писать это я знаю. Интересует именно инициация этой этой записи

Как можно стартануть запись при событии.

Я ж не знаю, как у человека сделано что уже. Поэтому все вприантв озвучиваю.

В какой момент и какую информацию нужно записать?

Каком?

При окончании звонка

Нужно данные этого звонка писать в базу, ну и при отмене звонка или трансфере его.

api_hangup_hook самый простой способ

Ну. Если событие хочется, то CHANNEL HANGUP COMPLETE

api_hangup_hook самый простой способ

Уже двигаюсь в этом направлении, заинтересовали подписки на события

Ну. Если событие хочется, то CHANNEL HANGUP COMPLETE

Думаю это то что надо. Спасибо, пойду дальше курить

<configuration name="lua.conf" description="LUA Configuration"> <settings> <hook event="CHANNEL_HANGUP_COMPLETE" script=myhook.lua"/> </settings> </configuration>

Но событие другое и скрипт тоже.

https://wiki.freeswitch.org/wiki/Event_List#CHANNEL_HANGUP_COMPLETE

Можно например запустить luarun скрип c EventConsumer для одного канала :)

На самом деле можно придумать достаточно много вариантов обработки CDR

Вариантов масса

mod_cdr_odbc собрать

Был такой, как мне помнится

не доверяю я экранированию в подобных модулях

cdr_xml и через middleware

radius

fail2ban + isql :)

Но я думаю xml_cdr или Lua реализация на hangup hook вполне достаточно

На Lua только желательно предусматреть повторну отправку в случае ошибки

Можно поподробнее про подписку, я похоже велосипед изобретаю

if (event:getHeader("Event-Name") == "CHANNEL_ANSWER") then

Нужно что бы при событии писались данные в скуль.

только не вздумай это писать из скрипта, хуки однопоточные. Вариант - освой mod_ampq

При окончании звонка

CHANNEL_HANGUP

https://github.com/fusionpbx/fusionpbx/blob/master/resources/install/scripts/app/voicemail/resources/scripts/mwi_subscribe.lua#L85-L126

<configuration name="lua.conf" description="LUA Configuration"> <settings> <hook event="CHANNEL_HANGUP_COMPLETE" script=myhook.lua"/> </settings> </configuration>

мы на CHANNEL_HANGUP подписываемся

Запускаеш отдельным потоком через luarun и далее обрабатываешь событие CHANNEL_HANGUP или любое какое захочешь

а чем кролик не?

Главное чтобы скрипт успевал обрабатывать поток событий. Например если бд недоступна не очень желательно прекращать чтение событий Лучше вычитывать их и далее сохранять например в файле как это делает xml_cdr

в очереди rabbitmq с контролем успешности записи..

пост - там будет норм

а если rabbitmq недоступен :) ?

да, тоже этого опасаюсь

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

а что иногда будет тупить - уверенность.

а если rabbitmq недоступен :) ?

но можно добавить restart=always в сервис-файл.. )

Можно и на redis очередь локальную использовать

лишь бы место не кончилось

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

Если будет недоступен то можно в кэш скидывать

только не вздумай это писать из скрипта, хуки однопоточные. Вариант - освой mod_ampq

не нашел инфы по mod_ampq, не подкинете ссылочек?

https://freeswitch.org/confluence/display/FREESWITCH/mod_amqp

https://freeswitch.org/confluence/display/FREESWITCH/mod_amqp

Ну и как всегда исходиники :)

Ну и как всегда исходиники :)

в исходниках я плохо ориентируюсь

в чем различие CHANNEL_HANGUP и CHANNEL_HANGUP_COMPLETE

Одно до формирования финальных данных, попадающих в CDR, другое после.

Это как разница между BEGIN и END.

там есть еще REPORTING события вроде

CS_REPORTING есть, это подстадия.

Одно событие, другое состояние.

Тонкий момент.

В одном состоянии может быть несколько событий.

https://freeswitch.org/confluence/display/FREESWITCH/mod_amqp

хммм.. странно искал через поиск, не нашлось

xml_cdr использует on_reportning в котором написано /*! executed when the state changes to reporting */

Ещё раз говорю: есть события, а есть состояния канала.

И вызовы внутреннего API FreeSwitch на уровне C не всегда совпадают с событиями.

Так это понятно. Просто как отловить этот переход состояния. Ну и можно экспортировать этот API в Lua и обрабатывать callbacks :)

mod_managed похоже дает доступ к этому API

А я не очень понимаю, чем CHANNEL_HANGUP_COMPLETE не устраивает? Все переменные, сформированные за время жизни канала доступны и уже не будут меняться.

Простая проверка заголовка на CS_REPORTING и выполнение всех необходимых операций.

У меня так и делает во многих местах. Там, правда Perl через ELS сбоку, но это сути не меняет. Я в то время с LUA ещё не подружился.

какие варианты еще есть помимо mod_amqp, для записи в скуль потока данных

Формировать SQL файлы через mod_cdr_csv и скриптом их гурзить по крону. Надёжно как танк.

Есть 2 части. Получение набора данных для записи и далее запись этих данных Первая часть может быть через файлы (cdr_csv) http сервер xml_cdr Inbound ESL connection, EventConsumer

После того как определишься с первой частью можно думать над второй

FusionPBX использует PHP PDO для записи CDR

Коллеги, что не так со строкой bgapi originate {execute_on_answer='sched_hangup +120 alloted_timeout'}sofia/internal/service@192.168.100.74:5080 &playback(/usr/share/freeswitch/sounds/music/8000/danza-espanola-op-37-h-142-xii-arabesca.wav)

молчит как убитый

в логах говорит, что проигрывает звонок: EXECUTE sofia/internal/service@192.168.100.74:5080 playback(/usr/share/freeswitch/sounds/music/8000/danza-espanola-op-37-h-142-xii-arabesca.wav)

Не идёт звук в сторону вызываемого абонента?

да, музыка не играет

сам файл слышал, в нем все ок, музыка есть

А что в 200 OK от него?

А трафик на то, что там в 200 OK указано идёт?

INVITE sip:service@192.168.100.74:5080 SIP/2.0 Via: SIP/2.0/UDP 192.168.100.106;rport;branch=z9hG4bKp020e5U7QcyNH Max-Forwards: 70 From: "" <sip:0000000000@192.168.100.106>;tag=F1B1j870y65vN To: <sip:service@192.168.100.74:5080> Call-ID: dc13c5a5-22e4-1236-23b3-5cb901c86de0 CSeq: 113183293 INVITE Contact: <sip:mod_sofia@192.168.100.106:5060> User-Agent: FreeSWITCH-mod_sofia/1.6.19-36-7a77e0b~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 274 X-FS-Support: update_display,send_info Remote-Party-ID: <sip:0000000000@192.168.100.106>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1507009975 1507009976 IN IP4 192.168.100.106 s=FreeSWITCH c=IN IP4 192.168.100.106 t=0 0 m=audio 28740 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.100.106;rport=5060;branch=z9hG4bKp020e5U7QcyNH From: "" <sip:0000000000@192.168.100.106>;tag=F1B1j870y65vN To: <sip:service@192.168.100.74:5080>;tag=XcFc0S04jaDFN Call-ID: dc13c5a5-22e4-1236-23b3-5cb901c86de0 CSeq: 113183293 INVITE Contact: <sip:service@192.168.100.74:5080;transport=udp> User-Agent: SoftSWITCH/1.6.13 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 248 X-FS-Display-Name: service X-FS-Display-Number: sip:service@192.168.100.74 X-FS-Support: update_display,send_info Remote-Party-ID: "service" <sip:service@192.168.100.74>;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1507016217 1507016218 IN IP4 192.168.100.74 s=FreeSWITCH c=IN IP4 192.168.100.74 t=0 0 m=audio 22668 RTP/AVP 0 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20

по-моему, все хорошо

там никаких натов, ничего нету, чистая коммутация между двумя соседними подсетями

Да. они в одной сети.

ртп-поток даже есть

не, в соседних, там маска /27, но это не принципиально

Смотри на принимающей стороне.

a sched_hangup это точно application а не api ?