Deprecated macro usage for connected line, redirecting, and CCSS
[asterisk/asterisk.git] / configs / ccss.conf.sample
1 ;
2 ; --- Call Completion Supplementary Services ---
3 ;
4 ; For more information about CCSS, see the CCSS user documentation
5 ; https://wiki.asterisk.org/wiki/display/AST/Call+Completion+Supplementary+Services+(CCSS)
6 ;
7
8 [general]
9 ; The cc_max_requests option is a global limit on the number of
10 ; CC requests that may be in the Asterisk system at any time.
11 ;
12 ;cc_max_requests = 20
13 ;
14 ; The cc_STATE_devstate variables listed below can be used to change the
15 ; default mapping of the internal state machine tracking the state of
16 ; call completion to an Asterisk Device State value. The acceptable values
17 ; that can be provided are as follows, with a description of what the
18 ; equivalent device BLF that this maps to:
19 ;
20 ;       UNKNOWN      ; Device is valid but channel didn't know state
21 ;       NOT_INUSE    ; Device is not used
22 ;       INUSE        ; Device is in use
23 ;       BUSY         ; Device is busy
24 ;       INVALID      ; Device is invalid
25 ;       UNAVAILABLE  ; Device is unavailable
26 ;       RINGING      ; Device is ringing
27 ;       RINGINUSE    ; Device is ringing *and* in use
28 ;       ONHOLD       ; Device is on hold
29 ;
30 ; These states are used to generate DEVICE_STATE information that can be
31 ; included with Asterisk hints for phones to subscribe to the state information
32 ; or dialplan to check the state using the EXTENSION_STATE() function or
33 ; the DEVICE_STATE() function.
34 ;
35 ; The states are in the format of: "ccss:TECH/ID" so an example of device
36 ; SIP/3000 making a CallCompletionRequest() could be checked  by looking at
37 ; DEVICE_STATE(ccss:SIP/3000) or an Asterisk Hint could be generated such as
38 ;
39 ; [hint-context]
40 ; exten => *843000,hint,ccss:SIP/3000
41 ;
42 ; and then accessed with EXTENSION_STATE(*843000@hint-context)
43 ; or subscribed to with a BLF button on a phone.
44 ;
45 ; The available state mapping and default values are:
46 ;
47 ; cc_available_devstate = NOT_INUSE
48 ; cc_offered_devstate = NOT_INUSE
49 ; cc_caller_requested_devstate = NOT_INUSE
50 ; cc_active_devstate = INUSE
51 ; cc_callee_ready_devstate = INUSE
52 ; cc_caller_busy_devstate = ONHOLD
53 ; cc_recalling_devstate = RINGING
54 ; cc_complete_devstate = NOT_INUSE
55 ; cc_failed_devstate = NOT_INUSE
56
57 ;
58 ;============================================
59 ;           PLEASE READ THIS!!!
60 ; The options described below should NOT be
61 ; set in this file. Rather, they should be
62 ; set per-device in a channel driver
63 ; configuration file.
64 ;           PLEASE READ THIS!!!
65 ;===========================================
66 ;
67 ;---------------------------------------------------------------------
68 ;                                Timers
69 ;---------------------------------------------------------------------
70 ;There are three configurable timers for all types of CC: the
71 ;cc_offer_timer, the ccbs_available_timer, and the ccnr_available_timer.
72 ;In addition, when using a generic agent, there is a fourth timer,
73 ;the cc_recall_timer. All timers are configured in seconds, and the
74 ;values shown below are the defaults.
75 ;
76 ;When a caller is offered CCBS or CCNR, the cc_offer_timer will
77 ;be started. If the caller does not request CC before the
78 ;cc_offer_timer expires, then the caller will be unable to request
79 ;CC for this call.
80 ;
81 ;cc_offer_timer = 20
82 ;
83 ;Once a caller has requested CC, then either the ccbs_available_timer
84 ;or the ccnr_available_timer will run, depending on the service
85 ;requested. The reason why there are two separate timers for CCBS
86 ;and CCNR is that it is reasonable to want to have a shorter timeout
87 ;configured for CCBS than for CCNR. If the available timer expires
88 ;before the called party becomes available, then the CC attempt
89 ;will have failed and monitoring of the called party will stop.
90 ;
91 ;ccbs_available_timer = 4800
92 ;ccnr_available_timer = 7200
93 ;
94 ; When using a generic agent, the original caller is called back
95 ; when one of the original called parties becomes available. The
96 ; cc_recall_timer tells Asterisk how long it should let the original
97 ; caller's phone ring before giving up. Please note that this parameter
98 ; only affects operation when using a generic agent.
99 ;
100 ;cc_recall_timer = 20
101 ;---------------------------------------------------------------------
102 ;                                Policies
103 ;---------------------------------------------------------------------
104 ; Policy settings tell Asterisk how to behave and what sort of
105 ; resources to allocate in order to facilitate CC. There are two
106 ; settings to control the actions Asterisk will take.
107 ;
108 ; The cc_agent_policy describes the behavior that Asterisk will
109 ; take when communicating with the caller during CC. There are
110 ; three possible options.
111 ;
112 ;never:   Never offer CC to the caller. Setting the cc_agent_policy
113 ;         to this value is the way to disable CC for a call.
114 ;
115 ;generic: A generic CC agent is one which uses no protocol-specific
116 ;         mechanisms to offer CC to the caller. Instead, the caller
117 ;         requests CC using a dialplan function. Due to internal
118 ;         restrictions, you should only use a generic CC agent on
119 ;         phones (i.e. not "trunks"). If you are using phones which
120 ;         do not support a protocol-specific method of using CC, then
121 ;         generic CC agents are what you should use.
122 ;
123 ;native:  A native CC agent is one which uses protocol-specific
124 ;         signaling to offer CC to the caller and accept CC requests
125 ;         from the caller. The supported protocols for native CC
126 ;         agents are SIP, ISDN ETSI PTP, ISDN ETSI PTMP, and Q.SIG
127 ;cc_agent_policy=never
128 ;
129 ; The cc_monitor_policy describes the behavior that Asterisk will
130 ; take when communicating with the called party during CC. There
131 ; are four possible options.
132 ;
133 ;never:   Analogous to the cc_agent_policy setting. We will never
134 ;         attempt to request CC services on this interface.
135 ;
136 ;generic: Analogous to the cc_agent_policy setting. We will monitor
137 ;         the called party's progress using protocol-agnostic
138 ;         capabilities. Like with generic CC agents, generic CC
139 ;         monitors should only be used for phones.
140 ;
141 ;native:  Analogous to the cc_agent_policy setting. We will use
142 ;         protocol-specific methods to request CC from this interface
143 ;         and to monitor the interface for availability.
144 ;
145 ;always:  If an interface is set to "always," then we will accept
146 ;         protocol-specific CC offers from the caller and use
147 ;         a native CC monitor for the remainder of the CC transaction.
148 ;         However, if the interface does not offer protocol-specific
149 ;         CC, then we will fall back to using a generic CC monitor
150 ;         instead. This is a good setting to use for phones for which
151 ;         you do not know if they support protocol-specific CC
152 ;         methodologies.
153 ;cc_monitor_policy=never
154 ;
155 ;
156 ;---------------------------------------------------------------------
157 ;                              Limits
158 ;---------------------------------------------------------------------
159 ;
160 ; The use of CC requires Asterisk to potentially use more memory than
161 ; some administrators would like. As such, it is a good idea to limit
162 ; the number of CC requests that can be in the system at a given time.
163 ; The values shown below are the defaults.
164 ;
165 ; The cc_max_agents setting limits the number of outstanding CC
166 ; requests a caller may have at any given time. Please note that due
167 ; to implementation restrictions, this setting is ignored when using
168 ; generic CC agents. Generic CC agents may only have one outstanding
169 ; CC request.
170 ;
171 ;cc_max_agents = 5
172 ;
173 ; The cc_max_monitors setting limits the number of outstanding CC
174 ; requests can be made to a specific interface at a given time.
175 ;
176 ;cc_max_monitors = 5
177 ;
178 ;---------------------------------------------------------------------
179 ;                            Other
180 ;---------------------------------------------------------------------
181 ;
182 ; When using a generic CC agent, the caller who requested CC will be
183 ; called back when a called party becomes available. When the caller
184 ; answers his phone, the administrator may opt to have a macro run.
185 ; What this macro does is up to the administrator. By default there
186 ; is no callback macro configured.
187 ;
188 ;cc_callback_macro=
189 ;
190 ; Alternatively, the administrator may run a subroutine. By default
191 ; there is no callback subroutine configured.  The subroutine should
192 ; be specified in the format: [[context,]exten,]priority
193 ;
194 ;cc_callback_sub=
195 ;
196 ; When using an ISDN phone and a generic CC agent, Asterisk is unable
197 ; to determine the dialstring that should be used when calling back
198 ; the original caller. Furthermore, if you desire to use any dialstring-
199 ; specific options, such as distinctive ring, you must set this
200 ; configuration option. For non-ISDN phones, it is not necessary to
201 ; set this, since Asterisk can determine the dialstring to use since
202 ; it is identical to the name of the calling device. By default, there
203 ; is no cc_agent_dialstring set.
204 ;
205 ;cc_agent_dialstring=