Understanding Busy/No Answer Codes

Asterisk Asterisk General
1

Hello,

We have the following [high-level] call flow:

PSTN –> Queue1 –> Queue2 –> Voicemail

For some reason, the agent in Queue1 failed to answer after several tries, and I see Asterisk responded upstream with a BYE showing Reason: Q.850;cause=19 instead of continuing the call flow to Queue2.

Asterisk logs show:

[2025-09-11 15:49:50] VERBOSE[1467417][C-00002638] app_dial.c: Called PJSIP/6434_Connect/sip:okg36185@clientIP:5080
[2025-09-11 15:49:55] VERBOSE[1467417][C-00002638] app_dial.c: PJSIP/6434_Connect-0000518b is making progress passing it to PJSIP/Upstream-00005185
[2025-09-11 15:50:02] VERBOSE[1467417][C-00002638] app_dial.c: No one is available to answer at this time (2:0/0/1)

My questions:

  1. What exactly does (2:0/0/1) mean?
  2. Why was the call passed upstream and not continued to Queue2 in the dialplan?

Thank you.

2

number of channels dialed:number of channels busy:number of channels congested:number of channels that couldn’t be dialed

You would need to show the actual complete dialplan and complete log. As it is I see app_dial, which means a Local channel is also involved, so there’s multiple layers of dialplan involved.

3

Thank you, Josh!

See call trace: Failed Queue Call - Pastebin.com

Lines 0-24: cover the incoming trunk, setting tenant/global variables, time-based dialplan rules, and IVR processing.

Lines 241-283 show Queue 803 which is a pass-through queue with no agents logged in.

Lines 283-1666 cover Queue 800 (Queue1), where calls attempt to reach agent 6434 multiple times, failing at the third attempt.

4

According to the log, a subroutine explicitly hung up the incoming channel after leaving the queue:

[2025-09-11 15:50:03] VERBOSE[1467417][C-00002638] pbx.c: Executing [6434@sub-local-dialing:69] ExecIf("PJSIP/Upstream-00005185", "0?Busy(5)") in new stack
[2025-09-11 15:50:03] VERBOSE[1467417][C-00002638] pbx.c: Executing [6434@sub-local-dialing:70] Hangup("PJSIP/Upstream-00005185", "") in new stack

Instead of doing as you thought.

5

OK, I figured this out.

The agent’s phone wasn’t ringing for whatever reason, so they tried transferring the call from an AMI-driven GUI to their extension. When that was done, “it left” the queue and called 6434 directly.

Question: At what log level would I see that transfer/redirect in the logs?

Thanks again

6

A redirect is fairly low level, may not show without debug level. I’m not sure without digging into code.

1 Like
7

Great, thank you again, Josh!

8

I typically generate User defined CEL events(celgenuserevent) for call transfers.. CEL sometimes picks up blindtransfers on its own and there is good info in there you can report on..

at the dialplan level, ${REDIRECTING()} (you can look up all the sub variables available in the asterisk docs) provides good info on the various items available, for me its something i use to generate reporting data for our customer-facing “call tracker” data parser.. so if you want to log it, I would turn on cel to an sqlite3 DB then you can query the DB for “blindtransfer” events.. or if you detect a redirect in your dialplan you can generate your own cel log and place whatever channel variable values you might want into the user data portion of it..
thats just how i handle it… makes it a little bit easier than trying to read through 1000s of lines of console output (we have some 2500 endpoint systems out there which get very busy)