LINUX.ORG.RU
решено ФорумAdmin

Поймать UNIQUEID если не было соединения каналов

 


0

1

Внешнее приложение дергает скрипт, который создает SQL запись в талице

INSERT INTO informer (date, jobid) VALUES ('now()', <jobid>);
Далее скрипт оригинирует звонок на asterisk передавая
...
Context: informer
Variable: jobid=<jobid>
...

Далее принимающий контекст добавляет UNIQUEID в базу

[informer]
exten => s,1,Answer
exten => s,n,Set(INFORMER_UPDATE_UNIQUEID(${jobid})=${UNIQUEID})
...

Если абонент снял трубку то все хорошо каналы соеденились и астериск начал выполнять контекст [informer], но если каналы не соеденились (абонент сбросил) то контекcт не выполняется и обновление базы не происходит.

Что можно придумать?

★★★★★

Последнее исправление: petav (всего исправлений: 1)

Если правильно помню, если дозвона не случилось, то в контекст всё-равно пойдет, только по другому экстену(то ли h, то ли ещё другое). Подключитесь AMI посмотрите что он выдаст из событий. А вообще, лог включать надо полный и смотреть на потроха в таких случаях.

FeyFre ★★★★
()
Ответ на: комментарий от petav

AMI нотификация точно приходит если коннекта небыло. Я хз как вы дозвон заводите(pbx_spool, али собственный комбайн?), я через AMI пинал дозвон, следил за результатом: либо в контекст попадало, либо всё плохо и я тоже это видел(вот не помню чем: только AMI или в контексте что было). Только опять таки: не успешный дозвон, нет канала - зачем тогда uid? Чем управлять то?

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

AMI нотификация точно приходит если коннекта небыло.

Да, приходит

Я хз как вы дозвон заводите

см. постановку вопроса.

petav ★★★★★
() автор топика
Ответ на: комментарий от kernelpanic

local каналы

Да, один из вариантов, логику убрать в local канал. Приоритетный.

Второй ожидать в AMI, но ждать приходится долго, пока дозвонится, пока сбросит и в это время скрипт не завершить, ответвлять его в дочерние процессы, необоснованно кол-во кода увеличит.

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

см. постановку вопроса.

Начать звонок можно 4 способами(из тех что я помню), из них 2 только подходят под описание:
1. /var/spool/asterisk/ положить файлки с описанием
2. Пнуть команду Originate через AMI
*2 остальные: начать дозвон из существующего канала и cli команду originate явно не ваш случай
В любом случае, через AMI повалит куча ивентов. Но я так понимаю управление AMI - не тот случай.
Вот что пишет voip-info

If the call is not answered, and the standard extension failed with priority 1 exists in the same context, control will jump there

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

В функционале используется оригинация (через ami) локального канала и екстеншина. Ошибка при проектировании была в том, что екстеншен к каналу подключается только после того как в канале поднимут трубку. А в екстеншене часть логики размещена, котолрая должна срабатывать когда трубку не подняли

Решение проблемы переместить логику в канал локальный

Channel: Channel on which to originate the call (The same as you specify in the Dial application command) Context: Context to use on connect (must use Exten & Priority with it) Exten: Extension to use on connect (must use Context & Priority with it)

(с) Asterisk Manager API Action Originate

Который всегда выполняется. Это единственный вариант приемлемый для асинхронного взаимодействия скрипта и станции. Можно анализировать ami (там вся информация есть), но это задерживает постановку задачи станции.

Других вариантов (которые я хотел услышать) наверное больше не существует, перенесу логику в локальный канал.

petav ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.