mirror of
https://github.com/asterisk/asterisk.git
synced 2025-10-24 05:38:11 +00:00
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
This commit is contained in:
Matthew Jordan
115
configs/samples/features.conf.sample
Normal file
115
configs/samples/features.conf.sample
Normal file
@@ -0,0 +1,115 @@
|
||||
;
|
||||
; Sample Call Features (transfer, monitor/mixmonitor, etc) configuration
|
||||
;
|
||||
|
||||
; Asterisk 12 Note - All parking lot configuration is now done in res_parking.conf
|
||||
|
||||
[general]
|
||||
;transferdigittimeout => 3 ; Number of seconds to wait between digits when transferring a call
|
||||
; (default is 3 seconds)
|
||||
;xfersound = beep ; to indicate an attended transfer is complete
|
||||
;xferfailsound = beeperr ; to indicate a failed transfer
|
||||
;pickupexten = *8 ; Configure the pickup extension. (default is *8)
|
||||
;pickupsound = beep ; to indicate a successful pickup (default: no sound)
|
||||
;pickupfailsound = beeperr ; to indicate that the pickup failed (default: no sound)
|
||||
;featuredigittimeout = 1000 ; Max time (ms) between digits for
|
||||
; feature activation (default is 1000 ms)
|
||||
;recordingfailsound = beeperr ; indicates that a one-touch monitor or one-touch mixmonitor feature failed
|
||||
; to be applied to the call. (default: no sound)
|
||||
;atxfernoanswertimeout = 15 ; Timeout for answer on attended transfer default is 15 seconds.
|
||||
;atxferdropcall = no ; If someone does an attended transfer, then hangs up before the transfer
|
||||
; target answers, then by default, the system will try to call back the
|
||||
; person that did the transfer. If this is set to "yes", the ringing
|
||||
; transfer target is immediately transferred to the transferee.
|
||||
;atxferloopdelay = 10 ; Number of seconds to sleep between retries (if atxferdropcall = no)
|
||||
;atxfercallbackretries = 2 ; Number of times to attempt to send the call back to the transferer.
|
||||
; By default, this is 2.
|
||||
|
||||
|
||||
; Note that the DTMF features listed below only work when two channels have answered and are bridged together.
|
||||
; They can not be used while the remote party is ringing or in progress. If you require this feature you can use
|
||||
; chan_local in combination with Answer to accomplish it.
|
||||
|
||||
[featuremap]
|
||||
;blindxfer => #1 ; Blind transfer (default is #) -- Make sure to set the T and/or t option in the Dial() or Queue() app call!
|
||||
;disconnect => *0 ; Disconnect (default is *) -- Make sure to set the H and/or h option in the Dial() or Queue() app call!
|
||||
;automon => *1 ; One Touch Record a.k.a. Touch Monitor -- Make sure to set the W and/or w option in the Dial() or Queue() app call!
|
||||
;atxfer => *2 ; Attended transfer -- Make sure to set the T and/or t option in the Dial() or Queue() app call!
|
||||
;parkcall => #72 ; Park call (one step parking) -- Make sure to set the K and/or k option in the Dial() app call!
|
||||
;automixmon => *3 ; One Touch Record a.k.a. Touch MixMonitor -- Make sure to set the X and/or x option in the Dial() or Queue() app call!
|
||||
|
||||
[applicationmap]
|
||||
; Note that the DYNAMIC_FEATURES channel variable must be set to use the features
|
||||
; defined here. The value of DYNAMIC_FEATURES should be the names of the features
|
||||
; to allow the channel to use separated by '#'. For example:
|
||||
;
|
||||
; Set(__DYNAMIC_FEATURES=myfeature1#myfeature2#myfeature3)
|
||||
;
|
||||
; (Note: The two leading underscores allow these feature settings to be set
|
||||
; on the outbound channels, as well. Otherwise, only the original channel
|
||||
; will have access to these features.)
|
||||
;
|
||||
; The syntax for declaring a dynamic feature is any of the following:
|
||||
;
|
||||
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<AppArguments>[,MOH_Class]]
|
||||
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,"<AppArguments>"[,MOH_Class]]
|
||||
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]
|
||||
|
||||
;
|
||||
; FeatureName -> This is the name of the feature used when setting the
|
||||
; DYNAMIC_FEATURES variable to enable usage of this feature.
|
||||
; DTMF_sequence -> This is the key sequence used to activate this feature.
|
||||
; ActivateOn -> This is the channel of the call that the application will be executed
|
||||
; on. Valid values are "self" and "peer". "self" means run the
|
||||
; application on the same channel that activated the feature. "peer"
|
||||
; means run the application on the opposite channel from the one that
|
||||
; has activated the feature.
|
||||
; ActivatedBy -> ActivatedBy is no longer honored. The feature is activated by which
|
||||
; channel DYNAMIC_FEATURES includes the feature is on. Use predial
|
||||
; to set different values of DYNAMIC_FEATURES on the channels.
|
||||
; Historic values are: "caller", "callee", and "both".
|
||||
; Application -> This is the application to execute.
|
||||
; AppArguments -> These are the arguments to be passed into the application. If you need
|
||||
; commas in your arguments, you should use either the second or third
|
||||
; syntax, above.
|
||||
; MOH_Class -> This is the music on hold class to play while the idle
|
||||
; channel waits for the feature to complete. If left blank,
|
||||
; no music will be played.
|
||||
;
|
||||
|
||||
;
|
||||
; IMPORTANT NOTE: The applicationmap is not intended to be used for all Asterisk
|
||||
; applications. When applications are used in extensions.conf, they are executed
|
||||
; by the PBX core. In this case, these applications are executed outside of the
|
||||
; PBX core, so it does *not* make sense to use any application which has any
|
||||
; concept of dialplan flow. Examples of this would be things like Goto,
|
||||
; Background, WaitExten, and many more. The exceptions to this are Gosub and
|
||||
; Macro routines which must complete for the call to continue.
|
||||
;
|
||||
; Enabling these features means that the PBX needs to stay in the media flow and
|
||||
; media will not be re-directed if DTMF is sent in the media stream.
|
||||
;
|
||||
; Example Usage:
|
||||
;
|
||||
;testfeature => #9,peer,Playback,tt-monkeys ;Allow both the caller and callee to play
|
||||
; ;tt-monkeys to the opposite channel
|
||||
;
|
||||
; Set arbitrary channel variables, based upon CALLERID number (Note that the application
|
||||
; argument contains commas)
|
||||
;retrieveinfo => #8,peer,Set(ARRAY(CDR(mark),CDR(name))=${ODBC_FOO(${CALLERID(num)})})
|
||||
;
|
||||
;pauseMonitor => #1,self/callee,Pausemonitor ;Allow the callee to pause monitoring
|
||||
; ;on their channel
|
||||
;unpauseMonitor => #3,self/callee,UnPauseMonitor ;Allow the callee to unpause monitoring
|
||||
; ;on their channel
|
||||
|
||||
; Dynamic Feature Groups:
|
||||
; Dynamic feature groups are groupings of features defined in [applicationmap]
|
||||
; that can have their own custom key mappings. To give a channel access to a dynamic
|
||||
; feature group, add the group name to the value of the DYNAMIC_FEATURES variable.
|
||||
;
|
||||
; example:
|
||||
; [myGroupName] ; defines the group named myGroupName
|
||||
; testfeature => #9 ; associates testfeature with the group and the keycode '#9'.
|
||||
; pauseMonitor => ; associates pauseMonitor with the group and uses the keycode specified
|
||||
; ; in the [applicationmap].
|
||||
Reference in New Issue
Block a user