QUEUEHOLDTIME Always Zero

Home » Asterisk Users » QUEUEHOLDTIME Always Zero
Asterisk Users 10 Comments

Asterisk 1.8.10.1~dfsg-1ubuntu1

Trying to build a simple announcement of the Queue status. QUEUEHOLDTIME
is always zero. What am I doing wrong?

queues.conf
[general]
autofill=yes shared_lastcall=yes

[StandardQueue](!)
musicclass

10 thoughts on - QUEUEHOLDTIME Always Zero

  • QUEUEHOLDTIME and some other Queue variables will be set just prior to the caller being bridged with a queue member and prior to the caller leaving the queue. So have some calls answered in sales Queue and then check the value for variable.

    –Satish Barot

  • — Executing [812@LocalSets:1] NoOp(“SIP/08000F3BE07C-00000005”,
    “queue status”) in new stack
    — Executing [812@LocalSets:2] Set(“SIP/08000F3BE07C-00000005”,
    “LOGGEDIN=1”) in new stack
    — Executing [812@LocalSets:3] Set(“SIP/08000F3BE07C-00000005”,
    “READY=0”) in new stack
    — Executing [812@LocalSets:4] Set(“SIP/08000F3BE07C-00000005”,
    “WAITING=2”) in new stack
    — Executing [812@LocalSets:5] Set(“SIP/08000F3BE07C-00000005”,
    “STUFF=0”) in new stack
    — Executing [812@LocalSets:6] Verbose(“SIP/08000F3BE07C-00000005”,
    “waiting: 2 calls in queue: 2 avg hold: 0 logged in: 1 ready: 0”) in new stack waiting: 2 calls in queue: 2 avg hold: 0 logged in: 1 ready: 0

    asset333*CLI> queue show sales sales has 2 calls (max unlimited) in ‘rrmemory’ strategy (0s holdtime,
    0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
    Members:
    SIP/mlcx500 (dynamic) (Ringing) has taken no calls yet
    Callers:
    1. SIP/mlcm800-00000001 (wait: 0:52, prio: 0)
    2. SIP/mlcx450-00000003 (wait: 0:45, prio: 0)

    Mitch

  • Satish I believe you have the answer. See output below, where I have 1
    call answered and 1 in the queue. Unfortunately, the average wait time is very inaccurate. These two calls where placed within seconds of each other. The one still in the queue has a wait time of 4:10, so the average should be about 4 minutes.

    — Executing [812@LocalSets:1] NoOp(“SIP/08000F3BE07C-0000000e”,
    “queue status”) in new stack
    — Executing [812@LocalSets:2] Set(“SIP/08000F3BE07C-0000000e”,
    “LOGGEDIN=1”) in new stack
    — Executing [812@LocalSets:3] Set(“SIP/08000F3BE07C-0000000e”,
    “READY=0”) in new stack
    — Executing [812@LocalSets:4] Set(“SIP/08000F3BE07C-0000000e”,
    “WAITING=1”) in new stack
    — Executing [812@LocalSets:5] Set(“SIP/08000F3BE07C-0000000e”,
    “STUFF=0”) in new stack
    — Executing [812@LocalSets:6] Verbose(“SIP/08000F3BE07C-0000000e”,
    “waiting: 1 calls in queue: 1 avg hold: 58 logged in: 1 ready: 0”) in new stack waiting: 1 calls in queue: 1 avg hold: 58 logged in: 1 ready: 0

    asset333*CLI> queue show sales sales has 1 calls (max unlimited) in ‘rrmemory’ strategy (58s holdtime,
    0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
    Members:
    SIP/mlcx500 (dynamic) (In use) has taken no calls yet
    Callers:
    1. SIP/mlcx450-00000003 (wait: 4:10, prio: 0)

  • I am also writing an AMI application that will allow management to see the queue status from an external program and saw the same issues with the AMI data. Using AMI I am able to get what I need from the individual records for each queued call.

    Mitch

  • Did you try restarting asterisk not only a reload Also I found a few broken stuff in queues like the rules (yes its on the tracker) maybe this is also

    —–Original Message—

  • That’s because the call is still on hold. Once the call is answered, the avg hold time will update again. It’s an average of how long the answered calls had to wait, not an average of all current calls waiting on hold. At least, that’s my understanding of the issue…

  • Warren – that coincides with what I am seeing. I guess it made sense to someone, but it is not terribly useful to me.

    mitch

  • The idea is a busy call center that takes calls all day long should be able to determine their average wait / hold time over the course of the day. It’s a metrics thing, not a live data feed. It doesn’t really become useful until you’ve had several live calls, and then it’s only useful if you’ve got predictable call times.

    For example, one of my clients has a customer service call center. Each of their calls are usually handled in less than 5 minutes. If their average hold times start spiking higher than that, they look at possibly increasing staff (among other things), because the idea is to not make the customer wait very long.

    Now, another customer runs a tech support hotline. These calls can take anywhere between a simple three minute password reset call to a 2 hour adventure to track down some hidden issue. This customer doesn’t look at hold time metrics, because they end up all over the place.

    If you want a good, in depth look at metrics related to your queues, I would suggest giving Queuemetrics an evaluation. Queuemetrics is a program that analyzes your queue_log file and generates both live data as well as historical reports. Both of the customers I’ve listed above utilize Queuemetrics and they both love it. The licensing is very reasonable for the market and they offer free evaluations as well.

    Thanks,
    –Warren Selby, dCAP