167 lines
9.4 KiB
Plaintext
167 lines
9.4 KiB
Plaintext
+===================================================================+
|
|
| QSIG Abstraction |
|
|
+===================================================================+
|
|
|
|
+-------------------------------------------------------------------+
|
|
| QSIG supplementary services |
|
|
+-------------------------------------------------------------------+
|
|
|
|
QSIG network differentiates between four different types of call transfer.
|
|
Two are not assisted and two are 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.
|
|
|
|
+-------------------------------------------------------------------+
|
|
| QSIG abstraction |
|
|
+-------------------------------------------------------------------+
|
|
|
|
Diva abstraction allows to write QSIG applications independent of the type
|
|
of 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.
|
|
|
|
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.
|
|
|
|
+-------------------------------------------------------------------+
|
|
| 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, ...
|
|
|
|
+-------------------------------------------------------------------+
|
|
| 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).
|
|
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
|
|
Diva supports all three roles (A, B, and C) in the mentioned above 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
|
|
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
|
|
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).
|
|
|
|
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
|
|
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 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.
|
|
|
|
+-------------------------------------------------------------------+
|
|
| Support at 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
|
|
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.
|
|
|
|
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
|
|
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.
|
|
|
|
+-------------------------------------------------------------------+
|
|
| 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).
|
|
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
|
|
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
|
|
and parties A and C are connected directly.
|
|
|
|
ECT Example:
|
|
/////////////////////////////////////////////////////////////////////
|
|
[macro-capiect]
|
|
; Activate suppressor of ambient noise for consultation call
|
|
exten => s,1,capicommand(noisesuppressor|yes)
|
|
; Invoke ECT command
|
|
exten => s,n,capicommand(ect)
|
|
|
|
[isdn-in]
|
|
; Send progress message on incoming call
|
|
exten => 12345,1,Progress()
|
|
exten => 12345,n,Set(TIMEOUT(digit)=1) ; Set Digit Timeout to 5 seconds
|
|
exten => 12345,n,Set(TIMEOUT(response)=5) ; Set Response Timeout to 10 seconds
|
|
; Play message to incoming call using early media mode
|
|
exten => 12345,n,Playback(demo-enterkeywords,noanswer,us)
|
|
; Accept incoming call
|
|
exten => 12345,n,Answer
|
|
; Activate suppressor of ambient noises for incoming call
|
|
exten => 12345,n,capicommand(noisesuppressor|yes)
|
|
; Save PLCI of incoming call to CAPIPLCI variable
|
|
exten => 12345,n,capicommand(getplci)
|
|
; Set CAPIECTPLCI variable to PLCI of incoming call
|
|
; and allow to export this variable to consultation call
|
|
exten => 12345,n,Set(_CAPIECTPLCI=${CAPIPLCI})
|
|
; Create consultation call and invoke ECT
|
|
; ECT procedure will detect CAPIECTPLCI is set and use saved in this variable value
|
|
; to identify the ECT party and invoke ECT independent from the state of the primary call
|
|
exten => 12345,n,Dial(CAPI/ISDN1/100,10,M(capiect))
|
|
exten => 12345,n,Hangup()
|
|
/////////////////////////////////////////////////////////////////////
|
|
|