User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 186
Dialogic Corporation
If the CRNp number is included during the gc_MakeCall( ) on CRNt and the primary call
is in the connected state, then a GCEV_XFER_CMPLT event is generated on CRNp once
the transferred call is connected. If the CRNp number is not included, there will be no
notification to the primary call and/or party A of the transferred call status. The CRNp
number must not be included in the gc_MakeCall() if primary call was disconnected prior
to making transferred call.
When party B receives any provisional response except 100 Trying from Party C and if the
REFER subscription is still alive, party B automatically sends NOTIFY to party A with such
transferred call status.
When party B receives the indication from party C that the call transfer was successful
(200 OK), the party B application is notified of the success via a GCEV_XFER_CMPLT
event on CRNp. If the primary call is still connected, party B will notify party A of the
transfer status (200 OK) and terminate the REFER subscription. Then party B implicitly,
without user/application initiation, disconnects the primary call with the party A. Although
the primary call to party A is implicitly dropped, the call itself must still be explicitly
dropped via gc_DropCall( ) and released via gc_ReleaseCallEx( ) to resynchronize the
local state machine.
Either the party A or party B application may terminate the primary call after party B
accepts the transfer request. If the primary call is terminated by party A before receiving
any call transfer termination event (GCEV_INVOKE_XFER or
GCEV_INVOKE_XFER_FAIL), party B will not notify party A of the transfer status. If the
primary call is terminated by party B before receiving any transferred call provisional or
final response from party C, party B will send NOTIFY to party A with 200 OK and
terminate the REFER subscription before sending BYE to party A.
If the primary call is disconnected before making the transferred call to party C, party B
must not include the primary call CRN (CRNp) when making the transferred call to party
C. Otherwise, a Global Call error will be returned.
Note that the primary call can be disconnected prior to making the transferred call only
during an unattended transfer because the transferred call can be established
independently from the primary call. During an attended transfer, the transferred call
cannot be established after the primary call is disconnected because the primary call
database contains the Replaces information that is required by the transferred call.
If the Referred-By header exists in the REFER message, it is passed to the application via
the GCEV_REQ_XFER event if SIP message information access was enabled (by setting
the IP_SIP_MSGINFO_ENABLE in the sip_msginfo_mask field of the IP_VIRTBOARD
data structure) when the virtual board was started.
Transfer Target or Transferred-To Endpoint (Party C)
From the perspective of party C, the transferred call is, for the most part, treated as a
typical incoming call. The call is first notified to the application by a GCEV_DETECTED or
GCEV_OFFERED event on CRNt. The GCRV_XFERCALL cause value is provided in the
event to alert the application that this call offering is the result of a transfer, but only if the
incoming INVITE contains Referred-By or Replaces information indicating a new