Filter
Top Products
Dialogic
®
Global Call IP Technology Guide — November 2007 77
Dialogic Corporation
IP Call Scenarios
to party A. Sending 202 Accepted to party A starts the REFER subscription, whereupon party B
automatically sends a NOTIFY of 100 Trying (with default expiration time of 300 seconds) to party
A on CRNp. No further notification of 100 Trying is sent from party B to party A during the call
transfer process.
Party B retrieves the destination address information from the unsolicited transfer request via the
GC_REROUTING_INFO structure passed with the GCEV_REQ_XFER event. Party B uses the
rerouting address information (Refer-To address) to initiate a call to the new destination party via
gc_MakeCall( ) on CRNt. From the perspective of the application, this transferred call is treated in
the same manner as a normal singular call and the party receives intermediate call state events as to
the progress of the call (e.g., GCEV_DIALING, GCEV_ALERTING, GCEV_PROCEEDING, and
GCEV_CONNECTED).
If the CRNp number is included during the gc_MakeCall( ) on CRNt and the primary call is in the
connected state, then a GCEV_XFER_CMPLT event is generated on CRNp once the transferred
call is connected. If the CRNp number is not included, there will be no notification to the primary
call and/or party A of the transferred call status. The CRNp number must not be included in the
gc_MakeCall() if primary call was disconnected prior to making transferred call.
When party B receives any provisional response except 100 Trying from Party C and if the REFER
subscription is still alive, party B automatically sends NOTIFY to party A with such transferred
call status.
When party B receives the indication from party C that the call transfer was successful (200 OK),
the party B application is notified of the success via a GCEV_XFER_CMPLT event on CRNp. If
the primary call is still connected, party B will notify party A of the transfer status (200 OK) and
terminate the REFER subscription. Then party B implicitly, without user/application initiation,
disconnects the primary call with party A. Although the primary call to party A is implicitly
dropped, the call itself must still be explicitly dropped via gc_DropCall( ) and released via
gc_ReleaseCallEx( ) to resynchronize the local state machine.
Either the party A or party B application may terminate the primary call after party B accepts the
transfer request. If the primary call is terminated by party A before receiving any call transfer
termination event (GCEV_INVOKE_XFER or GCEV_INVOKE_XFER_FAIL), party B will not
notify party A of the transfer status. If the primary call is terminated by party B before receiving
any transferred call provisional or final response from party C, party B will send NOTIFY to party
A with 200 OK and terminate the REFER subscription before sending BYE to party A.
If the primary call is disconnected before making the transferred call to party C, party B must not
include the primary call CRN (CRNp) when making the transferred call to party C. Otherwise, a
Global Call error will be returned.
Note that the primary call can be disconnected prior to making the transferred call only during an
unattended transfer because the transferred call can be established independently from the primary
call. During an attended transfer, the transferred call cannot be established after the primary call is
disconnected because the primary call database contains the Replaces information that is required
by the transferred call.
If the Referred-By header exists in the REFER message, it is passed to the application via the
GCEV_REQ_XFER event if SIP message information access was enabled (by setting the