Defining the queues
Queues that you can assign queue members into are defined in the queues.conf file. This file consists of the general section that defines the global options for all queues, and one or more queue sections. We will create queues.conf file in the /etc/asterisk directory and add the following configuration for the general section:
The first option (autofill=yes) makes sure that all waiting callers are connecting to available queue members (this was not always the case in the older versions of Asterisk). The second option (shared_lastcall=yes) will make the queue respect the wrapup time for members logged into more than one queue.
We will work with two queues – the marketing and sales queues. We will use a template for the common parameters, and then define the queues:
musicclass=default ; plays the default music on hold
strategy=rrmemory ; uses the Round Robin with Memory strategy
joinempty=no ; a caller may not join the queue when no members are available
leavewhenempty=yes ; leave the queue when no members available
ringinuse=no ; do not ring members when already InUse (prevents multiple calls to a member)
The options specified above are mostly self-explanatory, except the strategy option. This option distributes calls between members in a queue. We’ve used the Round Robin with Memory strategy, which will rotate through the members in the queue in sequential order, keep track of which agent got the last call, and present the next call to the next agent. When it gets to the last agent, it will go back to the top. Other possible strategies are:
- ringall – ring all available channels until someone answers
- leastrecent – ring the member that was least recently called
- fewestcalls – ring the member with the fewest completed calls
- random – ring a random member
- rrordered – same as rrmemory, except the queue member order from the config file is preserved
- linear – rings members in the order specified in the configuration file.
- wrandom – rings a random members, but uses the member’s penalty as a weight
To apply the configuration, we need to reload the app_queue.so module. There is one more thing we need to do before reloading this module – create an agents.conf file. We won’t use this file, but it needs to be created in order for the app_queue.so module to load:
Now we can reload the app_queue.so module. This can be done using the following command:
geek-university*CLI> module reload app_queue.so
Module 'app_queue.so' reloaded successfully.
-- Reloading module 'app_queue.so' (True Call Queueing)
We can now verify that queues are indeed loaded by using the queue show command:
geek-university*CLI> queue show
sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
marketing has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
As you can see from the output above, two queues exist, but no members (agents) or callers are present in the queues. So let’s add members to our queues and allow calls to be placed in a queue.