User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 187
Dialogic Corporation
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.
1.51.1.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 Dialogic
®
Global Call Software.
“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_CONNNECTED state from the perspective of the Global Call API.
For simplification purposes, none of the figures indicate the opening and closing of logical
channels (and the associated media sessions) because the control procedures are
consistent with typical non-transfer related SIP calls.
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.
Successful Transfer with Notification of Connection
Figure 1 illustrates the basic successful scenario, with party A receiving notification from
party B after the transferred call between party B and party C has been connected. The
SIP dialog for the primary call between party A and party B is automatically disconnected,
and both parties then tear down the call using gc_DropCall( ) and gc_ReleaseCallEx( ).