Filter
Top Products
90 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
3.3.6 Unsuccessful Call Transfer Scenarios
All of the scenarios in this section apply to both unattended (blind) transfer and attended
(supervised) SIP call transfers. The gc_InitXfer( ) function call and the corresponding
GCEV_INIT_XFER termination event are “dummy” operations that are only used to synchronize
the Global Call state machine and can safely be ignored in this context.
Transfer failures can be caused by any of transfer endpoints as shown in the scenarios. In all cases,
the transferring endpoint (Transferor or party A) is notified by a GCEV_INVOKE_XFER_REJ
event or a GCEV_INVOKE_XFER_FAIL event. No NOTIFY will be sent from party B to party A
if REFER is not accepted by a 202 Accepted response from party B. The primary call and
secondary call, if any, remain in the connected state after any transfer failure.
The most common transfer failure scenarios are described in the following topics:
• Party B Rejects Call Transfer
• No Response From Party B
• No Initial NOTIFY after REFER Accepted
• REFER Subscription Expires
• No Response From Party C
• Party B Drops Transferred Call Early
• Party C is Busy When Transfer Attempted
3.3.6.1 Party B Rejects Call Transfer
Figure 33, illustrates a scenario in which the application at the transferred endpoint (Transferee or
party B) calls gc_RejectXfer( ) to signal the Transferor (party A) that it cannot participate in a
transfer. The application may specify any valid SIP rejection reason, such as the 480 Temporarily
Unavailable shown in the figure; if no reason is specified, the default reason sent is 603 Decline. As
a result of the rejection, the GCEV_INVOKE_XFER_REJ termination event is received at the
Transferor application (party A). The original primary call is left connected and in the
GCST_CONNECTED state from the perspective of both party A and party B.