Filter
Top Products
74 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
3.3 Call Transfer Scenarios When Using SIP
The Dialogic
®
Global Call API functions that supports IP call transfer are described in the Global
Call API Library Reference; protocol-specific information about the individual call transfer APIs
can be found in the subsections of Section 8.3, “Dialogic
®
Global Call API Function Variances for
IP”. General information on implementing call transfer can be found in Section 4.25, “Call
Transfer”, on page 310, and SIP-specific details can be found in Section 4.25.5, “Call Transfer
When Using SIP”, on page 315.
The following topics describe the call transfer capabilities provided when using the SIP call
transfer supplementary service:
• General Conditions for SIP Call Transfers
• Endpoint Behavior in Unattended SIP Call Transfers
• Successful Unattended SIP Call Transfer Scenarios
• Endpoint Behavior in Attended SIP Transfers
• Successful SIP Attended Call Transfer Scenarios
• Unsuccessful Call Transfer Scenarios
3.3.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.