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. Caption |
---|
0 | Figure |
---|
1 | 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 |
---|
0 | Table |
---|
1 | 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 | SBC accepts the new INVITE by sending a 200-class response and shuts down the replaced dialog by sending a CANCEL message. | SBC rejects the new INVITE by sending a 486 response (Busy Here) and leaves the matched dialog unchanged. | Without an Early-Only flag | SBC accepts the new INVITE by sending a 200-class response and shuts down the replaced dialog by sending a CANCEL message. | 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 |
---|
0 | Table |
---|
1 | 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 |
|
Note |
---|
For deployments using complex call transfer scenarios such as those shown in the above table, Sonus 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:
Code Block |
---|
|
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 |