Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26ca7f046c8a00a0c86e9b2550016ec54396b5000a, userName='null'}
JIRAIDAUTHSBX-89464124031
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cbee06ac8a00a02355cd1c2f0155cd26ca930499, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb1e054d8a00a02355cd1c2f0155cd26ca930499, userName='null'}


Panel

In this section:

Table of Contents



Info
titleNote

The SBC does not support Relay messages after a call transfer with Replaces.

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

Include Page
call_transfer_for_a_call
call_transfer_for_a_call


The

Spacevars
0series4
 supports call transfers initiated via SIP REFER messages, REFER with Replaces, and INVITE with Replaces. Alternatively, the
Spacevars
0product
 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
Spacevars
0product
 performing the call transfer locally.


Info

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.


SIP REFER Messages

Spacevars
0product
 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:


  1. Party A calls Operator (Party B).

    Caption0Figure1Call Flow -

    The following figure represents an example for "Party A calls Operator" scenario:

    Image Modified


  2. Operator (party B) sends REFER request to transfer Party A to new Party C.

    Caption0Figure1Call Flow -

    The following figure represents an example for "Operator sends REFER" scenario:

    Image Modified


  3. Operator leg then drops out of the call. Result is A-C call.

    Caption0Figure1Call Flow -

    The following figure represents an example for "Operator drops out of call" scenario:

    Image Modified


REFER with Replaces

The 

Spacevars
0product
 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:

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

    Caption0Figure1Call Flow -

    The following figure represents an example for "Party A calls Party B" call flow scenario:

    Image Modified


  2.  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:

    caption

    0Figure
    1Consultative Transfer Using REFER with Replaces
    Image Modified


Info
titleNote

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

Spacevars
0product
 is 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.

Caption0Figure1Call Transfer When SBC is Configured to Relay REFER Requests

The following figure represents an example for call transfer when the SBC is configured to relay REFER requests:
Image Modified


INVITE with Replaces

The SIP INVITE with Replaces message is another SIP call transfer mechanism similar to REFER with Replaces. When the

Spacevars
0product
 receives 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 The following figure below for represents an example call flow.

Caption0Figure1Call Transfer Using

for call transfer using INVITE with Replaces:

Image Modified


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.

Caption

:

0Table1SBC Behavior on Receipt of the
INVITE w/ REPLACES Message
INVITE w/ REPLACES Message
On Matching An Early DialogOn Matching a Confirmed Dialog
With an Early-Only flagThe 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 flagThe 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).

    Note
    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).

    Note
    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:

Caption
0Table
1Supported 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


Note

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:

Code Block
languagenone
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

Authentication Response when the Transferred Call is Challenged

Available_since
TypeAvailable Since
Release10.1.2



pagebreak
Multiexcerpt include
SpaceWithExcerptICD
MultiExcerptNameOverview_SBX-95997
PageWithExcerptICD:SBX-95997 Authentication response from SBC when transferred call is challenged