Dialogic IP Phone 05-2239-009 User Manual

84

Dialogic Corporation

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. 

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. 

The ability to direct the REFER to either of the parties to which the Transferor provides the 
opportunity to protect the Transfer Target.