In this section:
The SBC does not support Relay messages after a call transfer with Replaces.
Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
The SBC supports up to 100 call transfers for a call.
The SBC Core supports call transfers initiated via SIP REFER messages, REFER with Replaces, and INVITE with Replaces. Alternatively, the SBC can be configured for REFER Relay to relay the REFER request to a downstream network element (such as an application server) so that the downstream network element performs the call transfer instead of the SBC performing the call transfer locally.
During call transfer, the SBC sends SIP NOTIFY messages toward the transferor regarding the events (such as 100 Trying, 180 Ringing, 200 OK (for INV) ) received from the transfer target. If a 183 Call Progress is received from the Transfer Target, then the SBC will not send a SIP NOTIFY about 183 towards the Transferor.
SBC support of the SIP REFER method can invoke several different call transfer scenarios.
The following example shows a "blind call transfer" using the SIP REFER method:
Party A calls Operator (Party B).
Call Flow - Party A calls Operator
Operator (party B) sends REFER request to transfer Party A to new Party C.
Call Flow - Operator sends REFER
Operator leg then drops out of the call. Result is A-C call.
Call Flow - Operator drops out of call
The SBC support of SIP REFER with Replaces allows a "consultative transfer" between two existing calls. The SIP REFER with Replaces request facilitates invoking such a call transfer as shown in the example below.
The following example shows REFER message using "consultative transfer" operation:
Party A calls Operator leg (B). Operator puts Party A on hold and establishes another call (Party B1 to Party C). Operator then transfers Party A to Party C and operator legs (Party B and Party B1) drop out of the call.
Call Flow - Party A calls Party B
The "consultative transfer" operation is shown in the following diagram:
Consultative Transfer Using REFER with Replaces
Starting with SBC SWe release 8.1, distributed SBC (D-SBC) deployments support REFER (without Replaces) in relay and local processing mode for audio pass-through calls.
Alternatively, the SBC is configurable to Relay all REFER messages received on a given Trunk Group rather than process the call transfer locally. In this configuration, all REFER messages received are relayed to the peer. This is typically used to relay REFER requests to an Application Server which process the call transfer. In addition to the REFER request, the response messages from the Application Server (202 Accepted, 18x Progress, NOTIFY) is relayed.
Call Transfer When SBC is Configured to Relay REFER Requests
The SIP INVITE with Replaces message is another SIP call transfer mechanism similar to REFER with Replaces. When the SBC receives an INVITE with Replaces request, if the Replaces header identifies a call leg that exists on the SBC, the new call leg will replace the call leg specified in the Replaces header. See figure below for an example call flow.
Call Transfer Using INVITE with Replaces
The SBC includes the following INVITE with Replaces messaging:
The SBC allows INVITE w/ REPLACES messages for the following call types:
On Receipt of the INVITE w/ REPLACES Message, the SBC accepts or rejects the new INVITE depending upon the conditions defined in the table below.
SBC Behavior on Receipt of the INVITE w/ REPLACES Message
INVITE w/ REPLACES Message | On Matching An Early Dialog | On Matching a Confirmed Dialog |
---|---|---|
With an Early-Only flag | The SBC accepts the new INVITE by sending a 200-class response and shuts down the replaced dialog by sending a CANCEL message. | The SBC rejects the new INVITE by sending a 486 response (Busy Here) and leaves the matched dialog unchanged. |
Without an Early-Only flag | The SBC accepts the new INVITE by sending a 200-class response and shuts down the replaced dialog by sending a CANCEL message. | The SBC accepts the new INVITE by sending a 200-class response and shuts down the replaced dialog by sending a BYE message. |
The SBC supports multiple call transfers using any of the above mechanisms (SIP REFER, REFER with Replaces, INVITE with Replaces) when the same transfer mechanism is used for each subsequent transfer on the call. Some limitations are imposed when subsequent transfers are performed using a mixture of call transfer features.
The standard SIP REFER (blind transfer) mechanism is the most flexible call transfer feature which can be followed by either of the other call transfer features (INVITE-Replaces and REFER-Replaces). Likewise, if the original transfer is made using INVITE-Replaces or REFER-Replaces, the subsequent transfer can be made via the same feature or using a SIP REFER blind transfer.
Initial Transfer using INVITE-Replaces – When performing the initial transfer using the INVITE-Replaces feature, a subsequent transfer can be performed using INVITE-Replaces or SIP REFER (blind transfer).
Initial transfer using REFER-Replaces – When an initial transfer is performed using the REFER-Replaces feature, a subsequent transfer can be performed using another REFER-Replaces or SIP REFER (blind transfer).
relayReplacesHeader
option), the From and To tags may become reversed causing the peer to reply with 481 “Transaction do not Exist”. The peer was unable to find the dialog. To rectify this, see SMM example below.Relay fragments in NOTIFY body – In order to relay fragments in NOTIFY bodies, the following configuration option was used.
Create sip transparency profile and include “message/sipfrag” as the sipMessageBody type to the profile.
set profiles services transparencyProfile sunil sipMessageBody message/sipfrag
Assign this profile to the egress trunk group.
The supported call transfer combinations (described above) are listed in the table below:
Supported Call Transfer Combinations
First Call Transfer | Subsequent Transfers | ||
---|---|---|---|
REFER | REFER-Replaces | INVITE-Replaces | |
REFER | Yes | Yes | Yes |
REFER-Replaces | Yes | Yes | No |
INVITE-Replaces | Yes | No | Yes |
For deployments using complex call transfer scenarios such as those shown in the above table, Ribbon recommends configuring the SBC to relay call transfer requests to an application server so that the application server can perform the call transfers.
When the SBC is configured for REFER Relay and the relaying of complex call transfer scenarios such as REFER-Replaces are needed, SMM rules such as the following example are required in order to swap the Replaces headers tags:
set addressContext "default" zone "EXT_ACCESS_ZONE" sipTrunkGroup "ACCESS_TG" signaling relayReplacesHeader enabled set addressContext "default" zone "INT_CORVISA_SIP_ZONE" sipTrunkGroup "ACCESS_PL_TG" signaling relayReplacesHeader enabled set addressContext default zone EXT_DVCACCESS_ZONE sipTrunkGroup DVC_ACCESS_TG signaling relayReplacesHeader enabled #Configured the SMM profile SWAP_REPLACES_HDR_TAGS, to swap the to & from tags sent to the endpoints. set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 criterion 1 type message message messageTypes request methodTypes invite set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 criterion 2 type header header name Replaces condition exist set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 1 type parameter paramType generic set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 1 operation store set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 1 from type parameter value "to-tag" set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 1 to type variable variableValue "var1" commit set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 2 type parameter paramType generic set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 2 operation store set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 2 from type parameter value "from-tag" set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 2 to type variable variableValue "var2" commit set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 3 type parameter paramType generic set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 3 operation modify set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 3 to type parameter value "to-tag" set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 3 from type variable variableValue "var2" commit set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 4 type parameter paramType generic set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 4 operation modify set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 4 to type parameter value "from-tag" set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS rule 1 action 4 from type variable variableValue "var1" commit set profiles signaling sipAdaptorProfile SWAP_REPLACES_HDR_TAGS state enabled commit set addressContext default zone EXT_DVCACCESS_ZONE sipTrunkGroup DVC_ACCESS_TG signaling messageManipulation outputAdapterProfile SWAP_REPLACES_HDR_TAGS commit
The SBC supports TG based authentication and surrogate registration for end points. In earlier versions of the SBC, after a SIP REFER call transfer, when the SBC received a 401 to the INVITE towards the transferee, the SBC could not respond with an INVITE with credentials even though the IPTG authentication and surrogate registration configuration was in place. Instead, the SBC would send a SIP NOTIFY message with an indication of the SIP 401 response.
This feature overcomes this limitation and allows the SBC to send an authentication response when the transferred call is challenged.