Dialogic Global Call IP Benutzerhandbuch

Seite von 604
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 
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