In this section:
The SBC Core inter-works seamlessly with different types of endpoints on the access side for the successful call completion. With the increased usage of the SBC in the enterprise domain, it is exposed to work progressively with more endpoints, irrespective of their support for the Secure Real-Time Transport Protocol (SRTP), and/or IPv4 or IPv6 or not, on the same Trunk Group. The Retry Profile is used to configure a trigger/action rule to specify that when a particular error response code (and optional warning code) is received (the trigger), the SBC performs a fallback action (fallback SRTP to RTP, fallback to IPV4 or fallback to IPV6). The SBC then reattempts an INVITE with the updated Session Description Protocol (SDP) offer based on the action configured for the received error response and warning code. For a call from the core network towards the access side, the SBC is expected to use SRTP as the primary option towards the access side: If the endpoints do not support SRTP: When the SBC receives an error response, which is configured on the profile and the corresponding action is configured as fallback: The functionality of the If there are multiple rules matching a SIP response code, the exact match of both SIP response code and SIP warning code are executed as a trigger. If initial INVITE is sent with SRTP and IPv4 address and the SBC receives a 488 response code with warning code 301, the trigger action rule 1 is matched and the subsequent INVITE is sent with RTP and IPv4 address in the SDP. Example: If initial INVITE is sent with SRTP and IPv4 address, and the SBC receives a 488 response with warning code 301, the subsequent INVITE is sent with RTP and IPv4 address in the SDP. If this INVITE does not receive any successful response, the INVITE is re-sent with RTP and IPv6 address. If multiple actions are configured for an action set, the new INVITE must be sent based on the combination of all the actions specified in the action set. If initial INVITE is sent with SRTP and IPV6 address, and the SBC receives a 488 response code with 301 warning code, subsequent INVITE is sent with RTP and IPv4 address in the SDP. The subsequent INVITE is sent as a combination of the actions specified in the action set1. If a specific match (SIP response code and SIP warning code) is not found in the If initial INVITE is sent with SRTP and IPv6 address, the SBC receives a 488 response code with 301 warning code. As specific match for both response code and warning code is not found in the profile, the next match for the "Response code" is searched and the new INVITE is sent with RTP and IPv4 address in the SDP. When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the Call Flow - Scenario 1 When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the If the response code is configured on the The SBC retries the call to the same peer with RTP and IPv4 address in the SDP. If the profile is not configured or the response code is not present in the profile, the SBC functions with the existing behavior. Call Flow - Scenario 2retryProfile
is configured, it takes precedence over cranback/redirection/maddr handling functionality.retryProfile
is not associated with the IPTG, the SBC functions with the existing behavior.SRTP to RTP Fallback Support
IPV4/IPV6 Inter-working Support
Retry Profile
retryProfile
is explained as follows:
Example:triggerActionRule Rule 1
{
Response Code: 488
Warning Code: 301
Action Set1:
{
Fallback from SRTP to RTP
}
}
triggerActionRule Rule 2
{
Response Code: 488
Action Set1:
{
Fallback to IPv6
}
}
The execution is stopped when:
triggerActionRule Rule 1
{
Response Code: 488
Warning Code: 301
Action Set1:
{
Fallback from SRTP to RTP
}
Action Set2:
{
Fallback to IPv6
}
}
Example:
triggerActionRule Rule1
{
Response Code: 488
Warning Code: 301
Action Set1:
{
Fallback from SRTP to RTP
Fallback to IPv4
}
}
retryProfile
, the SBC searches for the response code in the profile and the corresponding action is executed.
Example:triggerActionRule Rule1
{
Response Code: 488
Action Set1:
{
Fallback from SRTP to RTP
Fallback to IPv4
}
}
Call Flows
Scenario 1
retryProfile
linked to the IPTG. If the response code is configured on the profile with the action as fallBackSrtpToRtp
, the SBC retries the call to the same peer with RTP in the offer. If the Retry profile is not configured or the response code is not present in the profile, the SBC functions with the existing behavior.Scenario 2
retryProfile
linked to the IPTG.retryProfile
with the following actions:
Perform the following steps:
To configure a retryProfile
with trigger action rule, execute the following commands based on the action type:
When Action Type is set as fallBackSrtpToRtp
:
% set profiles services retryProfile rp1 triggerActionRule 2 sipResponseCode 301 sipWarningCode 333 action 2 actionType fallBackSrtpToRtp % commit
or
When Action Type is set as fallBackSrtpToRtp
and fallBackToIPV4
:
% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackSrtpToRtp,fallBackToIPV4 % commit
or
When Action Type is set as fallBackSrtpToRtp
and fallBackToIPV6
:
% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackSrtpToRtp,fallBackToIPV6 % commit
or
When Action Type is set as fallBackToIPV4
:
% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackToIPV4 % commit
or
When Action Type is set as fallBackToIPV6
:
% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackToIPV6 % commit
To enable the Retry profile and the attempt record generation option, execute the following command:
% set profiles services retryProfile rp1 attemptRecordGeneration enabled state enabled % commit
% set addressContext default zone z1 sipTrunkGroup TG1 services retryProfile rp1 % commit