User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 184
Dialogic Corporation
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.
1.51.1.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
Global Call API, both parties are in the GCST_CONNNECTED 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).
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 constructed with the local URI—the same as the
From or To header, depending on the direction of the initial call INVITE. Optionally, the
Transferor can override the default Referred-By header by inserting a Referred-By header
in the gc_InvokeXfer( ) parm block. Party A will be notified if REFER is accepted or
rejected by transferred endpoint (party B).
If party A receives a 2xx response to the REFER (indicating that is was accepted by party
B), a GCEV_INVOKE_XFER_ACCEPTED event may optionally be generated. This
optional event is disabled by default; after the line device has been opened, the event can
be enabled or disabled at any time by use of the gc_SetConfigData( ) function.
The primary call may be terminated by either party before transferred call is completed.
Note that in an H.450.2 implementation, party A will actually get INVOKE_XFER_REJ
event locally if party A terminates the primary call before receiving final status from party
B. Unlike an H.450.2 transfer, party A in a SIP transfer will not get any transfer termination
event if party A terminates the primary call before receiving final status from party B. This
is because there is no way to be sure if the transfer is successful or if it failed and it is