Good day, community!
I encountered an issue while working with call queues in Asterisk and need your help.
Here’s the situation: I’m using the Queue() function to handle incoming calls. The agent call strategy in the queue is set to ringall.
Here’s a snippet of my dial plan:
exten => 2,1,Playback(/var/lib/asterisk/sounds/custom/ACH_RecInfo)
same => n,Set(CDR(dstdep)=ach-service)
same => n,Set(_QueueVar=ach-service)
same => n,Queue(ach-service)
same => n,ExecIf($[${QUEUESTATUS}=JOINEMPTY]?Playback(/var/lib/asterisk/sounds/custom/ACH_QueueMessageEmpty))
same => n,ExecIf($[${QUEUESTATUS}=LEAVEEMPTY]?Playback(/var/lib/asterisk/sounds/custom/ACH_QueueMessageEmpty))
same => n,Hangup()
After the call is disconnected, the call handling moves to the h context:
exten => h,1,System(/etc/asterisk/lame-mp3-audio-encoding-separate.sh "external" "${STRFTIME(,,%Y)}" "${STRFTIME(,,%m)}" "${STRFTIME(,,%d)}" "${CHANNEL(uniqueid)}")
same => n,NoOp(${STAT(e,/var/spool/asterisk/monitor/${MONITOR_FILENAME}.mp3)})
same => n,ExecIf($["${STAT(e,/var/spool/asterisk/monitor/${MONITOR_FILENAME}.mp3)}" = "1"]?MSet(CDR(recording)=${MONITOR_FILENAME}.mp3,CDR(filename)=/var/spool/asterisk/monitor/${MONITOR_FILENAME}.mp3))
same => n,NoOp(Value of the 1st variable CDR(dstchannel): ${CDR(dstchannel)} )
same => n,NoOp(Value of the 2nd variable CDR(dstdep): ${CDR(dstdep)} )
same => n,NoOp(Value of the 3rd variable CALLERID(num): ${CALLERID(num)} )
same => n,NoOp(Value of the 4th variable CDR(start): ${CDR(start)})
same => n,NoOp(Value of the 5th variable QUEUESTATUS: ${QUEUESTATUS})
same => n,NoOp(Value of the 6th variable QueueVar: ${QueueVar})
same => n,NoOp(Value of the 7th variable CDR(dcontext): ${CDR(dcontext)})
same => n,NoOp(Value of the 8th variable CDR(disposition): ${CDR(disposition)})
same => n,NoOp(Value of the 9th variable The customer calls the number InNum: ${InNum})
same => n,System(/etc/asterisk/send_message_call_no_answer_callback.sh "${CDR(dstchannel)}" "${CDR(dstdep)}" "${CALLERID(num)}" "${CDR(start)}" "${QUEUESTATUS}" "${QueueVar}" "${CDR(dcontext)}" "${CDR(disposition)}" "${InNum}")
If there’s more than one agent registered in the queue, and given the ringall strategy, all available agents are called simultaneously. For example, if there are three free agents in the queue and one of them answers, the CDR will record three entries—two with NO ANSWER disposition and one with ANSWERED.
Here’s an example of such CDR entries:
| Id | accountcode | src | dst | dcontext | clid | channel | dstchannel | last | last | start | answer | end | duration | billsec | disposition | amaflags | userfield | uniqueid | linkedid | peeraccount | sequence | recording | filename | innum | dstdep | company |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 58873 | \N | 7100 | 2 | ach-open | “” <7100> | PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000005 | PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000006 | Queue | ach-service | 2024-12-24 17:28:57 | 2024-12-24 17:28:59 | 2024-12-24 17:29:24 | 27 | 25 | NO ANSWER | DOCUMENTATION | \N | 1735054137.33 | 1735054137.33 | \N | 7 | \N | \N | 33 | ach-service | ach |
| 58875 | \N | 7100 | 2 | ach-open | “” <7100> | PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000005 | PJSIP/KV-KYI-ACH-W007-SOFT-7101-00000008 | Queue | ach-service | 2024-12-24 17:29:22 | 2024-12-24 17:29:22 | 2024-12-24 17:29:24 | 2 | 2 | NO ANSWER | DOCUMENTATION | \N | 1735054137.33 | 1735054137.33 | \N | 12 | external/2024/12/24/1735054137.33.mp3 | /var/spool/asterisk/monitor/external/2024/12/24/1735054137.33.mp3 | 33 | ach-service | ach |
| 58874 | \N | 7100 | 2 | ach-open | “” <7100> | PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000005 | PJSIP/KV-KYI-ACH-W032-SOFT-7102-00000007 | Queue | ach-service | 2024-12-24 17:29:22 | 2024-12-24 17:29:22 | 2024-12-24 17:29:33 | 11 | 11 | ANSWERED | DOCUMENTATION | \N | 1735054137.33 | 1735054137.33 | \N | 10 | \N | \N | 33 | ach-service | ach |
However, when the call transitions to the h context, the value of ${CDR(disposition)} after either the caller or agent hangs up is NO ANSWER. Consequently, the script that sends an email about missed calls incorrectly considers these answered calls as missed, leading to false notifications.
Here’s the CLI call log showing that one of the agents answered, but the ${CDR(disposition)} variable still holds the NO ANSWER value:
-- Executing [33@sets:1] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "_InNum=33") in new stack
-- Executing [33@sets:2] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "User Dialed 33") in new stack
-- Executing [33@sets:3] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "CDR(company)=ach") in new stack
-- Executing [33@sets:4] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "CDR(innum)=33") in new stack
-- Executing [33@sets:5] GotoIfTime("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "*,*,1,jan?ach-holiday-new-year,s,1") in new stack
-- Executing [33@sets:6] GotoIfTime("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "00:00-23:59,mon-sun,*,*?ach-open,s,1") in new stack
-- Goto (ach-open,s,1)
-- Executing [s@ach-open:1] Progress("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "") in new stack
-- Executing [s@ach-open:2] Wait("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "2") in new stack
> 0x7f1468017860 -- Strict RTP learning after remote address set to: 192.168.164.135:4004
> 0x7f1468017860 -- Strict RTP switching to RTP target address 192.168.164.135:4004 as source
-- Executing [s@ach-open:3] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "MONITOR_FILENAME=external/2025/01/07/1736262240.144") in new stack
-- Executing [s@ach-open:4] Playback("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "/var/lib/asterisk/sounds/custom/ACH_Welcome") in new stack
-- <PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016> Playing '/var/lib/asterisk/sounds/custom/ACH_Welcome.slin' (language 'ru')
> 0x7f1468017860 -- Strict RTP learning complete - Locking on source address 192.168.164.135:4004
-- Executing [s@ach-open:5] BackGround("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "/var/lib/asterisk/sounds/custom/ACH_MenuDay") in new stack
-- <PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016> Playing '/var/lib/asterisk/sounds/custom/ACH_MenuDay.slin' (language 'ru')
[Jan 7 17:04:11] DTMF[59698][C-00000008]: channel.c:4019 __ast_read: DTMF begin '2' received on PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
[Jan 7 17:04:11] DTMF[59698][C-00000008]: channel.c:4023 __ast_read: DTMF begin ignored '2' on PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
[Jan 7 17:04:11] DTMF[59698][C-00000008]: channel.c:3905 __ast_read: DTMF end '2' received on PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016, duration 200 ms
[Jan 7 17:04:11] DTMF[59698][C-00000008]: channel.c:3994 __ast_read: DTMF end passthrough '2' on PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- Executing [2@ach-open:1] Playback("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "/var/lib/asterisk/sounds/custom/ACH_RecInfo") in new stack
-- <PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016> Playing '/var/lib/asterisk/sounds/custom/ACH_RecInfo.slin' (language 'ru')
-- Executing [2@ach-open:2] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "CDR(dstdep)=ach-service") in new stack
-- Executing [2@ach-open:3] Set("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "_QueueVar=ach-service") in new stack
-- Executing [2@ach-open:4] Queue("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "ach-service") in new stack
-- Started music on hold, class 'default', on channel 'PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016'
-- Called PJSIP/KV-KYI-ACH-S001-SOFT-7104
-- Called PJSIP/KV-KYI-ACH-W032-SOFT-7102
-- Called PJSIP/KV-KYI-ACH-W007-SOFT-7101
-- PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000017 connected line has changed. Saving it until answer for PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- PJSIP/KV-KYI-ACH-W032-SOFT-7102-00000018 connected line has changed. Saving it until answer for PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- PJSIP/KV-KYI-ACH-W007-SOFT-7101-00000019 connected line has changed. Saving it until answer for PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000017 is ringing
-- PJSIP/KV-KYI-ACH-W032-SOFT-7102-00000018 is ringing
-- PJSIP/KV-KYI-ACH-W007-SOFT-7101-00000019 is ringing
> 0x7f14680315d0 -- Strict RTP learning after remote address set to: 192.168.164.135:4008
-- PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000017 answered PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- Stopped music on hold on PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
== Begin MixMonitor Recording PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
-- Channel PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000017 joined 'simple_bridge' basic-bridge <552b0a4e-5f73-47b7-907d-139a89051e8d>
-- Channel PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016 joined 'simple_bridge' basic-bridge <552b0a4e-5f73-47b7-907d-139a89051e8d>
> 0x7f14680315d0 -- Strict RTP switching to RTP target address 192.168.164.135:4008 as source
> 0x7f14680315d0 -- Strict RTP learning complete - Locking on source address 192.168.164.135:4008
-- Channel PJSIP/KV-KYI-ACH-S001-SOFT-7104-00000017 left 'simple_bridge' basic-bridge <552b0a4e-5f73-47b7-907d-139a89051e8d>
-- Channel PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016 left 'simple_bridge' basic-bridge <552b0a4e-5f73-47b7-907d-139a89051e8d>
== Spawn extension (ach-open, 2, 4) exited non-zero on 'PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016'
-- Executing [h@ach-open:1] System("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "/etc/asterisk/lame-mp3-audio-encoding-separate.sh "external" "2025" "01" "07" "1736262240.144"") in new stack
-- Executing [h@ach-open:2] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "1") in new stack
-- Executing [h@ach-open:3] ExecIf("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "1?MSet(CDR(recording)=external/2025/01/07/1736262240.144.mp3,CDR(filename)=/var/spool/asterisk/monitor/external/2025/01/07/1736262240.144.mp3)") in new stack
-- Executing [h@ach-open:4] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 1st variable CDR(dstchannel): PJSIP/KV-KYI-ACH-W007-SOFT-7101-00000019 ") in new stack
-- Executing [h@ach-open:5] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 2nd variable CDR(dstdep): ach-service ") in new stack
-- Executing [h@ach-open:6] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 3rd variable CALLERID(num): 7100 ") in new stack
-- Executing [h@ach-open:7] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 4th variable CDR(start): 2025-01-07 17:04:17") in new stack
-- Executing [h@ach-open:8] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 5th variable QUEUESTATUS: ") in new stack
-- Executing [h@ach-open:9] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 6th variable QueueVar: ach-service") in new stack
-- Executing [h@ach-open:10] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 7th variable CDR(dcontext): ach-open") in new stack
-- Executing [h@ach-open:11] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 8th variable CDR(disposition): NO ANSWER") in new stack
-- Executing [h@ach-open:12] NoOp("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "Value of the 9th variable The customer calls the number InNum: 33") in new stack
-- Executing [h@ach-open:13] System("PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016", "/etc/asterisk/send_message_call_no_answer_callback.sh "PJSIP/KV-KYI-ACH-W007-SOFT-7101-00000019" "ach-service" "7100" "2025-01-07 17:04:17" "" "ach-service" "ach-open" "NO ANSWER" "33"") in new stack
== MixMonitor close filestream (mixed)
== End MixMonitor Recording PJSIP/KV-KYI-ACH-W007-SOFT-7100-00000016
I would appreciate any guidance on why this happens and how to ensure ${CDR(disposition)} reflects the actual status of the call.
Thank you in advance!