1. Configuration Guide
  2. SIP Signaling Services
  3. SIP REFER with Replaces

SIP REFER with Replaces

To support enterprise and call center applications, the Oracle® Enterprise Session Border Controller (ESBC) provides the ability for one party participating in a three-way call to request direct connectivity between the other two parties and to leave the call silently when that connectivity is established. SIP supports this function using the Replaces header in a REFER message, also known as REFER with Replaces.

A typical example of a refer with replaces flow includes three parties:

  • Transferee—A customer who calls into a company's service department.
  • Transferor—The service department's IVR/ACD, which manages the transfer.
  • Transfer-Target—The agent who ultimately talks with the customer.

To support the SIP REFER, the ESBC first establishes calls from the transferee to the transferor (Call 1) and from the transferor to the transfer-target (Call 2). After establishing these calls, the ESBC receives a SIP REFER from the transferor and manages the SIP and SDP signaling to replace Call 2 with a new call, Call 3, which is between the transferor and the transfer-target.

As shown below, call replacement consists of SIP ReINVITEs and associated messaging to establish flows for Call 3. This setup is subject to timing, compatibility and other hurdles that could cause the REFER to fail. Assuming successful setup, the ESBC subsequently issues BYEs for Call 1 and Call 2 and supports any further signaling for Call 3.

This call flow shows an IVR using the REFER with Replaces feature to transfer a call to an agent.

The common high-level sequence of a REFER with REPLACES application includes:

  1. The transferee calls a customer service line and reaches, via the ESBC, an Interactive Voice Response system/Automatic Call Distribution (IVR/ACD) system. In some architectures, these are two separate elements, but can always be understood as the transferor.
  2. Based on the customer’s selection from the menu of options, the IVR/ACD contacts an agent, the transfer-target, via the ESBC.
  3. Since the ultimate goal is for the IVR/ACD to drop out of the path, it sends a REFER with Replaces to the ESBC. This message indicates the ESBC should replace the IVR/ACD endpoint in the call leg with the transfer-target’s endpoint.
  4. The ESBC processes the REFER with Replaces, issuing ReINVITEs to the transferee with the agent’s parameters.
  5. There are multiple significant behaviors that the ESBC performs after the Re-INVITE, including:
    • Retains the original sessions and dialogs intact, supporting any subsequent REFER attempt by the transferor.
    • Manages SDP such that, in the case of attended transfer, it:
      • Sends a Re-INVITE without SDP to the transfer-target.
      • Sends Re-INVITE with updated SDP to transferee, based on 200OK SDP received from the transfer-target.
      • Sends ACK with new SDP to transfer-target, based on 200OK SDP received from the transferee. (This behavior can be changed for backward compatibility.)
    • Waits for a final success response to the Re-INVITE retaining both the transferee-to-transferor and transferor-to-transfer target call legs until it receives indications of success or failure. If there is a failure response, the ESBC sends the failure response to the transferor using a SIP NOTIFY, relying on it to either issue another REFER or release the calls.

      Note:

      the ESBC only handles 4xx, 5xx and 6xx error responses for the REFER ReINVITE towards the Transfer Target.

      An example of such a failure is the receipt of a Re-INVITE from the transfer-target at the same time the ESBC sends a Re-INVITE to the transfer-target. To manage this sequence, the ESBC accepts the ensuing 491 Request Pending message from the transfer-target and:

      • Sends a SIP NOTIFY to the transferor indicating the transfer failed due to a 491 Request Pending,
      • Retains both calls, then
      • Waits for the transferor to issue a new SIP REFER in an attempt to complete the transfer.
    • If it receives a BYE from the transferee after it has sent a Re-INVITE (with SDP) to the transfer-target, the ESBC sends 2 BYEs to the transferor, one for the transferee to transferor leg and one for the transferor to transfer-target leg, and also sends 1 BYE to the transfer-target for the transferor to transfer-target leg.
  6. The IVR/ACD drops out of the media path once the bridged call between the transferee and the transfer-target is established.

Direct media connectivity between endpoints must be possible in order for the REFER with Replaces to be carried out properly.

For example, if both endpoints (such as the customer and agent from the example above) are behind the same firewall, direct media connectivity should be possible. However, if one endpoint is behind a firewall and the other is not, then direct media connectivity may not be possible.

Note also that the ESBC complies with RFC 3264 by retaining identical o= line in the SDP when issuing an offer that modifies the session with the exception that it increments the sess-version value by one. This helps maintain SDP consistency across the dialog.

For licensing capacity purposes, note that a bridged session counts as a single call. Note also that the ESBC supports attended call transfers during HA switchover.

Sending Offerless Responses to Re-Invites

By default, the ESBC sends SDP in responses to Re-INVITEs to the transfer-target. This supports changes to the SDP during attended transfers. If desired, you can configure the ESBC to send offer-less responses to the Re-INVITE to the transfer target. You configure this by enabling the refer-reinvite-no-sdp parameter on the sip-config. This is a global configuration