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 (E-SBC) prevents the REFER from being sent to Alice and generates the INVITE to Eva.

If the INVITE to Eva succeeds, the E-SBC 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 E-SBC cancels the original dialog between the E-SBC 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 E-SBC 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 E-SBC sets a timer (32 seconds), after which a BYE will be sent.

If a REFER method is received containing no Referred-By header, the E-SBC adds one, allowing the E-SBC 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 E-SBC does not successfully handle the following anomalous transfer scenarios:

• The new INVITE to the Referred-To party gets challenged — the E-SBC 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 E-SBC.
• The E-SBC 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 E-SBC ignores any MIME attachment(s) within a REFER method.
• The E-SBC 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.