Maintaining RBT During Transfers

The ESBC 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 ESBC while the transfer is underway. You can configure the ESBC 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 ESBC creates an INVITE message whenever it receives a REFER. It then sends this INVITE to the address in the Refer-To header. The ESBC includes all the unmodified information contained in the REFER message in this INVITE, and uses the previously negotiated codec. The ESBC sends NOTIFY and BYE messages to the UA upon call transfer completion. This behavior is interrupted if the tranferor sends a BYE because the ESBC then tears down the flows between itself and both the caller, which carries the RBT, and the transferor.

You can configure the ESBC to avoid interruptions to this local RBT being played towards the ingress side (A party) for call transfer scenarios wherein the ESBC 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-enhancement

When 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 ESBC supports this behavior for HA deployments:

If the callee triggers the transfer after the switchover, the ESBC transfers media using new flows.
If the HA switchover happens while RBT is ongoing, the ESBC 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 ESBC. 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 ESBC. This feature is not applicable to scenarios wherein the ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC performs its default behavior, which includes the system stopping the RBT and clearing the flow on both sides. This drops the flow from the ESBC to A even though it is busy supporting an RBT media flow.

This image depicts the system dropping the RBT flow after receiving a BYE from the transferor.

When you set the refer-early-bye-enhancement option, the ESBC does not tear down the flow during this blind/attended (Invite) transfer because it detects a pending REFER. Instead, the ESBC maintains the flow until the transfer is complete or it receives a 200OK from B.

This image depicts the system successfully supporting the RBT flow in this blind attended transfer even though it has received a BYE from the transferor.

This scenario depicts the ESBC supporting an attended Transfer with Refer-Invite case. You have left the refer-reinvite option disabled at the session and realm. Here, the ESBC sends an INVITE in a new dialog and includes the Replaces header. This is used in conjunction with the refer-call-transfer feature

This image depicts the system dropping the RBT flow during this attended Transfer with Refer-Invite case after receiving a BYE from the transferor.

Again, because you have set the refer-early-bye-enhancement option, the ESBC does not tear down the flow during this attended Transfer with Refer-Invite case because it detects a pending REFER. Instead, the ESBC maintains the flow until after it sends a NOTIFY (200 OK) to B confirming the transfer is complete.

This image depicts the system successfully supporting the RBT flow in this attended Transfer with Refer-Invite case even though it has received a BYE from the transferor.

Applicable Logging

The ESBC 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 true

Other 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.