System information

You could further refine these login and logout routines to take into account that the
AQMSTATUS and RQMSTATUS channel variables are set each time AddQueueMember() and
RemoveQueueMember() are used. For example, you could set a flag that lets the queue
member know he has not been added to a queue by setting a flag, or even add recordings
or text-to-speech systems to play back the particular queue that is producing the prob-
lem. Or, if you’re monitoring this via the Asterisk Manager Interface, you could have
a screen pop, or use JabberSend() to inform the queue member via instant messaging.
(Sorry, sometimes our brains run away with us.)
An Introduction to Device State
Device states in Asterisk are used to inform various applications as to whether your
device is currently in use or not. This is especially important for queues, as we don’t
want to send callers to an agent who is already on the phone. Device states are controlled
by the channel module, and in Asterisk only chan_sip has the appropriate handling.
When the queue asks for the state of a device, it first queries the channel driver (e.g.,
chan_sip). If the channel cannot provide the device state directly (as is the case with
chan_iax2), it asks the Asterisk core to determine it, which it does by searching through
channels currently in progress.
Unfortunately, simply asking the core to search through active channels isn’t accurate,
so getting device state from channels other than chan_sip is less reliable when working
with queues. We’ll explore some methods of controlling calls to other channel types
in “Advanced Queues” on page 283, but for now we’ll focus on SIP channels, which
do not have complex device state requirements. For more information about device
states, see Chapter 14.
In order to correctly determine the state of a device in Asterisk, we need to enable call
counters in sip.conf. By enabling call counters, we’re telling Asterisk to track the active
calls for a device so that this information can be reported back to the channel module
and the state can be accurately reflected in our queues. First, let’s see what happens to
our queue without the callcounter option:
*CLI> queue show support
support has 0 calls (max unlimited) in 'rrmemory' strategy
(0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
Members:
SIP/0000FFFF0001 (dynamic) (Not in use) has taken no calls yet
No Callers
Now suppose we have an extension in our dialplan, 555, that calls MusicOnHold(). If we
dial that extension without having enabled call counters, a query of the support queue
(of which SIP/0000FFFF0001 is a member) from the Asterisk CLI will show something
similar to the following:
-- Executing [555@LocalSets:1] MusicOnHold("SIP/0000FFFF0001-00000000",
"") in new stack
-- Started music on hold, class 'default', on SIP/0000FFFF0001-00000000
Queue Members | 273