Filter
Top Products
66 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
3.2.5 Endpoint Behavior in H.450.2 Supervised Call Transfer
This section describes the behavior of each of the three endpoints in a supervised call transfer under
H.450.2. The assumed preconditions for supervised call transfer are:
• The transferring endpoint (party A) and the transferred endpoint (party B) are participating in
an active call, known as the primary call. From the perspective of the Global Call API, party A
and party B are both in the GCST_CONNECTED state.
• The transferring endpoint and the transferred-to endpoint (party C) are participating in an
active call, known as the secondary or consultation call. From the perspective of the Global
Call call control library, party A and party C are both in the GCST_CONNECTED state. If
party C uses Global Call and is not in the connected state when the transfer is invoked, it may
fail to receive the Global Call event for the transfer request (GCEV_REQ_INIT_XFER),
which will cause it to receive a GCEV_TASKFAIL.
3.2.5.1 Transferring Endpoint (Party A) Role
As in the case of blind transfer, the transferring endpoint initiates the supervised transfer by calling
the gc_InvokeXfer( ) function. The distinction between blind and supervised transfer usage is the
addition of the CRN of the secondary (consultation) call. Calling the gc_InvokeXfer( ) function at
the transferring endpoint with two CRN values results in the sending of an ctIdentify.Invoke APDU
in a Facility message to the transferred-to endpoint (party C). Once a positive acknowledgement
from the transferred-to endpoint is received via a ctIdentify.ReturnResult APDU in a Facility
message, the transferring endpoint automatically proceeds to invoke the actual call transfer by
sending an ctInitiate.Invoke APDU in a Facility message to the transferred endpoint (party B).
From this point forward, from the perspective of this endpoint, the behavior is similar to that of a
blind or unsupervised transfer. The one difference is that the secondary, consultation call is
disconnected once the transferred call is answered at the transferred-to endpoint (party C) and must
be explicitly dropped and released. Note however, if the transferred call goes unanswered or fails,
the secondary call is left active and maintained in the GCST_CONNECTED state.
3.2.5.2 Transferred Endpoint (Party B) Role
The endpoint to be transferred (party B) has no knowledge of the origins of the destination address
information a priori in that it was retrieved as a result of a consultation call. Thus, from the
perspective of this endpoint, the behavior and handling of supervised transfer is exactly the same as
that of blind transfer.
3.2.5.3 Transferred-To Endpoint (Party C) Role
At any point in time after a secondary consultation call is answered by the transferred-to endpoint,
a Facility(ctIdentify.Invoke) request may arrive requesting whether it is able to participate in an
upcoming transfer as signified by the GCEV_REQ_INIT_XFER event. Assuming that the endpoint
is capable, the application calls the gc_AcceptInitXfer( ) function to accept the transfer along with
the intended rerouting number address in the reroutinginfop GC_REROUTING_INFO pointer
parameter. The IP CCLIB internally returns a newly created callIdentity for the transferred call to
use.