mirror of
https://github.com/asterisk/asterisk.git
synced 2025-09-03 03:20:57 +00:00
6000f9963c
Adds additional control options over the transfer feature functionality to give users more control in how the transfer feature sounds and works. First, the "transfer" sound that plays when a transfer is initiated can now be customized by the user in features.conf, just as with the other transfer sounds. Secondly, the user can now specify the transfer extension in advance by using the TRANSFER_EXTEN variable. If a valid extension is contained in this variable, the call will automatically be transferred to this destination. Otherwise, it will fall back to collecting the extension from the user as is always done now. ASTERISK-29899 #close Change-Id: Ibff309caa459a2b958706f2ed0ca393b1ef502e3
128 lines
8.6 KiB
Plaintext
128 lines
8.6 KiB
Plaintext
;
|
|
; Sample Call Features (transfer, monitor/mixmonitor, etc) configuration
|
|
;
|
|
|
|
; Note: From Asterisk 12 - 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). If the TRANSFER_EXTEN dialplan variable has been set
|
|
; on the channel of the user that is invoking the transfer feature, then
|
|
; this option is not used as the user is transferred directly to the extension
|
|
; specified by TRANSFER_EXTEN (the transfer context remains the context specified
|
|
; by TRANSFER_CONTEXT, if set, and otherwise the default context).
|
|
;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.
|
|
;transferdialattempts = 3 ; Number of times that a transferer may attempt to dial an extension before
|
|
; being kicked back to the original call.
|
|
;transferannouncesound = beep ; Sound to play to a transferer to indicate transfer process has begun. If empty, no sound will be played.
|
|
;transferretrysound = beep ; Sound to play when a transferer fails to dial a valid extension.
|
|
;transferinvalidsound = beeperr ; Sound to play when a transferer fails to dial a valid extension and is out of retries.
|
|
;atxferabort = *1 ; cancel the attended transfer
|
|
;atxfercomplete = *2 ; complete the attended transfer, dropping out of the call
|
|
;atxferthreeway = *3 ; complete the attended transfer, but stay in the call. This will turn the call into a multi-party bridge
|
|
;atxferswap = *4 ; swap to the other party. Once an attended transfer has begun, this option may be used multiple times
|
|
|
|
; 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 a pre-dial
|
|
; handler to set different values for 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].
|