User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 193
Dialogic Corporation
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.
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.
To protect the Transfer Target, the Transferor simply reverses the primary and secondary
call CRNs when calling gc_InvokeXfer( ) to reverse the roles of the two remote parties.
The original Transfer Target will now send INVITE to the original Transferee, so that the
Transferee is effectively “called back” by the Transfer Target. This has the advantage of
hiding information about the original Transfer Target from the original transferee, although
the Transferee’s experience in this scenario will be different that in current systems PBX or
Centrex systems.
To expose the Transfer Target and provide an experience similar to current PBX and
Centrex systems, the Transferor uses the secondary call to alert the Transfer Target to the
impending transfer, but then disconnects the secondary call and completes the transfer as