Extension and device states in Asterisk

(Note that these descriptions of device states and extension states have not been updated to the way things work in Asterisk 1.6.)

Asterisk has an internal system that reports states for an extension. By using the dialplan priority -1, also called a hint, a connection can be made from an extension to one or many devices. The state of the extension now depends on the combined state of the devices.

The device state is basically based on the current calls. If the devicestate engine can find a call from or to the device, it's in use.

Some channel drivers implement a callback function for a better level of reporting device states. The SIP channel has a complicated system for this, which is improved by adding call limits to the configuration.

Functions that want to check the status of an extension register themself as a watcher. Watchers in this system can subscribe either to all extensions or just a specific extensions.

For non-device related states, there's an API called devicestate providers. This is an extendible system for delivering state information from outside sources or functions within Asterisk. Currently we have providers for app_meetme.c - the conference bridge - and call parking (metermaids).

There are manly three subscribers to extension states within Asterisk:

• AMI, the manager interface
• app_queue.c - the Queue dialplan application
• SIP subscriptions, a.k.a. "blinking lamps" or "buddy lists"

The CLI command "show hints" show last known state

Note

None of these handle user states, like an IM presence system. res_xmpp.c can subscribe and watch such states in jabber/xmpp based systems.

Architecture for devicestates

When a channel driver or asterisk app changes state for a watched object, it alerts the core. The core queues a change. When the change is processed, there's a query sent to the channel driver/provider if there's a function to handle that, otherwise a channel walk is issued to find a channel that involves the object.

The changes are queued and processed by a separate thread. This thread calls the watchers subscribing to status changes for the object. For manager, this results in events. For SIP, NOTIFY requests.

• Device states
  • devicestate.c
  • devicestate.h

Architecture for extension states

Hints are connected to extension. If an extension changes state it checks the hint devices. If there is a hint, the callbacks into device states are checked. The aggregated state is set for the hint and reported back.

• Extension states
  • AstENUM
  • pbx.c
  • pbx.h
• Structures
  • ast_state_cb struct. Callbacks for watchers
  • Callback ast_state_cb_type
  • ast_hint struct.
• Functions
  • ast_extension_state_add()
  • ast_extension_state_del()
  • ast_get_hint()