[sub-record]
exten => s,1,NoOP(Запись разговора)
same  =>   n,NoOP(${CALLERID(num)})
same  =>   n,Set(MONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y/%m/%d)}/${STRFTIME(${EPOCH},,%H-%M-%S)}-${CALLERID(num)}-${EXTEN}-${CDR(uniqueid)}.wav)
same  =>   n,MixMonitor(${MONITOR_FILENAME},b)
same  =>   n,NoOP(${MONITOR_FILENAME})
same  =>   n,Set(CDR(records)=${CALLERID(num)}-${EXTEN}-${CDR(uniqueid)}.wav)
same  =>   n,Return()
[default]
exten => _5XXXXXXXXXX,1,Answer()
same  => n,GoSub(sub-record,s,1)
same => n,Playback(/var/spool/asterisk/monitor/321)
same => n,Dial(SIP/8${EXTEN:1}@teleset_505,,A(/var/spool/asterisk/monitor/321))
same => n,Hangup()

были попытки  тоже не работает

Макрос в параметрах Dial нужно указать.
Пример: https://www.voip-info.org/asterisk-cmd-dial/#Dialmacros

опция u через gosub, ну или hangup handlers почитать можно

@ipoddubny @dyermakov Доброго вечера.
Я всё ещё периодически тщетно пытаюсь поймать причину потери TLS соединий. Может кто-то помочь? :)
Сейчас теория такая... что соединения "пропадает" при выполнении "pjsip reload", который:
pjsip reload=module reload res_pjsip.so res_pjsip_authenticator_digest.so res_pjsip_endpoint_identifier_ip.so res_pjsip_mwi.so res_pjsip_notify.so res_pjsip_outbound_publish.so res_pjsip_publish_asterisk.so res_pjsip_outbound_registration.so

Если откликнитесь.. чуть деталей добавлю

Доброго. Я могу на выходных посмотреть, после работы опять ковыряться в астериске невмоготу.

как я это понимаю :( Я после работы вообще компьютер видет уже не могу :(

спасибо. Я побольше информации соберу до выходных.. если она подтвердится, то обращусь...

Всем привет! Никто не встречался с ситуацией, когда в стандартной mysql таблице cdr после звонка остается только одна запись(а должно быть много, звонок попадает в queue, долго там болтается, далее к оператору, разговор и разрыв коммутации), и у этой записи время end = времени start, хотя по факту звонок был ненулевой. Астер 15.1.2.

В консоли звонок абсолютно нормальный. Вот часть лога из консоли:
[2019-01-29 08:06:27] VERBOSE[11616][C-00007402] netsock2.c: Using SIP RTP TOS bits 184
[2019-01-29 08:06:27] VERBOSE[11616][C-00007402] netsock2.c: Using SIP RTP CoS mark 5
[2019-01-29 08:06:27] VERBOSE[10663][C-00007402] pbx_lua.c: Executing [XXXXX@from-trunk:1] answer("SIP/xxx-00011f6a", "")
.
.
.
[2019-01-29 08:43:29] VERBOSE[10663][C-00007402] app_queue.c: SIP/XXXXX-0001244b is ringing
[2019-01-29 08:43:31] VERBOSE[10663][C-00007402] app_queue.c: SIP/XXXX-0001244b answered SIP/XXX-00011f6a
.
.
[2019-01-29 08:46:07] VERBOSE[10663][C-00007402] pbx_lua.c: Executing [XXX@from-trunk:1] hangup("SIP/XXX-00011f6a", "")


Под этот "баг" попали подряд несколько звонков в течение 10 минут. Гуглением похожих багов не нашел.
ЦП, памяти и iops с большим запасом.

А еще сами cdr иногда выкладываются с некоторой задержкой - это нормально?

А если писать в файл. Будет тогда не причём mysql и информация для размышления.

В настройках очереди есть параметр, не писать не отвеченные.

Да и не будет несколько записей,  если очередь не через local channel - но это не точно

Ну это же не решение проблемы). Костыль я уже написал, теперь cdr вытаскиваю позже и date_end высчитываю по-другому.

У меня напрямую вызывается Queue сразу во входящем звонке, без local channel

Это не костыль. Это дебаг, где проблема )

Большое спасибо @ipoddubny за неоценимую помощь в локализации бага с TLS в астериске...

После этого выяснилось дополнительно..

Клиент PhonerLite имеет забавную багу.
Я настроил на TLS, но если ноут уходит в хибернейт и возвращается... то клиент переключается на UDP.
Отправил багрепорт автору.
Но не это самое забавное... а то, что Asterisk на этот REGISTER в UDP начинает отвечать и идёт успешный обмен... Клиент считает что он успешно зарегистрировался.
Вот только... астериск так не считает и оставляет AOR в Unavailable.

Печалька.. в manager.conf нет возможности указать часовой пояс пользователя

а надо доступ по часам ?)

нет.. у меня сервер crm работает с многими АТС через AMI.. и получает CDR события. И... астериски в разных часовых поясах