diff options
author | Matthew Jordan <mjordan@digium.com> | 2014-07-17 21:17:28 +0000 |
---|---|---|
committer | Matthew Jordan <mjordan@digium.com> | 2014-07-17 21:17:28 +0000 |
commit | fc0fecb4768d696db3324bcf6dd03325bb4cd513 (patch) | |
tree | 12615f96e88382b2824d4901f6949571e41ea2e4 /configs/samples/ccss.conf.sample | |
parent | 1ce23d4534994fdd8bfb8ad3b9ca1884194097be (diff) |
configs: Move sample config files into a subdirectory of configs
This moves all samples configs from configs/ to configs/samples. This allows
for additional sets of sample configuration files to be added in the future.
Review: https://reviewboard.asterisk.org/r/3804/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'configs/samples/ccss.conf.sample')
-rw-r--r-- | configs/samples/ccss.conf.sample | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/configs/samples/ccss.conf.sample b/configs/samples/ccss.conf.sample new file mode 100644 index 000000000..21b0b0668 --- /dev/null +++ b/configs/samples/ccss.conf.sample @@ -0,0 +1,205 @@ +; +; --- Call Completion Supplementary Services --- +; +; For more information about CCSS, see the CCSS user documentation +; https://wiki.asterisk.org/wiki/display/AST/Call+Completion+Supplementary+Services+(CCSS) +; + +[general] +; The cc_max_requests option is a global limit on the number of +; CC requests that may be in the Asterisk system at any time. +; +;cc_max_requests = 20 +; +; The cc_STATE_devstate variables listed below can be used to change the +; default mapping of the internal state machine tracking the state of +; call completion to an Asterisk Device State value. The acceptable values +; that can be provided are as follows, with a description of what the +; equivalent device BLF that this maps to: +; +; UNKNOWN ; Device is valid but channel didn't know state +; NOT_INUSE ; Device is not used +; INUSE ; Device is in use +; BUSY ; Device is busy +; INVALID ; Device is invalid +; UNAVAILABLE ; Device is unavailable +; RINGING ; Device is ringing +; RINGINUSE ; Device is ringing *and* in use +; ONHOLD ; Device is on hold +; +; These states are used to generate DEVICE_STATE information that can be +; included with Asterisk hints for phones to subscribe to the state information +; or dialplan to check the state using the EXTENSION_STATE() function or +; the DEVICE_STATE() function. +; +; The states are in the format of: "ccss:TECH/ID" so an example of device +; SIP/3000 making a CallCompletionRequest() could be checked by looking at +; DEVICE_STATE(ccss:SIP/3000) or an Asterisk Hint could be generated such as +; +; [hint-context] +; exten => *843000,hint,ccss:SIP/3000 +; +; and then accessed with EXTENSION_STATE(*843000@hint-context) +; or subscribed to with a BLF button on a phone. +; +; The available state mapping and default values are: +; +; cc_available_devstate = NOT_INUSE +; cc_offered_devstate = NOT_INUSE +; cc_caller_requested_devstate = NOT_INUSE +; cc_active_devstate = INUSE +; cc_callee_ready_devstate = INUSE +; cc_caller_busy_devstate = ONHOLD +; cc_recalling_devstate = RINGING +; cc_complete_devstate = NOT_INUSE +; cc_failed_devstate = NOT_INUSE + +; +;============================================ +; PLEASE READ THIS!!! +; The options described below should NOT be +; set in this file. Rather, they should be +; set per-device in a channel driver +; configuration file. +; PLEASE READ THIS!!! +;=========================================== +; +;--------------------------------------------------------------------- +; Timers +;--------------------------------------------------------------------- +;There are three configurable timers for all types of CC: the +;cc_offer_timer, the ccbs_available_timer, and the ccnr_available_timer. +;In addition, when using a generic agent, there is a fourth timer, +;the cc_recall_timer. All timers are configured in seconds, and the +;values shown below are the defaults. +; +;When a caller is offered CCBS or CCNR, the cc_offer_timer will +;be started. If the caller does not request CC before the +;cc_offer_timer expires, then the caller will be unable to request +;CC for this call. +; +;cc_offer_timer = 20 +; +;Once a caller has requested CC, then either the ccbs_available_timer +;or the ccnr_available_timer will run, depending on the service +;requested. The reason why there are two separate timers for CCBS +;and CCNR is that it is reasonable to want to have a shorter timeout +;configured for CCBS than for CCNR. If the available timer expires +;before the called party becomes available, then the CC attempt +;will have failed and monitoring of the called party will stop. +; +;ccbs_available_timer = 4800 +;ccnr_available_timer = 7200 +; +; When using a generic agent, the original caller is called back +; when one of the original called parties becomes available. The +; cc_recall_timer tells Asterisk how long it should let the original +; caller's phone ring before giving up. Please note that this parameter +; only affects operation when using a generic agent. +; +;cc_recall_timer = 20 +;--------------------------------------------------------------------- +; Policies +;--------------------------------------------------------------------- +; Policy settings tell Asterisk how to behave and what sort of +; resources to allocate in order to facilitate CC. There are two +; settings to control the actions Asterisk will take. +; +; The cc_agent_policy describes the behavior that Asterisk will +; take when communicating with the caller during CC. There are +; three possible options. +; +;never: Never offer CC to the caller. Setting the cc_agent_policy +; to this value is the way to disable CC for a call. +; +;generic: A generic CC agent is one which uses no protocol-specific +; mechanisms to offer CC to the caller. Instead, the caller +; requests CC using a dialplan function. Due to internal +; restrictions, you should only use a generic CC agent on +; phones (i.e. not "trunks"). If you are using phones which +; do not support a protocol-specific method of using CC, then +; generic CC agents are what you should use. +; +;native: A native CC agent is one which uses protocol-specific +; signaling to offer CC to the caller and accept CC requests +; from the caller. The supported protocols for native CC +; agents are SIP, ISDN ETSI PTP, ISDN ETSI PTMP, and Q.SIG +;cc_agent_policy=never +; +; The cc_monitor_policy describes the behavior that Asterisk will +; take when communicating with the called party during CC. There +; are four possible options. +; +;never: Analogous to the cc_agent_policy setting. We will never +; attempt to request CC services on this interface. +; +;generic: Analogous to the cc_agent_policy setting. We will monitor +; the called party's progress using protocol-agnostic +; capabilities. Like with generic CC agents, generic CC +; monitors should only be used for phones. +; +;native: Analogous to the cc_agent_policy setting. We will use +; protocol-specific methods to request CC from this interface +; and to monitor the interface for availability. +; +;always: If an interface is set to "always," then we will accept +; protocol-specific CC offers from the caller and use +; a native CC monitor for the remainder of the CC transaction. +; However, if the interface does not offer protocol-specific +; CC, then we will fall back to using a generic CC monitor +; instead. This is a good setting to use for phones for which +; you do not know if they support protocol-specific CC +; methodologies. +;cc_monitor_policy=never +; +; +;--------------------------------------------------------------------- +; Limits +;--------------------------------------------------------------------- +; +; The use of CC requires Asterisk to potentially use more memory than +; some administrators would like. As such, it is a good idea to limit +; the number of CC requests that can be in the system at a given time. +; The values shown below are the defaults. +; +; The cc_max_agents setting limits the number of outstanding CC +; requests a caller may have at any given time. Please note that due +; to implementation restrictions, this setting is ignored when using +; generic CC agents. Generic CC agents may only have one outstanding +; CC request. +; +;cc_max_agents = 5 +; +; The cc_max_monitors setting limits the number of outstanding CC +; requests can be made to a specific interface at a given time. +; +;cc_max_monitors = 5 +; +;--------------------------------------------------------------------- +; Other +;--------------------------------------------------------------------- +; +; When using a generic CC agent, the caller who requested CC will be +; called back when a called party becomes available. When the caller +; answers his phone, the administrator may opt to have a macro run. +; What this macro does is up to the administrator. By default there +; is no callback macro configured. +; +;cc_callback_macro= +; +; Alternatively, the administrator may run a subroutine. By default +; there is no callback subroutine configured. The subroutine should +; be specified in the format: [[context,]exten,]priority +; +;cc_callback_sub= +; +; When using an ISDN phone and a generic CC agent, Asterisk is unable +; to determine the dialstring that should be used when calling back +; the original caller. Furthermore, if you desire to use any dialstring- +; specific options, such as distinctive ring, you must set this +; configuration option. For non-ISDN phones, it is not necessary to +; set this, since Asterisk can determine the dialstring to use since +; it is identical to the name of the calling device. By default, there +; is no cc_agent_dialstring set. +; +;cc_agent_dialstring= |