e9d72e0cb2
This commit merges in the rest of the code needed to support distributed device state. There are two main parts to this commit. Core changes: - The device state handling in the core has been updated to understand device state across a cluster of Asterisk servers. Every time the state of a device changes, it looks at all of the device states on each node, and determines the aggregate device state. That resulting device state is what is provided to modules in Asterisk that take actions based on the state of a device. New module, res_ais: - A module has been written to facilitate the communication of events between nodes in a cluster of Asterisk servers. This module uses the SAForum AIS (Service Availability Forum Application Interface Specification) CLM and EVT services (Cluster Management and Event) to handle this task. This module currently supports sharing Voicemail MWI (Message Waiting Indication) and device state events between servers. It has been tested with openais, though other implementations of the spec do exist. For more information on testing distributed device state, see the following doc: - doc/distributed_devstate.txt git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
77 lines
2.4 KiB
Text
77 lines
2.4 KiB
Text
;
|
|
; Sample configuration file for res_ais
|
|
; * SAForum AIS (Application Interface Specification)
|
|
;
|
|
; More information on the AIS specification is available from the SAForum.
|
|
; * http://www.saforum.org/
|
|
;
|
|
; A nice open source implementation of AIS is available called openais. Visit
|
|
; the openais website for downloads and more information.
|
|
; * http://www.openais.org/
|
|
;
|
|
|
|
;
|
|
; [general]
|
|
; The general section is reserved but not currently used.
|
|
;
|
|
|
|
;
|
|
; Event channels are named distributed groups that share events. Each node
|
|
; that is the member of the event channel should have an entry in their
|
|
; ais.conf file that indicates that they are a member of the event channel.
|
|
; Each node's entry for the event channel also indicates which event types
|
|
; will be published to other nodes, as well as which event types this node
|
|
; will subscribe to from other nodes in the event channel.
|
|
;
|
|
; The name of the event channel is the name in brackets that begin a section
|
|
; in the configuration file.
|
|
; [mwi]
|
|
;
|
|
; To define an event channel, this entry must be in the configuration section:
|
|
; type=event_channel
|
|
;
|
|
; Indicate that a node is capable of publishing events of a certain type by
|
|
; using the publish_event directive.
|
|
; publish_event=mwi
|
|
;
|
|
; Indicate that a node is interested in receiving events of a certain type
|
|
; from other nodes in the event channel by using the subscribe_event directive.
|
|
; subscribe_event=mwi
|
|
;
|
|
; Supported event types include: mwi, device_state
|
|
;
|
|
|
|
;
|
|
; This example is for a node that can provide MWI state information, but should
|
|
; also be listening for MWI state changes from other nodes. Examples of when
|
|
; this would be used are when this is both a voicemail server and also has
|
|
; phones directly registered to it.
|
|
;
|
|
; [mwi]
|
|
; type=event_channel
|
|
; publish_event=mwi
|
|
; subscribe_event=mwi
|
|
;
|
|
|
|
;
|
|
; This example would be used for a node that can provide MWI state to other
|
|
; nodes, but does not need to know about MWI state changes that happen on
|
|
; any other node. This would most likely be a voicemail server where no
|
|
; phones are directly registered.
|
|
;
|
|
; [mwi]
|
|
; type=event_channel
|
|
; publish_event=mwi
|
|
;
|
|
|
|
;
|
|
; This example would be used for a node that has phones directly registered
|
|
; to it, but does not have direct access to voicemail. So, this node wants
|
|
; to be informed about MWI state changes on other voicemail server nodes, but
|
|
; is not capable of publishing any state changes.
|
|
;
|
|
; [mwi]
|
|
; type=event_channel
|
|
; subscribe_event=mwi
|
|
;
|