REFER-Initiated Call Transfer
The Oracle Communications Session Border Controller supportes 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 can be configured for specific SIP interfaces, realms, or session agents.
An additional operational mode can determine 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.
The configuration parameter dyn-refer-term, and refer-call-transfer parameter 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, 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 (SBC) prevents the REFER from being sent to Alice and generates the INVITE to Eva.
If the INVITE to Eva succeeds, the 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 SBC cancels the original dialog between the 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 Communications Session Border Controller did receive a BYE from Bob (for instance, a blind transfer), it proxies the BYE to A. Otherwise, the 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 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 SBC adds one, allowing the 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 SBC does not successfully handle the following anomalous transfer scenarios:
- The new INVITE to the Referred-To party gets challenged — the 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 SBC.
- The 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 SBC ignores any MIME attachment(s) within a REFER method.
- The 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.
Maintaining RBT During Transfers
The SBC may stop sending its configured ring back tone (RBT) to the caller when operating within some transfer scenarios. Applicable scenarios include the presence of network infrastructure that issues a BYE from the callee to the SBC while the transfer is underway. You can configure the SBC to persist with RBT for the duration of the transfer process so the caller does not unexpectedly lose RBT. By default, this configuration is not set, which provides for proper transfer behavior within most infrastructures.
Default refer handling processing includes referencing your refer-call-transfer configuration, which, when enabled, gives the system the ability to provision the handling of REFER methods as call transfers. When this parameter is enabled, the SBC creates an INVITE message whenever it receives a REFER. It then sends this INVITE to the address in the Refer-To header. The SBC includes all the unmodified information contained in the REFER message in this INVITE, and uses the previously negotiated codec. The SBC sends NOTIFY and BYE messages to the UA upon call transfer completion. This behavior is interrupted if the tranferor sends a BYE because the SBC then tears down the flows between itself and both the caller, which carries the RBT, and the transferor.
You can configure the SBC to avoid interruptions to this local RBT being played towards the ingress side (A party) for call transfer scenarios wherein the SBC receives a BYE from the transferor before a 200 OK from the transferee during the call transfer process. To enable this behavior, you set the refer-early-bye-enhancement option in the sip-config, as shown below.
ORACLE(sip-config)# options +refer-early-bye-enhancementWhen you include the "+" sign in this syntax, the system allows previously configured options field values to remain operational. If you do not use the "+" sign, the system removes any other configured options leaving only this option operational.
Note:
If you have set this option and then downgrade to a version that does not support it, the system ignores the option setting.The SBC supports this behavior for HA deployments:
- If the callee triggers the transfer after the switchover, the SBC transfers media using new flows.
- If the HA switchover happens while RBT is ongoing, the SBC does not continue sending RBT on the new active. If the new active receives a refresh REFER/INVITE, it restarts RBT per its normal behavior.
This feature interacts with the following related features:
- refer-call-transfer Required—This feature is applicable only when the REFER is handled locally by the SBC. You must enable refer-call-transfer on the realm or session agent that receives the REFER.
- refer-reinvite
- Enabled—When enabled, this option enables the Refer with Replaces feature on the SBC. This feature is not applicable to scenarios wherein the SBC uses a reINVITE in the existing dialog to complete an attended call transfer. Therefore, this feature requires that you do not enable refer-reinvite. These configurations are actually intended to disable RBT on the applicable flows.
- Disabled—During an attended call transfer scenario with
the refer-reinvite option
disabled, the SBC handles and preserves the media flows
towards the transferee side, which allows
uninterrupted RBT even if the transferor sends a
premature BYE before the Transfer Agent accepts the
(200 OK from C party).
Ultimately, the SBC terminates the flows preserved for RBT whether the attended transfer completed successfully or unsuccessfully.
- refer-reinvite-no-sdp—If you enable refer-reinvite-no-sdp within the sip-config, then the system plays RBT because the SipMedia is retained in SipDialog. In this case, the system does not handle the Premature BYE, instead passing the BYE on to the targets and terminating the calls.
Call Flows
The following call flows depict the SBC attempting to handle RBT during refer scenarios. These images include two scenarios wherein the system does not support, and then does support RBT through the refer processing.
This first scenario is a simple transfer scenarios. Upon receiving a BYE from user agent, the SBC performs its default behavior, which includes the system stopping the RBT and clearing the flow on both sides. This drops the flow from the SBC to A even though it is busy supporting an RBT media flow.
When you set the refer-early-bye-enhancement option, the SBC does not tear down the flow during this blind/attended (Invite) transfer because it detects a pending REFER. Instead, the SBC maintains the flow until the transfer is complete or it receives a 200OK from B.
This scenario depicts the SBC supporting an attended Transfer with Refer-Invite case. You have left the refer-reinvite option disabled at the session and realm. Here, the SBC sends an INVITE in a new dialog and includes the Replaces header. This is used in conjunction with the refer-call-transfer feature
Again, because you have set the refer-early-bye-enhancement option, the SBC does not tear down the flow during this attended Transfer with Refer-Invite case because it detects a pending REFER. Instead, the SBC maintains the flow until after it sends a NOTIFY (200 OK) to B confirming the transfer is complete.
Applicable Logging
The SBC provides debug-level log messages for troubleshooting this feature. DEBUG logs are available to monitor proper processing of the feature. NOTICE logs are also available to track unrecoverable errors. The system captures logs in the log.sipd file, assuming you have enabled DEBUG mode.
Examples of applicable log messages include the following, showing the system recognizing a trigger that results in invoking the feature:
Feb 9 11:30:22.121 [CONFIG] (0) earlyByeEnhancement: true
Feb 9 11:30:25.349 [SESSION] (2) Sipd_is_refer_early_bye_enhancement is ON is_pending true
Feb 9 11:30:25.349 [SESSION] (2) is_pending trueOther examples of applicable log messages include the following, showing the system processing the feature:
Feb 9 11:30:25.349 [SESSION] (2) <sipRefer.cpp:1837> ReferCall::complete_transfer setting the pdialog->dropFlowFlag to true.
Feb 9 11:30:25.349 [SESSION] (2) <sipTrans.cpp:17268> SipClientTrans::drop_media_for_bye dropFlowFlag is true.
Feb 9 11:30:30.365 [TRANS] (2) <sipRefer.cpp:1887> ReferCall::complete_transfer dropFlowFlag is true, dropping the pending flows.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.