Processed by doc control
This commit is contained in:
MelwareDE
parent
cd9788c177
commit
1e15bbee22
154
README.Diva.qsig
154
README.Diva.qsig
|
|
@ -1,4 +1,4 @@
|
|||
+===================================================================+
|
||||
+===================================================================+
|
||||
| QSIG Abstraction |
|
||||
+===================================================================+
|
||||
|
||||
|
|
@ -6,131 +6,137 @@
|
|||
| QSIG supplementary services |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
QSIG network differentiates between four different types of call transfer.
|
||||
Two are not assisted and two are assisted.
|
||||
The QSIG network differentiates between four different types of call transfers,
|
||||
two unassisted and two assisted.
|
||||
The type of invoked unassisted call transfer depends on the call state.
|
||||
The type of assisted call transfers depends on the type of the switching
|
||||
equipment Diva interfaces to.
|
||||
The coding of the messages and the type of the transfer invoked depends
|
||||
on the QSIG dialect and on the vendor specific implementation of QSIG dialect.
|
||||
equipment Dialogic(R) Diva(R) interfaces as well.
|
||||
The coding of the messages and the type of the transfer invoked, depends
|
||||
on the QSIG dialect and on the vendor-specific implementation of QSIG dialect.
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| QSIG abstraction |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
Diva abstraction allows to write QSIG applications independent of the type
|
||||
of used QSIG dialect.
|
||||
Dialogic(R) Diva(R) System Release Software abstraction allows to write
|
||||
QSIG applications independent of the used QSIG dialect.
|
||||
|
||||
Not assisted call transfer:
|
||||
Application can use CAPI call deflection. Diva will automatically translate
|
||||
call deflection request in the appropriate QSIG primitives.
|
||||
The translation depends on the Diva configuration and on the call state.
|
||||
You can invoke this feature in any call state, but request can fail in
|
||||
case used switching equipment does not supports the required service.
|
||||
Unassisted call transfer:
|
||||
The application can use CAPI call deflection. The Diva System Release software
|
||||
will automatically translate the call deflection request in the appropriate
|
||||
QSIG primitives. The translation depends on the Diva System Release software
|
||||
configuration and on the call state.
|
||||
You can invoke this feature in any call state, but the request may fail in
|
||||
case the used switching equipment does not support the required service.
|
||||
|
||||
Assisted call transfer:
|
||||
Application can use CAPI Explicit Call Transfer (ECT). Diva will automatically
|
||||
translate ECT in the appropriate QSIG primitive.
|
||||
The translation depends on the Diva configuration.
|
||||
The application can use CAPI Explicit Call Transfer (ECT). The Diva System Release
|
||||
software will automatically translate ECT in the appropriate QSIG primitive.
|
||||
The translation depends on the Diva System Release configuration.
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| Conclusion |
|
||||
+-------------------------------------------------------------------+
|
||||
If reviewed in short form you can use any ETSI application with QSIG and do not
|
||||
need to change any code to access QSIG call transfers. This is no need to deal
|
||||
with details of underlying network.
|
||||
The same is true not only for QSIG. This is true for all supported by Diva
|
||||
signaling protocols. Same interface can be used to access basic and
|
||||
supplementary services for ETSI, QSIG, SS7 ISUP, 5ESS, R2, RBS/CAS, ...
|
||||
If reviewed in short form, you can use any ETSI application with QSIG and without
|
||||
the need to change any code to access QSIG call transfers. There is no need to deal
|
||||
with details of the underlying network.
|
||||
The same is true not only for QSIG but for all supported signaling protocols.
|
||||
The same interface can be used to access basic and supplementary services for
|
||||
ETSI, QSIG, SS7 ISUP, 5ESS, R2, RBS/CAS, ...
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| QSIG path replacement |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
Three parties which are involved in the path replacement procedure.
|
||||
Party which initiated the call (party A), party which initially received and
|
||||
transferred the call (party B) and the party which finally received the
|
||||
call after call transfer (party C).
|
||||
There are three parties involved in the path replacement procedure;
|
||||
The party that initiated the call (party A), the party that initially received and
|
||||
transferred the call (party B) and the party that finally received the
|
||||
call after the call transfer (party C).
|
||||
|
||||
The goal of the call replacement procedure is to free switching equipment resources
|
||||
by replacement of chain A->B->C with chain A->C.
|
||||
To achieve this goal party B will short cut D-channel link between A and C and
|
||||
let A and C exchange D-channel messages. In the most of cases party B will short
|
||||
cut the B-channel between A and C too and preserve this connection until path
|
||||
replacement is complete. In case path replacement will not proceed (not supported, ...)
|
||||
party B will preserve D-channel and B-channel interconnections for the entire
|
||||
by the replacement of the chain A->B->C with chain A->C.
|
||||
To achieve this, party B will short cut the D-channel link between A and C and
|
||||
let A and C exchange D-channel messages. In most cases, party B will short
|
||||
cut the B-channel between A and C as well and preserve this connection until the path
|
||||
replacement is complete. If the path replacement will not proceed (not supported, ...),
|
||||
party B will preserve the D-channel and B-channel interconnections for the entire
|
||||
duration of the call.
|
||||
|
||||
After party B completes the call transfer procedure one transfer complete message
|
||||
will be sent (Diva configuration option) and will invoke path replacement procedure
|
||||
(Diva configuration option). As part of this procedure party A will prepare alternative
|
||||
resource and send information about this resource over the D-channel to C through B.
|
||||
After reception of information about alternative resource C will establish new call
|
||||
After party B completes the call transfer procedure, one transfer complete message
|
||||
will be sent (Diva System Release softwre configuration option) and will invoke the path
|
||||
replacement procedure (Diva System Release configuration option). As part of this procedure,
|
||||
party A will prepare an alternative resource and send information about this resource over
|
||||
the D-channel to C through B.
|
||||
After the information about the alternative resource is received, C will establish a new call
|
||||
directly from C to A and replace A->B->C by C->A (A->B->C still running in parallel).
|
||||
After new connection is established A and C will change B-channel connection to new one
|
||||
After the new connection is established, A and C will establish a new B-channel connection
|
||||
and will exchange D-channel messages over B and release connections A->B and B->C.
|
||||
After release is complete C->A is preserved until duration of the call.
|
||||
After the release is complete, C->A is preserved during the duration of the call.
|
||||
|
||||
Diva supports all three roles (A, B, and C) in the mentioned above path replacement procedure.
|
||||
The Diva System Release software supports all three parties A, B, and C in the above mentioned
|
||||
path replacement procedure.
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| Support at party A and C endpoints |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
The support at A and C endpoints is transparent to the applications.
|
||||
Diva will replace one connection with other in fully transparent to application way.
|
||||
The data streaming between application and the bearer resource will be not interrupted
|
||||
The Diva System Release software will replace one connection with another in
|
||||
a fully transparent way to the application.
|
||||
The data streaming between the application and the bearer resource will not be interrupted
|
||||
during this operation. Only one notification about the change of the B-channel and
|
||||
about the completion of the path replacement procedure is provided to application but
|
||||
does not requires any action from the side of application (in certain environments
|
||||
about the completion of the path replacement procedure is provided to the application but
|
||||
does not require any action from the application (in certain environments
|
||||
applications will use this notification to issue RESET_B3 REQ and restart the voice
|
||||
message if any. PBX applications does not need to perform any action).
|
||||
message if any. PBX applications do not need to perform any action).
|
||||
|
||||
Please not that C responds to call replacement procedure only if the change of the
|
||||
connection is supported by underlying protocol. This change is not possible if Fax or
|
||||
Modem session is already in progress. In this case C will ignore path replacement and
|
||||
Please note that party C responds to the call replacement procedure only if the change of the
|
||||
connection is supported by the underlying protocol. This change is not possible if the fax or
|
||||
modem session is already in progress. In this case, C will ignore the path replacement and
|
||||
the chain A->B->C will be preserved for the entire duration of the call.
|
||||
The same is true if path replacement procedure will fail for any reason.
|
||||
The same is true if the path replacement procedure fails for any reason.
|
||||
|
||||
The MTPX adapter is required to provide path replacement operation at A and B.
|
||||
MTPX adapter is responsible for moving the call between different connections in the
|
||||
transparent for application way. Path replacement can be performed only between Diva
|
||||
interfaces which belongs to the same MTPX adapter.
|
||||
The M-Board is required to provide the path replacement operation at A and B and it is
|
||||
responsible for moving the call between different connections transparently for application.
|
||||
The path replacement can be performed only between Dialogic(R) Diva(R) interfaces
|
||||
that belong to the same M-Board.
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| Support at party B endpoint |
|
||||
| Support at the party B endpoint |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
Party B is the party which uses ECT to perform the assisted QSIG call transfer.
|
||||
The type of the call transfer and the messages sent after call transfer is completed
|
||||
are specified by Diva configuration. Diva detects if compatible QSIG dialects are used
|
||||
for both parties of ECT and will automatically establish D-channel bridge.
|
||||
Application is responsible to establish the B-channel bridge. The best practice is to
|
||||
Party B is the party that uses ECT to perform the assisted QSIG call transfer.
|
||||
The type of call transfer and the messages sent after the call transfer is completed
|
||||
are specified by the Diva System Release software configuration. The software detects if
|
||||
compatible QSIG dialects are used for both parties of ECT and will automatically
|
||||
establish the D-channel bridge.
|
||||
The application is responsible to establish the B-channel bridge. The best practice is to
|
||||
establish the B-channel bridge (using CAPI line interconnect command) before issuing
|
||||
the CAPI ECT command. Diva CAPI will atomatically maintain the D-channel bridge.
|
||||
the CAPI ECT command. The Dialogic(R) Diva(R) CAPI will atomatically maintain the D-channel bridge.
|
||||
|
||||
In case Diva MTPX adapter is used at party B endpoint this is possible to activate "ECT Emulation".
|
||||
If active MTPX adapter will automatically establish and maintain B-channel and D-channel bridge
|
||||
once ECT command is sent by Application. In this case this is no need to maintain the B-channel
|
||||
bridge by application. The MTPX adapter will maintain all necessary resources until path
|
||||
If the M-Board is used at the party B endpoint, it is possible to activate "ECT Emulation".
|
||||
If active, the M-Board will automatically establish and maintain the B-channel and D-channel bridge
|
||||
once the ECT command is sent by the application. In this case, there is no need to maintain the B-channel
|
||||
bridge by the application. The M-Board will maintain all necessary resources until the path
|
||||
replacement procedure is completed or for the entire duration of the call.
|
||||
This option is available only for calls which belongs to the same MTPX adapter.
|
||||
This option is available only for calls that belong to the same M-Board.
|
||||
|
||||
+-------------------------------------------------------------------+
|
||||
| Call state of involved in the ECT calls |
|
||||
+-------------------------------------------------------------------+
|
||||
|
||||
In case of QSIG this is not necessary to put one of the involved in the ECT calls on hold.
|
||||
Moreover this is possible to invoke the ECT if the consultation call is in alerted state
|
||||
(in case supported by switching equipment).
|
||||
In case of QSIG, it is not necessary to put one of the calls, involved in the ECT, on hold.
|
||||
Moreover, it is possible to invoke the ECT if the consultation call is in alerted state
|
||||
(if supported by the switching equipment).
|
||||
To achieve this, independent from the state of the primary and of the consultation call operation
|
||||
of the ECT this is necessary to set CAPIECTPLCIvariable to PLCI (getplci commang provides it in
|
||||
of the ECT, it is necessary to set the CAPIECTPLCI variable to PLCI (getplci commang provides it in
|
||||
CAPIPLCI variable) of the primary call before invoking the ECT.
|
||||
|
||||
Example: Application accepts one call, creates consultation call and once alert is received for
|
||||
consultation call starts playback of message on the first call. After additional command is
|
||||
received application proceeds with ECT independent from the state of the consultation call.
|
||||
This is even possible to play the message to the first call until path replacement is completed
|
||||
Example: The application accepts one call, creates the consultation call and once the alert is
|
||||
received, the consultation call starts the playback of message on the first call. After an
|
||||
additional command is received, the application proceeds with ECT, independent from the state
|
||||
of the consultation call.
|
||||
It is even possible to play the message to the first call until the path replacement is completed
|
||||
and parties A and C are connected directly.
|
||||
|
||||
ECT Example:
|
||||
|
|
|
|||
125
README.media
125
README.media
|
|
@ -1,4 +1,4 @@
|
|||
+===================================================================+
|
||||
+===================================================================+
|
||||
| Media control commands |
|
||||
+===================================================================+
|
||||
|
||||
|
|
@ -7,18 +7,18 @@
|
|||
+-------------------------------------------------------------------+
|
||||
|
||||
Description:
|
||||
Used to activate or to deactivate suppression of ambient noise.
|
||||
Can be used to remove caused by fans, air cooling systems, cars,
|
||||
trains and other sources of ambient noises from speech.
|
||||
Noise Suppressor is used to activate or to deactivate suppression of ambient noise,
|
||||
which can be used to remove noise from speech caused by fans, air cooling systems,
|
||||
cars, trains and other sources of ambient noises from speech.
|
||||
|
||||
Direction:
|
||||
Applies to Rx path only.
|
||||
In case of line interconnect can be activated for multiple parties.
|
||||
In case of line interconnect, it can be activated for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Diva 4PRI PCI, Diva 2PRI PCI, Diva 4PRI PCIe HS
|
||||
Other equipped with DSP Diva hardware can use this feature only
|
||||
together with RTP
|
||||
Dialogic(R) Diva(R) 4PRI PCI, 2PRI PCI, 4PRI PCIe HS Media Board
|
||||
Other Dialogic(R) Diva(R) Media Boards equipped with DSP Diva hardware can use this
|
||||
feature only together with RTP.
|
||||
|
||||
Syntax:
|
||||
noisesuppressor|yes,no
|
||||
|
|
@ -68,16 +68,15 @@ exten => 12345,n,Hangup()
|
|||
+-------------------------------------------------------------------+
|
||||
|
||||
Description:
|
||||
Used to activate or to deactivate suppression
|
||||
Clamping is used to activate or to deactivate suppression
|
||||
(removal from voice stream) of DTMF tones.
|
||||
|
||||
Direction:
|
||||
Applies to Rx path only.
|
||||
In case of line interconnect can be activated for
|
||||
multiple parties.
|
||||
In case of line interconnect, it can be activated for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Dialogic(R) Diva(R) Media Board equipped with DSPs
|
||||
|
||||
Syntax:
|
||||
clamping|N
|
||||
|
|
@ -220,11 +219,11 @@ Description:
|
|||
Allows to set gain in the range from -127 dBm to +6 dBm.
|
||||
|
||||
Diection:
|
||||
Applies to Rx path only. In case of line interconnect can be activated
|
||||
Applies to Rx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
rxdgain|N
|
||||
|
|
@ -264,11 +263,11 @@ Description:
|
|||
Allows to change gain in the range from -127 dBm to +6 dBm
|
||||
|
||||
Diection:
|
||||
Applies to Rx path only. In case of line interconnect can be activated
|
||||
Applies to Rx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
incSyntax:
|
||||
rxdgain|N
|
||||
|
|
@ -303,14 +302,14 @@ exten => h,1,Hangup
|
|||
|
||||
Description:
|
||||
Used to access Digital Gain Control for Tx direction.
|
||||
Allows to set gain in the range from -127 dBm to +6 dBm.
|
||||
Allows to set gain control in the range from -127 dBm to +6 dBm.
|
||||
|
||||
Diection:
|
||||
Applies to Tx path only. In case of line interconnect can be activated
|
||||
Applies to Tx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
txdgain|N
|
||||
|
|
@ -350,11 +349,11 @@ Description:
|
|||
Allows to change gain in the range from -127 dBm to +6 dBm
|
||||
|
||||
Diection:
|
||||
Applies to Tx path only. In case of line interconnect can be activated
|
||||
Applies to Tx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
incSyntax:
|
||||
rxtgain|N
|
||||
|
|
@ -391,18 +390,18 @@ Description:
|
|||
Used to set recording (Rx direction) and playback (Tx direction)
|
||||
rate in the range between 1250 ... 51200 Hz.
|
||||
|
||||
Using pitch control this is possible to play (record) voice message faster
|
||||
Using pitch control, it is possible to play (record) voice message faster
|
||||
(rate > 8000 Hz) or slower (rate < 8000 Hz).
|
||||
This is useful if playing voice mail messages and this is necessary to decrease the
|
||||
playback speed to achieve better understanding or to increase playback speed to
|
||||
rewind over the part of voice mail message.
|
||||
This is useful if the playback speed of voice mail messages needs to be decreased
|
||||
to achieve better understanding or to increase playback speed to
|
||||
rewind over a certain part of the voice mail message.
|
||||
|
||||
Diection:
|
||||
Applies to Rx and to Tx path. Can be used only for playback and for
|
||||
recoring of voice data. Not available with line interconnect and RTP.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
pitchcontrol|RxN|TxN - set Rx and Tx rate to different values
|
||||
|
|
@ -439,21 +438,21 @@ exten => h,1,Hangup
|
|||
+-------------------------------------------------------------------+
|
||||
|
||||
Description:
|
||||
Used to change recording (Rx direction) and playback (Tx direction)
|
||||
rate in the range between 1250 ... 51200 Hz.
|
||||
Used to change the recording (Rx direction) and playback (Tx direction)
|
||||
rate in the range from 1250 ... 51200 Hz.
|
||||
|
||||
Using pitch control this is possible to play (record) voice message faster
|
||||
With pitch control it is possible to play (record) voice message faster
|
||||
(rate > 8000 Hz) or slower (rate < 8000 Hz).
|
||||
This is useful if playing voice mail messages and this is necessary to decrease the
|
||||
playback speed to achieve better understanding or to increase playback speed to
|
||||
rewind over the part of voice mail message.
|
||||
This is useful if the playback speed of voice mail messages needs to be decreased
|
||||
to achieve better understanding or to increase playback speed to
|
||||
rewind over a certain part of the voice mail message.
|
||||
|
||||
Diection:
|
||||
Applies to Rx and to Tx path. Can be used only for playback and for
|
||||
recoring of voice data. Not available with line interconnect and RTP.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
incpitchcontrol|RxN|TxN - change Rx and Tx rate using different values
|
||||
|
|
@ -489,17 +488,17 @@ exten => h,1,Hangup
|
|||
+-------------------------------------------------------------------+
|
||||
|
||||
Description:
|
||||
Used to activate or to deactivate MF listen on B channel data
|
||||
Used to activate or to deactivate MF listen on B-channel data.
|
||||
Detected MF tones are mapped to appropriate DTMF digits.
|
||||
MF digits K1, K2, KP, S1 and ST are mapped to DTMF digits
|
||||
MF digits K1, K2, KP, S1, and ST are mapped to DTMF digits
|
||||
A, B, C, D, and * respectively.
|
||||
|
||||
Direction:
|
||||
Applies to Rx path only. In case of line interconnect can be activated
|
||||
Applies to Rx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
mftonedetection|yes,no
|
||||
|
|
@ -536,11 +535,11 @@ Description:
|
|||
Detected dialing pulses are mapped to appropriate DTMF digits.
|
||||
|
||||
Direction:
|
||||
Applies to Rx path only. In case of line interconnect can be activated
|
||||
Applies to Rx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
pulsedetection|yes,no
|
||||
|
|
@ -582,7 +581,7 @@ Path:
|
|||
Applies to Tx path only.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware.
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
|
||||
Syntax:
|
||||
sendtone|N
|
||||
|
|
@ -666,26 +665,26 @@ Description:
|
|||
Stop tone detection (stoptonedetection)
|
||||
|
||||
Direction:
|
||||
Applies to Rx path only. In case of line interconnect can be activated
|
||||
Applies to Rx path only. In case of line interconnect, it can be activated
|
||||
for multiple parties.
|
||||
|
||||
Supported hardware:
|
||||
Requires one equipped with DSP Diva hardware
|
||||
Not available if RTP is active
|
||||
Requires one Diva Media Board equipped with DSPs.
|
||||
Not available if RTP is active.
|
||||
|
||||
Syntax:
|
||||
starttonedetection|N
|
||||
stoptonedetection
|
||||
|
||||
N - extension number to be used in case tone detected.
|
||||
N - Extension number to be used in case a tone is detected.
|
||||
The reception of appropriate DTMF digits will be simulated after the
|
||||
detection of tone. At same time variable CAPIDETECTEDTONE will be set
|
||||
to identifier of detected tone in decimal format and variable
|
||||
CAPIDETECTEDTONEVISUAL will be set to user friendly name of detected tone.
|
||||
detection of the tone. At same time, the variable CAPIDETECTEDTONE will be set
|
||||
to identify the detected tone in decimal format and the variable
|
||||
CAPIDETECTEDTONEVISUAL will be set to a user friendly name of the detected tone.
|
||||
|
||||
Tone identifier:
|
||||
0x82 - Dial tone detected
|
||||
0x83 - PABX internal dial tone detected
|
||||
0x83 - PABX internal dial tone detected
|
||||
0x84 - Special dial tone (stutter dial tone) detected
|
||||
0x85 - Second dial tone detected
|
||||
0x86 - Ringing tone detected
|
||||
|
|
@ -769,25 +768,25 @@ exten => h,1,Hangup
|
|||
+-------------------------------------------------------------------+
|
||||
|
||||
Description:
|
||||
In the time voice message played back this is usefule to be able to apply
|
||||
While a voice message is played back it is useful to be able to apply
|
||||
media control commands to voice stream without interrupting the playback
|
||||
of the voice stream.
|
||||
The same is true for the conference and for connection between two parties.
|
||||
|
||||
The "vc" command allows to provide this functionality. Using this command
|
||||
The "vc" command allows to provide this functionality. With this command
|
||||
it is possible to bind arbitrary chan_capi commands to sequences of
|
||||
events (DTMF digits, ...). Once events are detected the appropriate command
|
||||
events (DTMF digits, ...). Once the events are detected, the appropriate command
|
||||
is executed without interruption of the voice stream.
|
||||
"vc" allows to create menu which is executing in background and allows to
|
||||
"vc" allows to create a menu that is executed in the background and allows to
|
||||
control voice stream by activation or deactivation of AGC, noise suppression,
|
||||
control the level of the signal, playback speed.
|
||||
control the level of the signal, and playback speed.
|
||||
"vc" allows to use any supported by channel driver command, but please note
|
||||
that commands are executed not in the context of the dial plan. The commands
|
||||
are executed using context of detected events parallel to dialplan and
|
||||
independent from dialplan.
|
||||
that commands are not executed in the context of the dial plan. The commands
|
||||
are executed using the context of the detected events parallel to the dialplan and
|
||||
independent from the dialplan.
|
||||
|
||||
Syntax:
|
||||
vc|command|key|param|param1|...|paramN
|
||||
vc|command|key|param|param1|...|paranN
|
||||
Add to menu: on detection of key Execute command using parameters param1|...|paramN
|
||||
|
||||
vc|command|key
|
||||
|
|
@ -799,8 +798,8 @@ vc|command
|
|||
vc
|
||||
Cleanup menu
|
||||
|
||||
In case one command will use key which is already in use then new command will overwrite
|
||||
one already existing:
|
||||
In case one command will use a key that is already in use then a new command will overwrite
|
||||
the existing command:
|
||||
exten => s,n,capicommand(vc|txagc|3|yes)
|
||||
exten => s,n,capicommand(vc|inctxdgain|3|1.5)
|
||||
|
||||
|
|
@ -808,11 +807,11 @@ is equivalent to:
|
|||
|
||||
exten => s,n,capicommand(vc|inctxdgain|3|1.5)
|
||||
|
||||
This is better to use only one digit as key for commands in menu
|
||||
if using menu for IVR and voice mailbox. This provides short response time.
|
||||
It is better to use only one digit as key for commands in menu if using the menu for IVR and
|
||||
voice mailbox. This provides short response time.
|
||||
|
||||
In case menu is used for conference or for connection between two parties it may be useful to use
|
||||
two or three digits for key. This will prevent one activation by occasional pressing of keys.
|
||||
In case, the menu is used for conference or for connection between two parties it may be useful to use
|
||||
two or three digits for the key. This will prevent an activation by accidentally pressing of keys.
|
||||
|
||||
Syntax example:
|
||||
exten => s,n,capicommand(vc|inctxdgain|5|1.5) ; Execute inctxdgain|1.5 if received DTMF digit 5
|
||||
|
|
|
|||
Loading…
Reference in New Issue