In this section:
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
SIP REFER Messages
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
REFER with Replaces
The
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 invoked by a REFER with Replaces header request on the Party B leg. The Replaces header indicates that the B leg should replace the B1 leg. The SBC performs this operation by connecting the voice path from A-C and then disconnecting the operator legs B and B1. The resulting call transfer will have the original ingress leg (Party A) connected to the second call's egress leg (Party C).
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.
REFER Relay
Alternatively, the
Call Transfer When SBC is Configured to Relay REFER Requests
INVITE with Replaces
The SIP INVITE with Replaces message is another SIP call transfer mechanism similar to REFER with Replaces. When the
Call Transfer Using INVITE with Replaces
SBC Support for INVITE with Replaces
The SBC includes the following INVITE with Replaces messaging:
- Use the Early-Only flag while processing the Replaces header of the INVITE w/ REPLACES message
- Allow the Call Pickup feature in Alerting state by allowing the INVITE w/ REPLACES of an early dialog
The SBC allows INVITE w/ REPLACES messages for the following call types:
- Calls in Established state—In this case, INVITE w/ REPLACES messages are allowed either on ingress call legs or on egress call legs.
- Calls in Alerting state—In this case, INVITE w/ REPLACES messages are allowed only on egress call legs.
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. |
Multiple Call Transfers Interactions and Limitations
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).
The INVITE-Replaces transfer cannot be followed by a REFER-Replaces transfer. This combination of call transfer features on the same call is not supported.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).
The REFER-Replaces transfer cannot be followed by an INVITE-Replaces transfer. This combination of call transfer features on the same call is not supported.- Replaces header was relayed in the INVITE – When the Replaces header is relayed in the INVITE (using
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.
Supported Call Transfer Combinations
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.
SMM Example to Swap Replaces Header Tags
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