REFER Relay and INVITE with Replaces

Overview

When the SBC establishes a call, the two legs are connected (Ingress and Egress) with the same Global Call Identifier (GCID). If one of the participants initiates a transfer, only one of the SIP call legs (either the Ingress or the Egress) survives. This results in establishing a call, where the legs are connected with different GCIDs. After such successful transfer, the SBC previously did not relay REFER (Or any in-dialog message) as there was no peer leg information available for the old GCID.
This feature enhances the SBC to ensure the peer leg information is available for the surviving legs, which results in relaying in-dialog messages successfully.

The SBC is now enhanced to relay these messages to the other leg for the following scenarios:

Transfer Scenario	Conditions	Relay to Other Leg	SIP/In-Dialog Message Types
Blind transfer through the SBC	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is enabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Attended transfer through the SBC with REFER relay enabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is enabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Attended transfer through the SBC with REFER relay disabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is enabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Blind transfer through the SBC	Either of the connected parties sends an in-dialog SIP message 'relayFlags'  in the IPSP is disabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Attended transfer through the SBC with REFER relay enabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is disabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Attended transfer through the SBC with REFER relay disabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is disabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish
Blind transfer through the SIP In Core with the REFER relay disabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is enabled for that method on the leg that receives this message		In-dialog: info, message, notify, options, and publish
Attended transfer through the SIP In Core with the REFER relay disabled	Either of the connected parties sends an in-dialog SIP message 'relayFlags' in the IPSP is enabled for that method on the leg that receives this message		SIP: info, message, notify, options, and publish

Single SBC

The SBC stores the peer GCID and peer direction (Ingress/Egress) along with the GCID and the direction of the current SIP leg. This peer information is passed to both Ingress and Egress legs whenever a call is marked stable. During the blind transfer scenario, the peer information is passed to the new leg (while constructing a new SIP leg).

Single SBC Call Flows

Expand the following section to view the Single SBC call flows.

SIP In Core

In earlier versions of SBC, for the SIP In Core transfer, the SBC that received the REFER always consumed it. This resulted in multiple SIP In Core legs between the finally connected parties after the transfer. This scenario is not preferred since the SIP In Core SBCs can be at different geographical locations. This leads to a significant lag in the final call. 

The SBC 10.1 is enhanced to optimize the call transfers involving SIP In Core to achieve a single SIP In Core leg between the finally connected parties. The core logic for this optimization is to relay the REFER message from the SBC which receives the REFER to the other SBC of SIP In Core setup.
To achieve this optimization, the SBC constructs and stores new headers for all SIP In Core legs.

X-RBBN-OTG-INFO with information of Ingress Trunk group that received the INVITE.
X-RBBN-DTG-INFO with information of Egress Trunk group towards the end party.

The blind transfer REFER is relayed to other SBC of SIP In Core if the following conditions are met:

• The peer leg of the SBC leg which receives REFER is a SIP In Core leg.

• The policy dip at the SBC which receives the REFER message results in a route with SBC other than one which received the REFER.

The attended transfer REFER is relayed to other SBC of SIP In Core if the following conditions are met:

• The peer leg of the SBC leg which receives REFER with Replaces is a SIP In Core leg.

• The Replaces parameter in REFER references a leg of the dialog to be replaced. The peer leg of replaces leg must be a SIP In Core leg.

For the attended transfer case, while relaying REFER with replaces, the SBC translates the leg in Replaces parameter to its peer leg. This is achieved by selecting the existing IPSP flag "Reject the REFER request if no Match Found". This REFER is processed at the SBC where the peer leg is transferee (not the SIP In Core). This SBC (which receives relayed REFER from the other SBC of SIP In Core) treats it as a blind transfer and generates a new INVITE towards the transfer target. The SBC also adds the Replaces header as it is received in the REFER request. This ensures that the two parties are connected with only a single SIP In Core leg even after multiple transfers. The In-dialog messages information, message, notify, options, and publish are relayed as per the IPSP configuration of the leg sending these messages.

SIP In Core Call Flows

Expand the following section to view the SIP In Core call flows.