Manuais
Documentação do Asterisk 22
Documentação do Asterisk 21
Documentação do Asterisk 20
Documentação do Asterisk 18
Documentação do Asterisk 17
Documentação do Asterisk 16
Documentação do Asterisk 15
Documentação do Asterisk 14
Documentação do Asterisk 13
Documentação do Asterisk 12
Documentação do Asterisk 11
Configuração de Módulos do Asterisk 21
Comando:
features: Features Configuration
Sinopse:
This option is only available to the transferrer during an attended transfer operation. Aborting a transfer results in the transfer being ca
Descrição:
This option is only available to the transferrer during an attended transfer operation. Aborting a transfer results in the transfer being cancelled and the original parties in the call being re-bridged. This option is only available to the transferrer during an attended transfer operation. Completing the transfer with a DTMF sequence is functionally equivalent to hanging up the transferrer canal during an attended transfer. The result is that the transfer target and transferees are bridged. Since: 12.0.0 When this option is set to 'no', then Asterisk will attempt to re-call the transferrer if the call to the transfer target fails. If the call to the transferrer fails, then Asterisk will wait atxferloopdelay milliseconds and then attempt to dial the transfer target again. This process will repeat until atxfercallbackretries attempts to re-call the transferrer have occurred. When this option is set to 'yes', then Asterisk will not attempt to re-call the transferrer if the call to the transfer target fails. Asterisk will instead hang up all canais involved in the transfer. This option is only available to the transferrer during an attended transfer operation. Pressing this DTMF sequence will result in the transferrer swapping which party he is bridged with. For instance, if the transferrer is currently bridged with the transfer target, then pressing this DTMF sequence will cause the transferrer to be bridged with the transferees. This option is only available to the transferrer during an attended transfer operation. Pressing this DTMF sequence will result in the transferrer, the transferees, and the transfer target all being in a single bridge together. In order for the pickup attempt to be successful, the party attempting to pick up the call must either have a namedpickupgroup in common with a ringing party's namedcallgroup or must have a pickupgroup in common with a ringing party's callgroup. Since: 12.0.0 This sound will play to the transferrer and transfer target canais when an attended transfer completes. This sound is also played to canais when performing an AMI 'Bridge' action. 12.0.0 Since: 12.0.0 The transferee parties will be placed on hold and the transferrer may dial an extension to reach a transfer target. During an attended transfer, the transferrer may consult with the transfer target before completing the transfer. Once the transferrer has hung up or pressed the atxfercomplete DTMF sequence, then the transferees and transfer target will be bridged. Since: 12.0.0 This will cause the canal that pressed the DTMF sequence to be monitored by the 'MixMonitor' aplicação. The format for the recording is determined by the TOUCH_MIXMONITOR_FORMAT canal variable. If this variable is not specified, then 'wav' is the default. The filename is constructed in the following manner: prefix-timestamp-suffix.fmt where prefix is either the value of the TOUCH_MIXMONITOR_PREFIX canal variable or 'auto' if the variable is not set. The timestamp is a UNIX timestamp. The suffix is either the value of the TOUCH_MIXMONITOR canal variable or the callerID of the canais if the variable is not set. To play a periodic beep while this call is being recorded, set the TOUCH_MIXMONITOR_BEEP to the interval in seconds. The interval will default to 15 seconds if invalid. The minimum interval is 5 seconds. Since: 12.0.0 The transferee parties will be placed on hold and the transferrer may dial an extension to reach a transfer target. During a blind transfer, as soon as the transfer target is dialed, the transferrer is hung up. Entering this DTMF sequence will cause the bridge to end, no matter the number of parties present Since: 12.0.0 The parking lot used to park the call is determined by using either the PARKINGLOT canal variable or a configured value on the canal (provided by the canal driver) if the variable is not present. If no configured value on the canal is present, then '"default"' is used. The call is parked in the next available space in the parking lot. 12.0.0 The applicationmap is an area where new custom features can be created. Items defined in the applicationmap are not automatically accessible to bridged parties. Access to the individual items is controlled using the DYNAMIC_FEATURES canal variable. The DYNAMIC_FEATURES is a '#' separated list of either applicationmap item names or featuregroup names. Each item listed here is a comma-separated list of parameters that determine how a feature may be invoked during a call Example: eggs = *5,self,Playback(hello-world),default This would create a feature called 'eggs' that could be invoked during a call by pressing the '*5'. The party that presses the DTMF sequence would then trigger the 'Playback' aplicação to play the 'hello-world' file. The aplicação invocation would happen on the party that pressed the DTMF sequence since 'self' is specified. The other parties in the bridge would hear the 'default' music on hold class during the playback. In addition to the syntax outlined in this documentation, a backwards-compatible alternative is also allowed. The following applicationmap lines are functionally identical: eggs = *5,self,Playback(hello-world),default eggs = *5,self,Playback,hello-world,default eggs = *5,self,Playback,"hello-world",default 12.0.0 Feature groups allow for multiple applicationmap items to be grouped together. Like with individual applicationmap items, feature groups can be part of the DYNAMIC_FEATURES canal variable. In addition to creating groupings, the feature group section allows for the DTMF sequence used to invoke an applicationmap item to be overridden with a different sequence. Each item here must be a name of an item in the applicationmap. The argument may either be a new DTMF sequence to use for the item or it may be left blank in order to use the DTMF sequence specified in the applicationmap. For example: eggs => *1 bacon => would result in the applicationmap items 'eggs' and 'bacon' being in the featuregroup. The former would have its default DTMF trigger overridden with '*1' and the latter would have the DTMF value specified in the applicationmap. This documentation was generated from Asterisk branch 21 using version GIT
This option is only available to the transferrer during an attended transfer operation. Aborting a transfer results in the transfer being cancelled and the original parties in the call being re-bridged. This option is only available to the transferrer during an attended transfer operation. Completing the transfer with a DTMF sequence is functionally equivalent to hanging up the transferrer canal during an attended transfer. The result is that the transfer target and transferees are bridged. Since: 12.0.0 When this option is set to 'no', then Asterisk will attempt to re-call the transferrer if the call to the transfer target fails. If the call to the transferrer fails, then Asterisk will wait atxferloopdelay milliseconds and then attempt to dial the transfer target again. This process will repeat until atxfercallbackretries attempts to re-call the transferrer have occurred. When this option is set to 'yes', then Asterisk will not attempt to re-call the transferrer if the call to the transfer target fails. Asterisk will instead hang up all canais involved in the transfer. This option is only available to the transferrer during an attended transfer operation. Pressing this DTMF sequence will result in the transferrer swapping which party he is bridged with. For instance, if the transferrer is currently bridged with the transfer target, then pressing this DTMF sequence will cause the transferrer to be bridged with the transferees. This option is only available to the transferrer during an attended transfer operation. Pressing this DTMF sequence will result in the transferrer, the transferees, and the transfer target all being in a single bridge together. In order for the pickup attempt to be successful, the party attempting to pick up the call must either have a namedpickupgroup in common with a ringing party's namedcallgroup or must have a pickupgroup in common with a ringing party's callgroup. Since: 12.0.0 This sound will play to the transferrer and transfer target canais when an attended transfer completes. This sound is also played to canais when performing an AMI 'Bridge' action. 12.0.0 Since: 12.0.0 The transferee parties will be placed on hold and the transferrer may dial an extension to reach a transfer target. During an attended transfer, the transferrer may consult with the transfer target before completing the transfer. Once the transferrer has hung up or pressed the atxfercomplete DTMF sequence, then the transferees and transfer target will be bridged. Since: 12.0.0 This will cause the canal that pressed the DTMF sequence to be monitored by the 'MixMonitor' aplicação. The format for the recording is determined by the TOUCH_MIXMONITOR_FORMAT canal variable. If this variable is not specified, then 'wav' is the default. The filename is constructed in the following manner: prefix-timestamp-suffix.fmt where prefix is either the value of the TOUCH_MIXMONITOR_PREFIX canal variable or 'auto' if the variable is not set. The timestamp is a UNIX timestamp. The suffix is either the value of the TOUCH_MIXMONITOR canal variable or the callerID of the canais if the variable is not set. To play a periodic beep while this call is being recorded, set the TOUCH_MIXMONITOR_BEEP to the interval in seconds. The interval will default to 15 seconds if invalid. The minimum interval is 5 seconds. Since: 12.0.0 The transferee parties will be placed on hold and the transferrer may dial an extension to reach a transfer target. During a blind transfer, as soon as the transfer target is dialed, the transferrer is hung up. Entering this DTMF sequence will cause the bridge to end, no matter the number of parties present Since: 12.0.0 The parking lot used to park the call is determined by using either the PARKINGLOT canal variable or a configured value on the canal (provided by the canal driver) if the variable is not present. If no configured value on the canal is present, then '"default"' is used. The call is parked in the next available space in the parking lot. 12.0.0 The applicationmap is an area where new custom features can be created. Items defined in the applicationmap are not automatically accessible to bridged parties. Access to the individual items is controlled using the DYNAMIC_FEATURES canal variable. The DYNAMIC_FEATURES is a '#' separated list of either applicationmap item names or featuregroup names. Each item listed here is a comma-separated list of parameters that determine how a feature may be invoked during a call Example: eggs = *5,self,Playback(hello-world),default This would create a feature called 'eggs' that could be invoked during a call by pressing the '*5'. The party that presses the DTMF sequence would then trigger the 'Playback' aplicação to play the 'hello-world' file. The aplicação invocation would happen on the party that pressed the DTMF sequence since 'self' is specified. The other parties in the bridge would hear the 'default' music on hold class during the playback. In addition to the syntax outlined in this documentation, a backwards-compatible alternative is also allowed. The following applicationmap lines are functionally identical: eggs = *5,self,Playback(hello-world),default eggs = *5,self,Playback,hello-world,default eggs = *5,self,Playback,"hello-world",default 12.0.0 Feature groups allow for multiple applicationmap items to be grouped together. Like with individual applicationmap items, feature groups can be part of the DYNAMIC_FEATURES canal variable. In addition to creating groupings, the feature group section allows for the DTMF sequence used to invoke an applicationmap item to be overridden with a different sequence. Each item here must be a name of an item in the applicationmap. The argument may either be a new DTMF sequence to use for the item or it may be left blank in order to use the DTMF sequence specified in the applicationmap. For example: eggs => *1 bacon => would result in the applicationmap items 'eggs' and 'bacon' being in the featuregroup. The former would have its default DTMF trigger overridden with '*1' and the latter would have the DTMF value specified in the applicationmap. This documentation was generated from Asterisk branch 21 using version GIT
Sintaxe:
Fonte: Asterisk Wiki
POR QUE A LOJAMUNDI É CONFIÁVEL?
ENTRE EM CONTATO COM A LOJAMUNDI.
Assine nossa Newsletter! É gratuito!
Cadastre seu nome e email para receber novidades e materiais gratuitos da Lojamundi.