Call Transfers

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.

SIP REFER Messages

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:

1. Party A calls Operator (Party B). The following figure represents an example for "Party A calls Operator" scenario:

   

2. Operator (party B) sends REFER request to transfer Party A to new Party C. The following figure represents an example for "Operator sends REFER" scenario:

   

3. Operator leg then drops out of the call. Result is A-C call. The following figure represents an example for "Operator drops out of call" scenario:

   

REFER with Replaces

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:

1. Party A calls Operator leg (B). Operator puts Party A on hold and establishes another call (Party B¹ to Party C). Operator then transfers Party A to Party C and operator legs (Party B and Party B¹) drop out of the call. The following figure represents an example for "Party A calls Party B" call flow scenario:

   
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 B¹ leg. The SBC performs this operation by connecting the voice path from A-C and then disconnecting the operator legs B and B¹. 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:

   

REFER Relay

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. The following figure represents an example for call transfer when the 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 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. The following figure represents an example for 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:

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:

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

Authentication Response when the Transferred Call is Challenged

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.

• The SBC responds to an authentication challenge to a new INVITE generated after a blind transfer, using TG authentication credentials if TG-based authentication is in place and both transferring and transferred parties are not surrogate registered endpoints.
• The SBC responds to an authentication challenge to a new INVITE generated after a blind transfer, using surviving party surrogate details, if present. Otherwise, it uses the TG authentication credentials.