Dialogic Dialogic Global Call IP IP Phone User Manual


 
78 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
IP_SIP_MSGINFO_ENABLE in the sip_msginfo_mask field of the IP_VIRTBOARD data
structure) when the virtual board was started.
3.3.2.3 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 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.
3.3.3 Successful Unattended SIP Call Transfer Scenarios
This section describes various scenarios for successful call transfers under the SIP protocol. The
scenarios include:
Successful Transfer with Notification of Connection
Successful Transfer with Notification of Ringing
Successful Transfer with Early Termination of REFER Subscription
Successful Transfer with Primary Call Cleared Prior to Transfer Completion
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.