User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 185
Dialogic Corporation
party A’s responsibility to update the application transfer states in this case. This is a
common scenario in blind transfer where party A does not care about the transferred call
status and drops the primary call immediately after receiving a
INVOKE_XFER_ACCEPTED event.
When the REFER subscription is terminated, party A rejects subsequent NOTIFY
messages. Any of the following events terminate the REFER subscription:
• a NOTIFY with subscription state terminated is received
• a NOTIFY of 180 Ringing is received
• a 2xx-6xx final response is received
• the primary call is terminated
If the primary call remains connected and the REFER subscription is alive, party A may
be notified of the final status of transferred call from party B. The notification of transferred
call status is optional depending on party B.
From party A’s perspective, a call transfer is considered successful as long as
GCEV_INVOKE_XFER_ACCEPTED (if enabled) and GCEV_INVOKE_XFER events are
received. If the optional GCEV_INVOKE_XFER_ACCEPTED event type is enabled, that
event is generated by receiving a 2xx response (to the REFER request) from party B. The
GCEV_INVOKE_XFER event is generated by receiving from party B either a NOTIFY of
termination of the REFER subscription or a NOTIFY of 180 Ringing or 2xx final status on
the transferred call.
The REFER subscription will be terminated and the primary call will also be disconnected
locally immediately after generating a GCEV_INVOKE_XFER event. From the Global Call
API perspective, the primary call is terminated at the transferring endpoint as indicated by
the GCEV_DISCONNECTED event implying the Transferor endpoint is then responsible
for dropping and releasing the primary call.
Transferee or Transferred Endpoint (Party B)
The endpoint to be transferred (party B, or Transferee in SIP terms) is notified of the
request to transfer from the initiating endpoint via a GCEV_REQ_XFER event on CRNp. If
party B accepts the transfer request via gc_AcceptXfer( ) function call on CRNp, a 202
Accepted response is sent 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).