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 Note The configurable script name is the same as the script name that PSX returns. The The SBC adds a P-Charging-Vector header with the Note 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.
The SBC allows a maximum of three script names to be configured.pemInterworking flag inhibits sending the P-Early Media header in the first 18x response for the ingress preconditions interworking scenario.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.termIOI parameter is configured in the Signaling SIP Trunk Group.
Note
- If Preconditions interworking is configured as “Use UPDATE”, configure the Allow UPDATE flag as well.
- If Preconditions interworking is configured as “Use UPDATE” but a 183 from the peer does not have UPDATE in the Allow header, the SBC will not send an UPDATE and does not take any other action, thus a call timeout timer generates to terminate the call.
- Do not set Preconditions to "Required" for interworking scenarios.
During an ingress precondition interworking scenario, if the remote precondition is met in PRACK, the SBC processes it and sends the INVITE towards the egress.
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 |
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 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 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. |
Overview
Content Tools