[HELP] - Queue calls hanging up after 31 sec. in queue

Hi all,

I have a series of inbound numbers that basically dump the caller directly into our customer service queue. There is a gotoiftime command that routes to the following context if our company is open:


pretty simple - we set the monitor filename, the callerID, and dump the person into queue.

we also have a main number that gives them some options, one of which routes them to the SAME context above, and dumps them into queue.

what’s funny is that the main line calls can sit in queue for up to 5 minutes before timing out and going to voicemail (just like they should) but the calls from the other numbers that dump straight into the queue do not. the caller will be in queue for 30-31 seconds, and then the call is simply ended, with no warning to the caller or our agents.

at this point, we’re losing approx 33% of our inbound callers to this issue, and I cannot figure out why - the callers are being dumped into the queue by the SAME context, yet only the callers that come in on our main line are ever allowed to hold more than 31 seconds.

So, for some reason, asterisk is hanging up the call. This is happening on on a regular basis, and I can recreate it at will.


I’m all ears guys. Like I said, the context that sets up the caller being dumped into queue is used for ALL of our inbound numbers, yet only one of them works as it should. The rest (I haven’t tested every single one, there are about 20 in total) seem to only allow the caller to remain in queue for 31 seconds before dropping them.

PLEASE help, if you can - this is driving me up the wall.

update - i checked zapata.conf after seeing the Onhook event in the second CLI capture. for some reason, callprogess was set to yes. I’ll turn that off tonight and see if it helps - if anyone has any other thoughts, please post. we’re losing approx 33% of our calls because of this issue.

changing callprogress to no did not make any difference. we’re still dropping calls at around the 31 second mark.


is the problem that you haven’t answered the calls that is disconnected?

the problem is that we have a queue that several different phone numbers all point to. for ONE of these numbers, calls are dumped into the queue and have up to 5 min to be answered. for all the other numbers, the calls are ending prematurely, after around 30 seconds.

it’s not that agents aren’t picking up the phones - on the contrary, if one of these calls is routed to an agent and picked up within 30 seconds, all is well. but if the caller is on hold for longer than 30 seconds, the call is dropped.

the thing that i can’t get around is that the main number is not affected by this. calls can sit in queue for the full 300 seconds before routing to the queue voicemail, but they NEVER hang up prematurely.

and the final kicker is that both the main number and the other numbers all use the same context to route callers into the queue (see my original post). the only difference between the main number and the others is that the main number routes to an autoattendant first, where the customer has to press a number to be routed to the ‘queue’ context, whereas the other numbers call the context directly.

hopefully this is a bit clearer - i’m sorry if my explanations aren’t what they should be. if this still isn’t clear, i’m going to post some of the dialplan here in a minute.

I diden’t meen that the agent isen’t answering, but when calls to the main number is played a message the call is “answered”, calls that is not played a message before they are queuing is not answered (i think).

Here is our main AA, which is signalled by 888-919-xxxx. Note that customers can hit 2 or 3 to route to the Queue context

[500FC_CUSTOMER_SERVICE_DAY] include => from-inside exten => s,1,Background(500FCDay) exten => s,2,Background(500FCOpts) exten => 1,1,Queue(COPIA_IVR|t) exten => 2,1,Goto(500FC_CUSTOMER_SERVICE_QUEUE,s,1) exten => 3,1,Goto(500FC_CUSTOMER_SERVICE_QUEUE,s,1) exten => 4,1,Goto(500FC_CUSTOMER_SERVICE_DAY,s,1) exten => i,1,Goto(500FC_CUSTOMER_SERVICE_DAY,s,1) exten => t,1,Goto(500FC_CUSTOMER_SERVICE_DAY,s,1)

Now, for 800-264-xxxx, 888-730-xxxx, etc (there are 8 toll-free numbers in total), they call the following context directly, instead of going through the initial autoattendant like the first number does.

[500FC_CUSTOMER_SERVICE_QUEUE] exten => s,1,Set(MONITOR_FILENAME=Queue-CustSvc-${CALLERIDNUM}-${TIMESTAMP}) exten => s,2,SetCallerId(500FC-CUSTSVC-${CALLERIDNUM}) exten => s,3,Queue(500FC_CUSTOMER_SERVICE_QUEUE|t) exten => s,4,Voicemail(su8003)

So, the only difference between the number that works and those that don’t is that the working number calls the top (500FC_CUSTOMER_SERVICE_DAY) context BEFORE routing to the queue context, whereas the other numbers just route directly to the queue context…

does that make more sense? sorry, i whacked my head on one of our overhead tv’s and have a nice inch long split in my scalp…i have a bit of a headache from that.

let me know if you have any ideas, because i’m out.

do you think adding an Answer command to the queue context might do it? i’ll add one right now…

new code:

[500FC_CUSTOMER_SERVICE_QUEUE] exten => s,1,Answer exten => s,2,Set(MONITOR_FILENAME=Queue-CustSvc-${CALLERIDNUM}-${TIMESTAMP}) exten => s,3,SetCallerId(500FC-CUSTSVC-${CALLERIDNUM}) exten => s,4,Queue(500FC_CUSTOMER_SERVICE_QUEUE|t) exten => s,5,Voicemail(su8003)

Yes like this example
exten => 1589,1,Answer
exten => 1589,2,Ringing
exten => 1589,3,Wait(2)
exten => 1589,4,Queue(testq|t|||45)
exten => 1589,5,Queue(testq2|t|||45)
exten => 1589,6,Hangup

For the main number you probebly are using the background or playback command, this commands will do the answer for you.

i never would have thought that that would make a difference, but thank you for pointing that out. i will update the thread as soon as i know for sure that worked.

and if it does, i owe you a case of beer torgeirh

oh beer… I really hope it’s working :smile:

that did it!

we had 4 abandoned queue calls yesterday, contrasted with > 80 the day before.

i cannot believe that the queue command doesn’t automatically ‘answer’ the phone first. let this be a warning to anyone who might dump a caller straight into a queue - use the answer command first.

torgeirh - where are you located? i’m not sure what the rules are on shipping beer - i’d probably end up on some terrorist watchlist.