REFER-Initiated Call Transfer
In prior releases, the Oracle Communications Session Border Controller supported REFER-initiated call transfer either by proxying the REFER to the other User Agent in the dialog, or by terminating the received REFER and issuing a new INVITE to the referred party. These static alternate operational modes could be configured for specific SIP interfaces, realms, or session agents.
Release S-C6.2.0 enhances support with an additional operational mode that determines on a call-by-call basis whether to proxy the REFER to the next hop, or terminate the REFER and issue an INVITE in its stead.
Note:
With the release of Version S-C6.2.0, support for REFER-initiated call transfer is no longer available for SIP interfaces; support must be configured for realms and/or session agents.Version S-C6.2.0 provides a new configuration parameter dyn-refer-term, and a revised refer-call-transfer parameter (both available in realm-config configuration mode) that specify call transfer modes.
With the refer-call-transfer parameter set to disabled (the default), all received REFERs are simply proxied to the peer User Agent.
With the refer-call-transfer parameter set to enabled, the Oracle Communications Session Border Controller terminates all REFERs, generates a new INVITE, and sends the INVITE to the address in the Refer-To header.
With the refer-call-transfer parameter set to dynamic (a new value introduced with Version S-C6.2.0), the Oracle Communications Session Border Controller determines REFER handling on a call-by-call basis as follows:
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 Communications Session Border Controller (OCSBC) prevents the REFER from being sent to Alice and generates the INVITE to Eva.
If the INVITE to Eva succeeds, the OCSBC 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 OCSBC cancels the original dialog between the OCSBC 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 Communications Session Border Controller did receive a BYE from Bob (for instance, a blind transfer), it proxies the BYE to A. Otherwise, the OCSBC 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 OCSBC sets a timer (32 seconds), after which a BYE will be sent.
If a REFER method is received containing no Referred-By header, the OCSBC adds one, allowing the OCSBC 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 OCSBC does not successfully handle the following anomalous transfer scenarios:
- The new INVITE to the Referred-To party gets challenged — the OCSBC 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 OCSBC.
- The OCSBC 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 OCSBC ignores any MIME attachment(s) within a REFER method.
- The OCSBC 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.
REFER Source Routing
If, after the conclusion of static or dynamic REFER handling, the REFER is terminated and a new INVITE issued, users now can specify a policy lookup behavior based upon either the source realm of the calling party (the INVITE originator), or the source realm of the referring party (the REFER originator).
Behavior is controlled by a new refer-src-routing parameter in the sip-config configuration element.
disabled, the default value, specifies that the Oracle Communications Session Border Controller performs a policy lookup based on the source realm of the calling party.
enabled specifies that the Oracle Communications Session Border Controller performs a policy lookup based on the source realm of the referring party. Note: Enable refer-src-routing when refer-call-transfer is set to dynamic.
