Queue - Call completed elsewhere

Hello,

Is a normal behavior for Asterisk to send <Reason: SIP;cause=200;text="Call completed elsewhere"> for unanswered calls? For example when I’m calling the Queue application with the following parameters:

Queue(“109,rtC,15”)

Asterisk is sending an INVITE to all members and if the caller is dropping the call, then Asterisk is sending Cancel with <Reason: SIP;cause=200;text=“Call completed elsewhere”> to all members, even if that call wasn’t answered at all:

-- Called SIP/11
 -- SIP/IE-11-0000bf55 connected line has changed. Saving it until answer for
-- SIP/IE-11-0000bf55 is ringing
== Spawn extension (macro-Queue, s, 23) exited non-zero on '' in macro 'Queue'

Shouldn’t Asterisk send just Cancel without any reason in case if the call wasn’t answered by any member from the queue?

What is the actual console output? You appear to be using Local channels, so that introduces a separate Dial which can itself change things.

No, it’s not a local channel, it’s a SIP Channel:

[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] pbx.c: [2019-12-02 16:25:40]     -- Executing [s@macro-Queue:23] Queue("SIP/INT-0000be8b", "11,rCt,,,120") in new stack
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP TOS bits 184
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP CoS mark 5
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- Called SIP/53
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP TOS bits 184
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP CoS mark 5
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- Called SIP/52
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP TOS bits 184
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP CoS mark 5
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- Called SIP/29
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP TOS bits 184
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] netsock2.c: [2019-12-02 16:25:40]   == Using SIP RTP CoS mark 5
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- Called SIP/28
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- SIP/28-0000be8f connected line has changed. Saving it until answer for SIP/INT-0000be8b
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- SIP/29-0000be8e connected line has changed. Saving it until answer for SIP/INT-0000be8b
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- SIP/52-0000be8d connected line has changed. Saving it until answer for SIP/INT-0000be8b
[2019-12-02 16:25:40] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:40]     -- SIP/53-0000be8c connected line has changed. Saving it until answer for SIP/INT-0000be8b
[2019-12-02 16:25:41] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:41]     -- SIP/28-0000be8f is ringing
[2019-12-02 16:25:41] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:41]     -- SIP/29-0000be8e is ringing
[2019-12-02 16:25:41] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:41]     -- SIP/52-0000be8d is ringing
[2019-12-02 16:25:41] VERBOSE[22204][C-00006173] app_queue.c: [2019-12-02 16:25:41]     -- SIP/53-0000be8c is ringing
[2019-12-02 16:25:44] VERBOSE[22204][C-00006173] app_macro.c: [2019-12-02 16:25:44]   == Spawn extension (macro-Queue, s, 23) exited non-zero on 'SIP/INT-0000be8b' in macro 'Queue'
[2019-12-02 16:25:44] VERBOSE[22204][C-00006173] pbx.c: [2019-12-02 16:25:44]   == Spawn extension (incoming, 123456789, 34) exited non-zero on 'SIP/INT-0000be8b'

Ah, your initial information made it seem that way. Nothing else springs to mind, but I would suggest in the future providing full information and log at the start to provide a clearer picture.

I suspect it is done that way to stop people complaining about missed calls being reported on the phone, given that the queue system can call and cancel several times before successfully delivering a call.

exactly

its an option available to queues as well as ring groups in freepbx

for example if a queue call rang a phone but that phone didn’t answer the call however another queue member did, no missed call is displayed (the phone needs to support this as well)

Yes, I agree, that’s normal behavior when the call is answered by any of the members. But what if the call is coming into the queue - and none of the members are answering that call? This is a missed call, and in a normal case, I suppose that Asterisk should just send CANCEL without any reason. Shouldn’t?

if now one answers it is set to be a missed call even if called again agent after timeout and answered

this is how I see it working in 13.26.0 asterisk version

there is a sip header setting calls as answered or not answered always if you want you could set it before the queueu

You have to use a capital C in the options when calling a queue

options

  • C - Mark all calls as “answered elsewhere” when cancelled.

Yes, that’s true. This option is set already <Queue(“109,rtC,15”)>, and Asterisk indeed is sending “Call completed elsewhere” header but the problem is that he is sending this header for all calls, no matter are they answered or not, I was expected to receive CANCEL with “Call completed elsewhere” just for answered calls. For abandoned calls, I expected to get a CANCEL message without a reason.

What if the caller abandoned their position during the playback of an announcement, or during the retry timeout?

As the call is not answered by any member, then I think the best option is to send CANCEL message without a reason.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.