User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 183
Dialogic Corporation
1.51.1.1 General Conditions for SIP Call Transfers
SIP call transfer uses the REFER method (with NOTIFY support) to reroute a call (a SIP
dialog) after the call has been established; in other words, after two endpoints have an
established media path.
There are two fundamental types of call transfer:
• Unattended transfer, which is referred to as “blind transfer” in most other technologies
and protocols. In this type of transfer the transferring party (called the Transferor in
SIP) has a call (or SIP dialog) with the transferred party (called the Transferee in SIP)
but not with the transferred-to party (called the Transfer Target in SIP).
• Attended transfer, which is referred to as “supervised transfer” in most other
technologies and protocols. In this type of transfer, the Transferor has a dialog with
both the Transferee and the Transfer Target.
In its simplest terms, a SIP call transfer involves the Transferor issuing a REFER to the
Transferee to cause the Transferee to issue an INVITE to the Transfer Target. The
Transferee and Transfer Target negotiate the media without regard to the media that had
been negotiated between the Transferor and the Transferee, just as if the Transferee had
initiated the INVITE on its own.
Once a transfer request is accepted by the Transferee, the Transferor is not allowed to
send another transfer request to the Transferee. Only if a transfer request is rejected or
fails is the Transferor allowed to attempt another transfer request to Transferee.
The disposition of the media streams between the Transferor and the Transferee is not
altered by the REFER method. A successful REFER transaction does not terminate the
session between the Transferor and the Transferee; if those parties wish to terminate their
session, they must do so with a subsequent BYE request.
In the SIP call transfer protocol the Transferor is notified when the Transferee accepts the
REFER transfer request. The Dialogic
®
Global Call 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 1.51.3.1, “Enabling
GCEV_INVOKE_XFER_ACCEPTED Events”, on page 204, for more information.
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.