This feature introduces the functionality of relaying REFER with Replaces support on SBC CNF architecture. Previously, the CNF architecture could have multiple SC pods where the calls are distributed across all the available SC (Session Control) pods. The SLB (Load Balancer) distributes the incoming calls across SC pods. As a result of this load balancing, two associated calls may be hosted on two different SC pods in an attended call scenario. In this scenario, relaying REFER with the Replaces feature enables the application server sitting next to the SBC to bridge the transferee and transfer target.

The CNF architecture supports relaying REFER with Replaces when two calls are hosted on a single SC pod. If the two calls are spread across two different SC pods, then the calls can't be bridged using the attended transfer feature. Design enhancements are introduced in both a single SC Pod scenario and a Multiple SC Pod scenario to support this functionality of attended transfer using relaying of REFER with Replaces.

When two calls are hosted on two SC pods, the SBC receives a REFER with Replaces and identifies where the second call is hosted by decoding the other SC pod instance ID from the "tags" in the Replaces information. Once the other SC pod instance ID is found, it sends a dialog lookup request back to the other SC pod, gets the details in response, and sends the same in the REFER relay to its associated call leg where REFER is received.

Relaying Refer with Replaces - Single SC Pod

In the following call scenario, the transferor (UE1) has its two associated calls on a single SC pod instance. It sends REFER on the first call with the second call's Replaces information, allowing the SBC to relay the REFER with Replaces to its associated call leg. While relaying, the SBC translates and sends the Replaces parameters to the associated call leg. The SBC already supports this call scenario.

The PSX Refer To Header Relay flag controls the translation of the Replaces parameter.

Relaying Refer with Replaces - Multiple SC Pods

In the following call scenario, the transferor (UE1) has its two associated calls hosted on two different SC pod instances. When the SBC receives a REFER with Replaces, it identifies where the second call (UE2) is hosted by decoding the other SC pod instance ID from the "tags" in the Replaces information. Once the other SC pod instance ID is found, it sends a dialog lookup request back to the other SC pod, gets the details in response and sends the same in the REFER relay to its associated call leg where REFER is received.

Limitations

Processing of Refer with Replaces is not supported locally on the SBC when the two associated calls with the transferor are hosted on two different SC pods.