Filter
Top Products
84 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
3.3.4 Endpoint Behavior in Attended SIP Transfers
The assumed preconditions for attended SIP call transfer (commonly referred to as “supervised call
transfer” in other technologies and protocols) are:
• 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, party A and party B are both in the
GCST_CONNECTED state.
• The Transferor and the transferred-to party (party C or the Transfer Target in SIP terminology)
are participating in an active call, known as the secondary or consultation call. From the
perspective of the Global Call call control library, party A and party C are both in the
GCST_CONNECTED state.
Completion of a successful attended transfer results in the eventual termination of the primary and
secondary calls, and the creation of the transferred call between party B and the party C.
3.3.4.1 Transferor or Transferring Endpoint (Party A)
SIP does not support or require a transfer initiation process to obtain the rerouting number as in
H.323/H.450.2 supervised transfer. To be consistent with the generic Global Call supervised
transfer scenario, the party A application in a SIP attended transfer can call gc_InitXfer( ), but no
request / response messages will be exchanged between party A and party C as a result. Following
this function call, party A always receives a GCEV_INIT_XFER completion event with a dummy
rerouting address. To alert party C of incoming transfer process, party A can only notify party C by
application data or human interaction outside of SIP protocol.
Just as in the case of unattended transfers, an attended transfer is actually initiated when the
Transferor calls the gc_InvokeXfer( ) function. The difference between unattended and attended
transfer usage is the inclusion of the CRN of the secondary (consultation) call as a parameter in the
function call. When the Transferor calls gc_InvokeXfer( ) with two CRN values, a REFER
message with a replace parameter in the Refer-To header is sent to the Transferee (party B).
From this point onward, the behavior at this endpoint is similar to that of a unattended transfer,
except that the application must also drop the secondary/consultation call at transfer completion.
Unlike H.450.2, Global Call will not disconnect the secondary/consultation call once the
transferred call is answered at party C.
Because SIP does not require any pre-invocation setup for attended call transfers, the Transferor
(party A) can actually treat either of the two active calls as the primary call, and can send the
REFER to either of the remote endpoints. This fact provides a recovery mechanism in case one of
the remote endpoints does not support the REFER method, as illustrated in the scenarios in the
following section.
Protecting and Exposing the Transfer Target
The ability to direct the REFER to either of the parties to which the Transferor provides the
opportunity to protect the Transfer Target.