Asterisk 11 has been outfitted with support for presence states. An easy way to understand this is to compare presence state support to the device state support Asterisk has always had. Like with device state support, Asterisk has a core API so that modules can register themselves as presence state providers, alert others to changes in presence state, and query the presence state of others. The difference between the device and presence state concepts is made clear by understanding the subject of state for each concept.
- Device state reflects the current state of a physical device connected to Asterisk
- Presence state reflects the current state of the user of the device
For example, a device may currently be
not in use but the person is
away. This can be a critical detail when determining the availability of the person.
While the architectures of presence state and device state support in Asterisk are similar, there are some key differences between the two.
- Asterisk cannot infer presence state changes the same way it can device state changes. For instance, when a SIP endpoint is on a call, Asterisk can infer that the device is being used and report the device state as
in use. Asterisk cannot infer whether a user of such a device does not wish to be disturbed or would rather chat, though. Thus, all presence state changes have to be manually enacted.
- Asterisk does not take presence into consideration when determining availability of a device. For instance, members of a queue whose device state is
busywill not be called; however, if that member's device is
not in usebut his presence is
awaythen Asterisk will still attempt to call the queue member.
- Asterisk cannot aggregate multiple presence states into a single combined state. Multiple device states can be listed in an extension's hint priority to have a combined state reported. Presence state support in Asterisk lacks this concept.
not_set: No presence state has been set for this entity.
unavailable: This entity is present but currently not available for communications.
available: This entity is available for communication.
away: This entity is not present and is unable to communicate.
xa: This entity is not present and is not expected to return for a while.
chat: This entity is available to communicate but would rather use instant messaging than speak.
dnd: This entity does not wish to be disturbed.
Subtype and Message
In addition to the basic presence states provided, presence also has the concept of a subtype and a message.
The subtype is a brief method of describing the nature of the state. For instance, a subtype for the
away status might be "at home".
The message is a longer explanation of the current presence state. Using the same
away example from before, the message may be "Sick with the flu. Out until the 18th".
func_presencestate And The
The only provider of presence state in Asterisk 11 is the
CustomPresence provider. This provider is supplied by the
func_presencestate.so module, which grants access to the
PRESENCE_STATE dialplan function. The documentation for
PRESENCE_STATE can be found here.
CustomPresence is device-agnostic within the core and can be a handy way to set and query presence from dialplan, or APIs such as the AMI.
A simple use case for
CustomPresence in dialplan is demonstrated below.
With this dialplan, a user can dial
[email protected] to toggle Bob's presence between
unavailable. When a user attempts to call Bob using
[email protected], if Bob's presence is currently not
available then the call will go directly to voicemail.
Configuring Presence Subscription with Hints
As is mentioned in the phone support section, at the time of writing this will only work with a Digium phone.
Like with device state, presence state is associated to a dialplan extension with a hint. Presence state hints come after device state in the hint extension and are separated by a comma (
,). As an example:
Or alternatively, you could define the presence state provider without a device.
The first example would allow for someone subscribing to the extension state of
[email protected] to be notified of device state changes for device
SIP/2000 as well as presence state changes for the presence provider
The second example would allow for the subscriber to receive notification of state changes for only the presence provider CustomPresence:2000.
CustomPresence presence state provider will be discussed further on this page.
Example Presence Notification
When a SIP device is subscribed to a hint you have configured in Asterisk and that hint references a presence state provider, then upon change of that state Asterisk will generate a notification. That notification will take the form of a SIP NOTIFY including XML content. In the expanding panel below I've included an example of a presence notification sent to a Digium phone. This particular presence notification happened when we changed presence state for CustomPresence:6002 via the CLI command 'presencestate change'.
Phone Support for Presence State via SIP presence notifications
At the time of writing, only Digium phones have built-in support for interpreting Asterisk's Presence State notifications (as opposed to SIP presence notifications for extension/device state). The CustomPresence provider itself is device-agnostic and support for other devices could be added in. Or devices themselves (soft-phone or hardphone) could be modified to interpret the XML send out in the Presence State notification.
This Video provides more insight on how presence can be set and viewed on Digium phones.
When using Digium phones with the Digium Phone Module for Asterisk, you can set hints in Asterisk so that when one Digium phone's presence is updated, other Digium phones can be notified of the presence change. The DPMA automatically creates provisions such that when a Digium Phone updates its presence,
CustomPresence:<line name> is updated, where
<line name> is the value set for the
line= option in a
type=phone category. Using the example dialplan from the Overview section, Digium phones that are subscribed to
[email protected] will automatically be updated about line 2000's presence whenever line 2000's presence changes.