1. ACLI Configuration Guide
  2. SIP Signaling Services
  3. REFER-Initiated Call Transfer
  4. Supported Scenarios

Supported Scenarios

In the basic scenario for REFER initiated call transfer, a call is established between two User Agents (Alice and Bob). User Agent Bob then sends a REFER request to transfer the call to a third User Agent Eva. With dynamic call-transfer enabled, the Oracle® Enterprise Session Border Controller (ESBC) prevents the REFER from being sent to Alice and generates the INVITE to Eva.

If the INVITE to Eva succeeds, the ESBC sends a re-INVITE to Alice modifying the SIP session as described in Section 14 of RFC 3261, SIP: Session Initiation Protocol. At this point the ESBC cancels the original dialog between the ESBC and Bob.

If the INVITE to Eva fails, call disposition depends on whether or not Bob issued a BYE after the REFER call transfer. If the Oracle® Enterprise Session Border Controller did receive a BYE from Bob (for instance, a blind transfer), it proxies the BYE to A. Otherwise, the ESBC retains the original SIP session and media session, thus allowing Bob to re-establish the call with Alice by sending a re-INVITE. In this case, the ESBC sets a timer (32 seconds), after which a BYE will be sent.

If a REFER method is received containing no Referred-By header, the ESBC adds one, allowing the ESBC to support all call agent screen applications.

In addition, the SIP REFER method call transfer feature supports the following:

  • Both unattended and attended call transfers
  • Both successful and unsuccessful call transfers
  • Early media from the Referred-To party to the transferee
  • REFER method transfer from different sources within the destination realm
  • The REFER event package as defined in RFC 3515. This applies for situations where multiple REFER methods are used within a single dialog.
  • Third party initiated REFER method signalling the transfer of a call by associating the REFER method to the dialogue via the REFER TargetDialog.
  • The Referred-To party can be both in a different realm (and thus a different steering pool) from the referrer, and in the same realm
  • The associated latching should not prohibit the Referred-To party from being latched to while the referee is still sending media.

The ESBC does not successfully handle the following anomalous transfer scenarios:

  • The new INVITE to the Referred-To party gets challenged — the ESBC does not answer the challenge. It is treated with the 401/407 response just as any other unsuccessful final response.
  • The header of the REFER message contains a method other than INVITE or contains URI-parameters or embedded headers not supported by the ESBC.
  • The ESBC shall allow the Referred-To URI that happens to resolve to the same next-hop as the original INVITE went to, to do so.
  • The ESBC ignores any MIME attachment(s) within a REFER method.
  • The ESBC recurses (when configured to do so) when the new INVITE sent to the Referred-To party receives a 3xx response.
  • The transferee indicated support for 100rel, and the original two parties agreed on using it, yet the Referred-To party does not support it.
  • The original parties negotiated SRTP keys.