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

1 files changed, 115 insertions, 0 deletions

diff --git a/configs/samples/features.conf.sample b/configs/samples/features.conf.sample
new file mode 100644
index 000000000..1724fc155
--- /dev/null
+++ b/configs/samples/features.conf.sample
@@ -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].