Dialogic Global Call IP Benutzerhandbuch

78

Dialogic Corporation

IP_SIP_MSGINFO_ENABLE in the sip_msginfo_mask field of the IP_VIRTBOARD data 
structure) when the virtual board was started. 

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 transferred call. Referred-
By and Replaces information, if present, is also attached to GCEV_OFFERED events if SIP header 
access was enabled (by setting the IP_SIP_MSGINFO_ENABLE value in the sip_msginfo_mask 
field of the IP_VIRTBOARD data structure) when the virtual board was started.

At that point, the application may retrieve the typical calling party information on CRNt. Party C is 
then provided the same methods of action as a typical incoming call, namely to alert party B that 
the call is proceeding (typically for gateways), ringback notification that the local user is being 
alerted, or simply that the call is answered. The only behavior change from this endpoint over 
typical non-transferred calls is whether to handle the calling party information any differently 
because it is the result of a transfer.

This section describes various scenarios for successful call transfers under the SIP protocol. The 
scenarios include:

All of the scenarios indicate all three common naming conventions for the three parties involved in 
a call transfer: parties (A, B, and C), endpoints (transferring, transferred, and transferred-to), and 
SIP roles (Transferor, Transferee, and Transfer Target). “IP CClib” refers to the call control library 
and SIP stack portions of Global Call. “Non-Global Call” is used to represent a User Agent that 
might behave legally but differently than Global Call. Pre and post conditions are explicitly listed 
in each scenario, but the common pre-condition for all scenarios is that the Transferor (party A) and 
the Transferee (party B) are participating in an active (primary) call and are in the 
GCST_CONNECTED state from the perspective of the Global Call API. 

All of the following scenarios illustrate the optional GCEV_INVOKE_XFER_ACCEPTED event, 
which is disabled by default. The party A application can enable and disable this event at any time 
after the line device is opened using the gc_SetConfigData( ) function.