User is logged into phone OK and into queue, but no users ever ring. Even when setting as static agent.
We join the queue as we’ve set Join when empty yes, but console never show a ring.
We see:
[2010-10-07 13:40:58] DEBUG[10350] app_queue.c: Queue 6300 has no realtime members defined. No need for update
but
queue show 6300
6300 has 0 calls (max unlimited) in ‘rrmemory’ strategy (0s holdtime, 0s talktime), W:0, C:0, A:2, SL:0.0% within 60s
Members:
Test user (Local/[email protected]/n) (dynamic) (Invalid) has taken no calls yet
Local/[email protected]/n (dynamic) (Invalid) has taken no calls yet
No Callers
Also, when using a static member full logs show:
“is unavailable as device state is invalid”
We’re using generate hints too for queue toggle BLF
Anything we’re missing? We’re on Asterisk 1.6.2.11
the USEQUEUUESTATE does not influence whether or not the individual toggle hints and feature codes are generated.
USEDEVSTATE influences that.
USEQUEUESTATE is just a badly named hint (because of some history) that will force it to generate the “HINT” states for the members vs. the device state that is supported (but a sub-optimal design and serious short sighted on the Asterisk dev team’s side) up through 1.6.2 until they finally added the hints into 1.8.
Well as long as you are on 1.6, you will need to not set QUEUESTATE=yes as that is what is resulting in your “HINT” (the same thing is generated when you login with a dynamic agent)
Once you disable that, it will try to use the Device information in place of the HINT, which is mostly accurate though it does not address users with multiple devices and it does not address the addition of information such as DND which the hint would.
At this point, the patch has not been ported to 1.6, or otherwise the official support from 1.8 has not been back ported to 1.6, which would recognize the HINT syntax. (And I’m not sure if they kept the same syntax I used in the original patch, if the Asterisk team is true to their normal MO, they will have changed it to something else and then we are going to have to detect it is a 1.8 system and change the syntax we generate so it works properly.
You need to create a few static agents (that would normally be dynamic) and show me what is in the queues_additional.conf file for the “member=” line like those I included above.
You can even make a new queue to do that, I just need to see what is being generated for your configuration and version so we are on the same page.
6300 has 0 calls (max unlimited) in ‘rrmemory’ strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
Members:
Natalie Smith (Local/[email protected]/n) (Invalid) has taken no calls yet
Local/[email protected]/n (dynamic) (Invalid) has taken no calls yet
No Callers
you haven’t clarified what your current situation is to know if there is an issue or not? Even if you are using all dynamic, you can add a static agent to answer the above questions (unless you want to check the CLI when your agent logs in as similar member information can be seen there).
It’s hard to answer your question without knowing what your current state is, and I’m not quite sure anyhow what “Is 1.4 the only way?” - the only way what?
Being in deviceanduser mode, if especially if you happen to have multiple devices per user, you may be having an issue with the way it is detecting the member state (though even with one device per user).
For your static agents, check the “member” entries in queues_additional.conf. It should look something like this:
Where the last entry is the device that is associated with the user 202 (it does not have to be the same as the user number). That is the device that is going to be associated with the member’s state to determine if they are available or not. For device and user mode, that can be ambiguous.
I wrote a patch that was available for Asterisk 1.4 that, in conjunction with setting USEQUEUESTATE=yes (the name is a bit unintuitive), would generate queue members as:
such that the HINT would be used, which is more valid and resolved all deviceanduser issues as well. However, the Asterisk team delayed adding this until 1.8 (and the syntax may be a little different, I have not checked on that), even though the patch has been available and fairly heavily tested for probably 1.5 years now. This of course won’t work for 1.6 because the patch has not been ported to the best of my knowledge (even though it wouldn’t be too hard to do such if someone wants to).
There is an open bug related to this change for cases where the device is not available such as someone trying to use a follow-me where they no the device will not be used. That ticket is slowly being worked for a solution. So any additional information on this issue that uncovers something else related to this area would be timely for us to incorporate into the fix.