configuration samples: Pull all parking related stuff out of features.conf
[asterisk/asterisk.git] / configs / features.conf.sample
1 ;
2 ; Sample Call Features (transfer, monitor/mixmonitor, etc) configuration
3 ;
4
5 ; Asterisk 12 Note - All parking lot configuration is now done in res_parking.conf
6
7 [general]
8 ;transferdigittimeout => 3      ; Number of seconds to wait between digits when transferring a call
9                                 ; (default is 3 seconds)
10 ;xfersound = beep               ; to indicate an attended transfer is complete
11 ;xferfailsound = beeperr        ; to indicate a failed transfer
12 ;pickupexten = *8               ; Configure the pickup extension. (default is *8)
13 ;pickupsound = beep             ; to indicate a successful pickup (default: no sound)
14 ;pickupfailsound = beeperr      ; to indicate that the pickup failed (default: no sound)
15 ;featuredigittimeout = 1000     ; Max time (ms) between digits for
16                                 ; feature activation  (default is 1000 ms)
17 ;recordingfailsound = beeperr   ; indicates that a one-touch monitor or one-touch mixmonitor feature failed
18                                 ; to be applied to the call. (default: no sound)
19 ;atxfernoanswertimeout = 15     ; Timeout for answer on attended transfer default is 15 seconds.
20 ;atxferdropcall = no            ; If someone does an attended transfer, then hangs up before the transfer
21                                 ; target answers, then by default, the system will try to call back the
22                                 ; person that did the transfer.  If this is set to "yes", the ringing
23                                 ; transfer target is immediately transferred to the transferee.
24 ;atxferloopdelay = 10           ; Number of seconds to sleep between retries (if atxferdropcall = no)
25 ;atxfercallbackretries = 2      ; Number of times to attempt to send the call back to the transferer.
26                                 ; By default, this is 2.
27
28
29 ; Note that the DTMF features listed below only work when two channels have answered and are bridged together.
30 ; They can not be used while the remote party is ringing or in progress. If you require this feature you can use
31 ; chan_local in combination with Answer to accomplish it.
32
33 [featuremap]
34 ;blindxfer => #1                ; Blind transfer  (default is #) -- Make sure to set the T and/or t option in the Dial() or Queue() app call!
35 ;disconnect => *0               ; Disconnect  (default is *) -- Make sure to set the H and/or h option in the Dial() or Queue() app call!
36 ;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!
37 ;atxfer => *2                   ; Attended transfer  -- Make sure to set the T and/or t option in the Dial() or Queue()  app call!
38 ;parkcall => #72                ; Park call (one step parking)  -- Make sure to set the K and/or k option in the Dial() app call!
39 ;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!
40
41 [applicationmap]
42 ; Note that the DYNAMIC_FEATURES channel variable must be set to use the features
43 ; defined here.  The value of DYNAMIC_FEATURES should be the names of the features
44 ; to allow the channel to use separated by '#'.  For example:
45 ;
46 ;    Set(__DYNAMIC_FEATURES=myfeature1#myfeature2#myfeature3)
47 ;
48 ; (Note: The two leading underscores allow these feature settings to be set
49 ;  on the outbound channels, as well.  Otherwise, only the original channel
50 ;  will have access to these features.)
51 ;
52 ; The syntax for declaring a dynamic feature is any of the following:
53 ;
54 ;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<AppArguments>[,MOH_Class]]
55 ;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,"<AppArguments>"[,MOH_Class]]
56 ;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]
57
58 ;
59 ;  FeatureName   -> This is the name of the feature used when setting the
60 ;                   DYNAMIC_FEATURES variable to enable usage of this feature.
61 ;  DTMF_sequence -> This is the key sequence used to activate this feature.
62 ;  ActivateOn    -> This is the channel of the call that the application will be executed
63 ;                   on. Valid values are "self" and "peer". "self" means run the
64 ;                   application on the same channel that activated the feature. "peer"
65 ;                   means run the application on the opposite channel from the one that
66 ;                   has activated the feature.
67 ;  ActivatedBy   -> ActivatedBy is no longer honored.  The feature is activated by which
68 ;                   channel DYNAMIC_FEATURES includes the feature is on.  Use predial
69 ;                   to set different values of DYNAMIC_FEATURES on the channels.
70 ;                   Historic values are: "caller", "callee", and "both".
71 ;  Application   -> This is the application to execute.
72 ;  AppArguments  -> These are the arguments to be passed into the application.  If you need
73 ;                   commas in your arguments, you should use either the second or third
74 ;                   syntax, above.
75 ;  MOH_Class     -> This is the music on hold class to play while the idle
76 ;                   channel waits for the feature to complete. If left blank,
77 ;                   no music will be played.
78 ;
79
80 ;
81 ; IMPORTANT NOTE: The applicationmap is not intended to be used for all Asterisk
82 ;   applications. When applications are used in extensions.conf, they are executed
83 ;   by the PBX core. In this case, these applications are executed outside of the
84 ;   PBX core, so it does *not* make sense to use any application which has any
85 ;   concept of dialplan flow. Examples of this would be things like Goto,
86 ;   Background, WaitExten, and many more.  The exceptions to this are Gosub and
87 ;   Macro routines which must complete for the call to continue.
88 ;
89 ; Enabling these features means that the PBX needs to stay in the media flow and
90 ; media will not be re-directed if DTMF is sent in the media stream.
91 ;
92 ; Example Usage:
93 ;
94 ;testfeature => #9,peer,Playback,tt-monkeys  ;Allow both the caller and callee to play
95 ;                                            ;tt-monkeys to the opposite channel
96 ;
97 ; Set arbitrary channel variables, based upon CALLERID number (Note that the application
98 ; argument contains commas)
99 ;retrieveinfo => #8,peer,Set(ARRAY(CDR(mark),CDR(name))=${ODBC_FOO(${CALLERID(num)})})
100 ;
101 ;pauseMonitor   => #1,self/callee,Pausemonitor     ;Allow the callee to pause monitoring
102 ;                                                  ;on their channel
103 ;unpauseMonitor => #3,self/callee,UnPauseMonitor   ;Allow the callee to unpause monitoring
104 ;                                                  ;on their channel
105
106 ; Dynamic Feature Groups:
107 ;   Dynamic feature groups are groupings of features defined in [applicationmap]
108 ;   that can have their own custom key mappings.  To give a channel access to a dynamic
109 ;   feature group, add the group name to the value of the DYNAMIC_FEATURES variable.
110 ;
111 ; example:
112 ; [myGroupName]         ; defines the group named myGroupName
113 ; testfeature => #9     ; associates testfeature with the group and the keycode '#9'.
114 ; pauseMonitor =>       ; associates pauseMonitor with the group and uses the keycode specified
115 ;                       ; in the [applicationmap].