Filter
Top Products
58 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
attempt. Note however, that it is not notified as to the end result of the transfer, specifically whether
the transfer results in a connection or a no-answer. Instead, the transferring endpoint is only
guaranteed notification that the transferred-to endpoint has been alerted to the incoming transferred
call offering (that is, ringback). As specified in H.450.2, the ctInitiate.ReturnResult APDU may be
returned in either Alerting or Connect. The primary call will also be disconnected remotely via the
transferred endpoint (party B) as part of a successful status notification from this endpoint. Both
the forward and reverse logical channels will be closed along with their associated audio or data
streams. From the Dialogic
®
Global Call API perspective, the primary call is terminated at the
transferring endpoint, as indicated by the GCEV_DISCONNECTED event, implying the endpoint
is then responsible for the drop and release of the primary call.
3.2.2.2 Transferred Endpoint (Party B) Role
The endpoint to be transferred (party B) is notified of the request to transfer from the initiating
endpoint via the GCEV_REQ_XFER event. Assuming the party to be transferred accepts the
transfer request via the gc_AcceptXfer( ) function, it retrieves the destination address information
from the unsolicited transfer request via the GC_REROUTING_INFO structure passed within the
GCEV_REQ_XFER event. The endpoint to be transferred then uses the rerouting address
information to initiate a call to the new destination party via gc_MakeCall( ). From the perspective
of the application, this transferred call is treated in the same manner as a normal singular call and
the party receives intermediate call state events as to the progress of the call (that is,
GCEV_DIALING, GCEV_ALERTING, GCEV_PROCEEDING, and GCEV_CONNECTED).
When the transferred endpoint receives its first indication from the transferred-to endpoint (party
C) that the call transfer was successful (ctSetup.ReturnResult APDU), the transferred endpoint is
notified of the transfer success and implicitly, without user or application initiation, disconnects the
primary call with the transferring endpoint.
Assuming the transferred call is answered, the transferred endpoint is then involved in active media
streaming with the transferred-to endpoint. Note that the notification of transfer success via the
GCEV_XFER_CMPLT event may also arrive with any call progress events, that is,
GCEV_ALERTING, GCEV_PROCEEDING, or GCEV_CONNECTED. Although the primary
call to the transferring endpoint (party A) is implicitly dropped, the call itself must still be
explicitly dropped via gc_DropCall( ) to resynchronize the local state machine and released via
gc_ReleaseCallEx( ).
3.2.2.3 Transferred-To Endpoint (Party C) Role
For the most part, from the perspective of the transferred-to endpoint (party C), the transferred call
is treated as a typical incoming call. The call is first notified to the application via
GCEV_DETECTED or GCEV_OFFERED events at which point the GCRV_XFERCALL cause
value provided in the event will alert the application that this call offering is the result of a transfer.
At that point, the application may retrieve the typical calling party information about the call. The
transferred-to party is then provided the same methods of action as a typical incoming call, namely
alerting the transferred endpoint (party B) that the call is proceeding (typical for gateways),
ringback notification that the local user is being alerted, or simply answering the call. The only
behavior change from this endpoint over typical non-transferred calls, is whether to treat or display
the calling party information any differently if it is the result of a transfer. Assuming the transferred
call is eventually connected or timed out on no answer, the transferred-to party must eventually
drop and release this call as the case for non-transferred call.