Device states in Asterisk are important both from a software standpoint (Asterisk might need to know the state of a device or the line on a device in order to know whether a call can be placed to it) and from a user’s perspective (for example, a light may be turned on or off to signify whether a particular line is in use, or whether an agent is available for any more calls). From the viewpoint of a queue, it is extremely important to know the status of the device an agent is using in order to determine whether the next caller in the queue can be distributed to that agent. Without knowledge of the device’s state, the queue would simply place multiple calls to the same endpoint.
Once you start expanding your single system to multiple boxes (potentially in multiple physical locations, such as remote or satellite offices), you will need to distribute the device state of endpoints between the systems. The kind of implementation that is required will depend on whether you’re distributing them between systems on the same LAN (low-latency links) or over a WAN (higher-latency links). We’ll discuss two device state distribution methods in this section: OpenAIS for low-latency links, and XMPP for higher-latency links.
The OpenAIS implementation (http://www.openais.org/doku.php) was first added to
Asterisk in the 1.6.1 branch, to enable distribution of device state
information across servers. The addition of OpenAIS provided great possibilities for distributed systems, as
device state awareness is an important aspect of such systems. Previous
methods required the use of GROUP() and
GROUP_COUNT() for each channel, with that information
queried for over DUNDi. While this approach is useful in some scenarios
(we could use this functionality to look up the number of calls our
systems are handling and direct calls intelligently to systems handling
fewer calls), as a mechanism for determining device state information it
is severely lacking.
OpenAIS did give us the first
implementation of a system that allows the state of devices and message
waiting indications to be distributed among multiple Asterisk systems
(see Figure 22.6, “Device state distribution with OpenAIS”). The downside of the
OpenAIS implementation is that it requires all the systems to live on
low-latency links, which typically means they all need to reside in the
same physical location, attached to the same switch. That said, while
the OpenAIS library does not work across physically separate networks,
it does allow a Queue() to reside on one system and
queue members to reside on another system (or multiple systems). It does
this without requiring us to use Local channels and test their
availability through other methods, thereby limiting (or eliminating)
the number of connection attempts made across the network, and multiple
device ringing.
Using OpenAIS has an advantage, in that it is relatively easy to configure and get working. The disadvantage is that it is not distributable over physical locations. As of Asterisk 1.8, though, we can use XMPP for device state distribution over a wide area network, as you’ll see in the next section.
More information about configuring distributed device states with OpenAIS is available in the section called “Using OpenAIS”.
As of Asterisk 1.8, an implementation that uses XMPP for device state distribution has been added. Because the XMPP protocol is designed for (or at least allows) usage across wide area networks, we can now have Asterisk systems at different physical locations distribute device state information to each other (see Figure 22.7, “Device state distribution with XMPP”). With the OpenAIS implementation, the library would be used on each system, enabling them to distribute device state information. In the XMPP scenario, a central server (or cluster of servers) is used to distribute the state among all of the Asterisk boxes in the cluster. Currently the best application for doing this is the Tigase XMPP server (http://www.tigase.org), because of its support for PubSub events. While other XMPP servers may be supported in the future, only Tigase is known to work at this time.
With XMPP, the queues can be located in different physical locations, and satellite offices can take calls from the primary office, or vice versa. This provides another layer of redundancy, because if the primary site goes offline and the ITSP is set up in such a way as to fail over to another office, the calls can be distributed among those satellite offices until the primary site goes back online. This is quite exciting for many people, as it adds a layer of functionality that was not previously available, and most of it can be done with relatively minimal configuration.
The advantage to XMPP device state distribution is that it is possible to distribute state to multiple physical locations, which is not possible with OpenAIS. The disadvantage is that it is more complex to set up (since you need an external service running the Tigase XMPP server) than the OpenAIS implementation.
More information about configuring distributed device states with XMPP can be found in the section called “Using XMPP”.