не хочется а придется, ари не для этих целей

можно фильтровать по классам событий еще

Самый простой способ, который знаю, - ловить событие NewConnectedLine. Должно быть в момент ответа и в ConnectedLineNum будет номер ответившего.

Если нужно что-то более сложное/точное, придётся отслеживать с каким каналом звонящий соединяется через промежуточные Local-каналы (по крайней мере сам не нашёл более простого решения).

ну и никто не отменять просто скипать не нужные события в своем скрипте

это всё замечательно, но как узнать инфу если  оно было ДО запуска скрипта?

Как написал Роман, нужен демон, который будет постоянно подключен к AMI.

ну, я запускаю скрипт раз в минуту по крону
он проверяет - и если уже подключен то просто новый не запускается
но бывает что на АТС нет вызовов (ночь к примеру) и скрипт по тайматут отключается
тогда есть шанс пропустить часть инфы

скрипт запускается один раз при загрузке системы и работает, все, это основная концепция.

В скрипте бесконечный цикл который получает инфу из ами. Получаешь ее, обрабатываешь и что-то делаешь

коллеги, редактирую контекст, делаю dialplan reload, но ничего не меняется. Куда копать?

Где не меняется? В жизни?

dialplan show

чем проверяли, как сравнивали?
чистый астер или freepbx?
какой файл правили?

Добрый,
нужна помощь (за денюжку) связка UCM6102 —> Mikrotik (L2TP client) —> Ubuntu ((L2TP server) and (OPENVPN server)) -> FREEPBX (Asterisk 16) (OPENVP client).
Звонок приходит а голоса нету, NAT'а по дороге нету. Готов заплатить, за подсказку.
Кому интересно в ЛС.

ael reload

уже подсказали добрые люди в соседнем чяти

я заметил

у меня очередной вопрос про запись разговоров, но в этот раз скорее про область видимости переменных канала...
итак, сложная ситауция с callback
всё сделано и работет по "учебнкику"
а именно, создаётся call файл, который сначала звоник абоненту А, тот отвечает, ему играет привестствие и идёт вызов абоненту Б...
упрощённо call файл:
Originate: Local/<numA>@contextstart
Context: contextcallback
Extension: <numB>

упрощённо контексты
contextstart:
__recfile=.....
MixMonitor(recfile...)
Dial(..<numA>)
HangUp

contextcallback:
Answer
Playback
ExecIf( "recfile" = "" ) ... __recfile ... & MixMonitor
Dial( ..<numB>)

так вот, в этой конструкции получается 2 записи, т.к. не смотря на два подчёркивания в contextstart  у recfile, в contextcallback эта переменная неизвестна и заново создаётся

это пример, тут вопрос про то что во втором плече ничего не известно про переменные первого плеча
как то побороть это можно ?

на вскидку можно попробовать обойти. например
1)создавать переменные в call файле
2)у вас это local каналы и они будут отличаться одной циферкой ;1 ;2, т.е. можно вычислить второй и использовать SHARED()

Всем привет. Некоторое время назад обсуждали допустимый процент потерь RTP. Тут от 0.5 до 5% цифры были.  Просто потери есть в районе 2%. В МТТ говорят иди к провайдеру, провайдер говорит - мы не виноваты такое случается. Так вот, какой процент всё же допустим? Можно ли сослаться на что-то чтобы прижать провайдера?

считается допустимой нормой потери RTP до 3% (тогда речь будет, более менее комфортной), джиттер не должен превышать 150мс

так же имеет значение кодеки, и джиттер-буфер