SIP REFER Method Call Transfer
In prior releases, the Oracle® Enterprise Session Border Controller supports the SIP REFER method by proxying it to the other UA in the dialog. A handling mode has been developed for the REFER method so that the Oracle® Enterprise Session Border Controller automatically converts a received REFER method into an INVITE method, thus allowing the Oracle® Enterprise Session Border Controller to transfer a call without having to proxy the REFER back to the other UA.
This function can be configured for a specified realm or session agent. When both elements have the SIP REFER method call transfer functionality configured, the session-agent configuration takes precedence over realm-config.
The Oracle® Enterprise Session Border Controller has a configuration parameter giving it the ability to provision the handling of REFER methods as call transfers. The parameter is called refer-call-transfer. When this feature is enabled, the Oracle® Enterprise Session Border Controller creates an INVITE message whenever it receives a REFER. The Oracle® Enterprise Session Border Controller sends this INVITE message to the address in the Refer-To header. Included in the INVITE message is all the unmodified information contained in the REFER message. The previously negotiated codec is also still used in the new INVITE message. NOTIFY and BYE messages are sent to the UA upon call transfer completion.
If a REFER method is received containing no Referred-By header, the Oracle® Enterprise Session Border Controller adds one, allowing the Oracle® Enterprise Session Border Controller 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 transforee
- 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.
Unsuccessful Transfer Scenarios
The Oracle® Enterprise Session Border Controller does not successfully handle the following failed, unusual, and unexpected transfer scenarios:
- The new INVITE to the Referred-To party gets challenged, the Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller.
- The Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller ignores any MIME attachment(s) within a REFER method.
- The Oracle® Enterprise Session Border Controller 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.
- The original parties agreed on a codec using a dynamic payload type, and the Referred-To party happens to use a different dynamic payload number for that codec.
