Filter
Top Products
96 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
3.3.6.7 Party C is Busy When Transfer Attempted
Figure 39 illustrates a scenario in which the Transfer Target (party C) is busy at the time the
transfer is requested. (This primarily applies to unattended transfers, since the Transferor would be
aware that the Transfer Target is busy in an attended transfer.) In this case, the Transferor (party A)
receives a GCEV_INVOKE_XFER_FAIL termination event and the Transferee (party B) receives
a GCEV_XFER_FAIL termination event. The original primary call is left connected and in the
GCST_CONNECTED state from the perspective of both party A and party B.
Figure 39. SIP Call Transfer Failure - Party C is Busy When Transfer Attempted
A
(Transferring)
App
A
(Transferring)
IP CCLib
B
(Transferred)
App
B
(Transferred)
IP CCLib
C
(Transferred To)
App
C
(Transferred To)
IP CCLib
GCEV_REQ_
XFER(CRNp)
202 Accepted
GCEV_ACCEPT_
XFER(CRNp)
GCEV_
INVOKE_XFER_
ACCEPTED(CRNp)
NOTIFY(100 Trying)
Subscription-State=active; expires=300
200 OK
REFER
gc_InvokeXfer
(CRNp)
INVITE
gc_MakeCall
(CRNt, CRNp)
Party C is busy (not shown)
gc_AcceptXfer
(CRNp)
GCEV_DROPCALL
(CRNt)
gc_ReleaseCallEx
(CRNt)
GCEV_RELEASECALL
(CRNt)
GCEV_XFER_FAIL
(CRNp)
gc_DropCall(CRNt)
Parties A and B remain connected.
Party C also remains connected (to another party not shown).
Post condition:
Cause = IPEC_SIPReasonStatus486BusyHere
NOTIFY (486 Busy Here)
Subscription-State = terminated
200 OK
Cause = IPEC_SIPReasonStatus486BusyHere
GCEV_
INVOKE_XFER_
FAIL(CRNp, busy)
ACK
486 BusyHere
Primary call between parties A and B is connected (not shown).
Party C has call connected to another party (not shown).
Pre condition:
GCEV_DIALING
(CRNt)