собственно кейс
[macro-check]
exten =>s,1,wait(100); делаем тут чтото, неважно что
[dialout_1]
exten => s,1,Dial(dahdi/g0/12345,,M(check)); on call macro
[dialout_2]
exten => 1,1,Dial(local/s@dialout_1/n)
теперь если позвонить например с sip/test на 1 в последнем контексте и положить трубку ПОСЛЕ того как будет отвечена dahdi линия - то положется канал SIP/test-xxx, а все остальные останутся висеть до тех пор, пока не отработает on-call-macro.
вопрос - чего поменяли и где. в 1.6 не наблюдается.
Задан: Jul 24 '15
Просмотрен: 211 раз
Обновлен: Jul 24 '15
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
Ответа на вопрос не знаю. Могу тока констатировать что с M что с U на 1.8 такое же поведение. Столкнулся с этим когда реализовывал отправку диагностики по клиенту оператору ТП. В моем случае вызывался php скрипт и собственно пока он не заканчивал свою работу, то у вызывающего гудки, а у сотрудника тишина и даже если вызывающий положит трубу, то линия сотрудника (SIP) продолжает висеть. Много чего пробовал, в том числе и FORK, но ничего не помогало. Удалось победить такое поведение только тогда когда в скрипте, который вызывается диалпланом, стали вызывать второй скрипт (который уже и делал то что мне надо) с отвязкой stdin и stderr при вызове exec, а так же пустили его работать в background`е. Таким образом "родитель" сразу завершает свою работу и отпускает dialplan, а потомок продолжает работать. Посему как вариант в macro-check вызывать скрипт, который совать в background и уже в нем делать что нужно. Тогда оба канала не будут зависеть от скрипта, но скрипт продолжит свою работу даже если повесят трубку.
virus_net (Jul 24 '15)editне, ну это понятно. в моем случае макрос детектит сигнализацию аналоговой линии с которой dadhi не справляетя(проседают сигналы). его в бекгранд не засунешь.
meral (Jul 24 '15)edit