Filter
Top Products
Dialogic
®
Global Call IP Technology Guide — November 2007 75
Dialogic Corporation
IP Call Scenarios
In the SIP call transfer protocol the Transferor is notified when the Transferee accepts the REFER
transfer request. The Dialogic
®
Global Call API Library allows this notification to be signaled to
the application as a GCEV_INVOKE_XFER_ACCEPTED event. This event is optional, and is
disabled (or masked) 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. See Section 4.25.5.1,
“Enabling GCEV_INVOKE_XFER_ACCEPTED Events”, on page 315 for details.
When performing a call transfer operation, all involved call handles must be on the same stack
instance. This imposes the following application restrictions for call transfer operations
• When performing an attended call transfer at party A, both the consultation line device and the
transferring line device must be on the same virtual board.
• When performing a call transfer (either attended or unattended) at party B, both the
transferring line device and the transferred line device must be on the same virtual board.
• When performing an attended call transfer at party C, both the consultation line device and the
transferred-to line device must be on the same virtual board.
Interoperability Issues
The latest standards for the SIP REFER method are defined in IETF RFC 3515, published in April
2003. The current Global Call implementation is compliant with RFC 3515, but many existing
implementations of REFER are based on the previous draft of the REFER method and are not fully
compliant. The most significant non-compliance issues are:
• no initial NOTIFY after sending out 202 accept to REFER request
• no subscription state information in NOTIFY message
• no NOTIFY generated by the Transferee (Transferred party) after the call is terminated
• any NOTIFY received by the Transferor (Transferring party) after the subscription is
terminated or the call is terminated will be rejected. Note that the subscription can be
terminated implicitly after receiving NOTIFY of 180 Ringing.
3.3.2 Endpoint Behavior in Unattended SIP Call Transfers
The precondition for unattended call transfer (commonly referred to as “blind call transfer” in other
technologies and protocols) is that the transferring endpoint (party A, or Transferor in SIP
terminology) and the transferred endpoint (party B or Transferee in SIP terms) are participating in
an active call, known as the primary call. From the perspective of the Dialogic
®
Global Call API,
both parties are in the GCST_CONNECTED state. Completion of a successful unattended transfer
results in the eventual termination of the primary call, and the creation of the transferred call
between party B and the Transfer Target (party C).
3.3.2.1 Transferor or Transferring Endpoint (party A)
The Transferor (party A) initiates an unattended transfer by calling the gc_InvokeXfer( ) function
on the CRN of the primary call (CRNp), which results in the sending a REFER message to the
Transferee (party B). The Refer-To header in the REFER request is constructed from either the char
*numberstr or the GC_MAKECALL_BLK *makecallp parameter in the gc_InvokeXfer( )
function, following the same rules as gc_MakeCall( ). The Referred-By header is automatically