+===================================================================+
|       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()
/////////////////////////////////////////////////////////////////////