forked from SimplesIP/pabx-app
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
205 lines
8.6 KiB
205 lines
8.6 KiB
; |
|
; --- 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=
|
|
|