The SBC Core provides a preconditions support feature to reserve network resources as a preventative measure to minimize chances of session failure due to lack of resources before alerting the called party. This prevents a "ghost ring" where the called party is alerted before the call is set up.
The SBC Core supports preconditions interworking functionality only when one leg of a call supports preconditions and other does not. The SBC supports preconditions functionality on either of the legs (egress or ingress). With this feature, preconditions interworking is decided based on the precondition profile configuration, present in the Common IP Attributes of the IP Signaling Profile (IPSP).
This feature supports ISUP-SIP and SIP-SIP preconditions interworking, and provides transparency by dropping/adding of preconditions attributes between supporting or non-supporting peers. The preconditions are configured from the SBC at the SIP Trunk Group level using the parameters “preconditions” (for incoming requests) and “transmitPreconditions” (for outgoing requests).
The SBC Core completes the ingress preconditions when the call terminates at the PSX script. Users can configure the list of script names (in the psxScriptProfile
) for which the SBC performs ingress preconditions interworking. The ingress preconditions trigger when one of the configured script names matches with the PSX returned script name. The script execution continues after the ingress preconditions are met.
NOTE: The SBC allows a maximum of three script names to configure. The configurable script name is the same as the script name that the PSX returns.
The pemInterworking
flag inhibits sending the P-Early Media header in the first 18x response for the ingress preconditions interworking scenario.
The SBC adds a P-Charging-Vector header with the termIOI
parameter to the 18x response sent to the ingress network. The termIOI
parameter sends the terminating networking identifier to the ingress network. The SBC creates and sends the termIOI
parameter when there is no egress network, which occurs when the call is terminated in the script. When there is an egress network, the termIOI
parameter is received from the egress network.
NOTE: The termIOI
parameter is configured in the Signaling SIP Trunk Group.
NOTE:
For in-depth details of SBC preconditions interworking and preconditions profile flags interactions, refer to Reserving Network Resources.
IP Signaling Profile - Common IP Attributes - Preconditions
The following are the parameter descriptions:
Preconditions Profile Parameters
Parameter | Range | Description |
---|
State | N/A | Enable this flag to activate the Preconditions Profile configuration. NOTE: The remaining Preconditions Profile configuration options (listed below) are available once this preconditions State flag is enabled. |
Support If Egress IPTG | N/A | Enable this flag during session offer processing to have the SBC assume preconditions support for entities on the egress trunk group. NOTE: The SBC does not associate semantics with this field from the ingress IPTG perspective. |
Strength Mandatory Policy | N/A | Enable this flag for the SBC to determine whether preconditions interworking is required on the ingress leg. NOTE: The precondition strength is mandatory in the precondition attribute and the Support If Egress IPTG flag is disabled. |
Strength Optional Policy | N/A | Enable this flag to determine whether precondition inter-working is required on the ingress leg. NOTE: The precondition strength is optional in the precondition attribute and the SupportIfEgressIPTG flag is disabled. |
UPDATEPreconditions Policy | NA | Enable this flag for the SBC to indicate whether local preconditions are met with the initial INVITE or with a subsequent UPDATE on the egress leg. NOTE: This flag is significant when egress leg supports precondition based on the configuration. |
Strength Mandatory Priority | 1-100 | (Default = 1) Enter a value to specify the priority assigned to a call leg. This fields helps in resolving conflicts with selecting the policy. If the StrengthMandatoryPriority flag is enabled on one call leg, but disabled on the other call leg, the SBC considers the priority assigned to the policy on each call leg to select the policy and selects the policy with the higher priority. When the two call legs have the same priority, the SBC selects the policy on the ingress leg. NOTE: Priority is inversely proportional to the value of digit. Lower the digit value, higher the priority. For example, priority 1 takes precedence over priority 2. |
Strength Optional Priority | 1-100 | (Default = 1) Enter a value to specify the priority assigned to a call leg. This parameter helps in resolving conflicts with selecting the policy. If the StrengthOptionalPolicy flag is enabled on one call leg but disabled on the other call leg, the SBC accounts the priority assigned to policy on each call leg to select the policy. The SBC selects the policy which has higher priority. When the two call legs have the same priority, the SBC selects the policy on ingress leg. NOTE: The priority is inversely proportional to the value of digit. The lower the digit value, the higher the priority. For example, priority 1 takes precedence over priority 2. |
UPDATEPreconditions Priority | 1-100 | (Default = 1) Enter a value to specify the priority assigned to a call leg. This field helps in resolving the conflicts with selecting the UPDATE policy. If the UPDATE policy is enabled on one call leg, but disabled on the other call leg, the SBC considers the priority assigned to each UPDATE policy to select the UPDATE policy. In such cases, the SBC selects the UPDATE policy with higher priority. When the two call legs have the same priority, the SBC selects the policy on ingress leg. NOTE: The priority is inversely proportional to the value of digit. The lower the digit value, the higher the priority. For example, priority 1 takes precedence over priority 2. |
Make the required changes and click
Save to save the changes made.