Filter
Top Products
76 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP Call Scenarios
constructed with the local URI—the same as the From or To header, depending on the direction of
the initial call INVITE. Optionally, the Transferor can override the default Referred-By header by
inserting a Referred-By header in the gc_InvokeXfer( ) parm block. Party A will be notified if
REFER is accepted or rejected by transferred endpoint (party B).
If party A receives a 2xx response to the REFER (indicating that is was accepted by party B), a
GCEV_INVOKE_XFER_ACCEPTED event may optionally be generated. This optional event is
disabled by default; after the line device has been opened, the event can be enabled or disabled at
any time by use of the gc_SetConfigData( ) function.
The primary call may be terminated by either party before transferred call is completed. Unlike an
H.450.2 transfer, party A in a SIP transfer will not get any transfer termination event if party A
terminates the primary call before receiving final status from party B. This is because there is no
way to be sure if the transfer is successful or if it failed and it is 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 GCEV_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.
3.3.2.2 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