In this section:

Related articles:

 

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 be configured.

The configurable script name is the same as the script name that PSX returns.

The pemInterworking flag inhibits sending the P-Early Media header in the first 18x response for the ingress preconditions interworking scenario.

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 sceanario, if the remote precondition is met in PRACK, the SBC will be able to process it and send the INVITE towards egress.

For in-depth details of SBC preconditions interworking and preconditions profile flags interactions, refer to Reserving Network Resources.

Command Syntax

% set profiles signaling ipSignalingProfile <profile name> commonIpAttributes preconditions
	State <disable | enable>
	StrengthMandatoryPolicy <disable | enable>
	StrengthMandatoryPriority <1-100>
	StrengthOptionalPolicy <disable | enable>
	StrengthOptionalPriority <1-100>
	SupportIfEgressIPTG <disable | enable>
	UPDATEPreconditionsPolicy <disable | enable>
	UPDATEPreconditionsPriority <1-100>

 

Command Parameters

Preconditions Profile Parameters

ParameterRangeDescription
StateN/A

Enable this flag to activate the Preconditions Profile configuration.

  • disable (default)
  • enable

NOTE: The remaining Preconditions Profile configuration options (listed below) are available once this preconditions State flag is enabled.

StrengthMandatoryPolicy

N/A

Enable this flag for the SBC to determine whether preconditions interworking is required on the ingress leg.

  • disable (default)
  • enable

NOTE: The precondition strength is mandatory in the precondition attribute and the Support If Egress IPTG flag is disabled.

StrengthMandatoryPriority1-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.

StrengthOptionalPolicyN/A 

Enable this flag to determine whether precondition inter-working is required on the ingress leg.

  • disable (default)
  • enable

NOTE: The precondition strength is optional in the precondition attribute and the SupportIfEgressIPTG flag is disabled.

StrengthOptionalPriority1-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.

SupportIfEgressIPTG

N/A


Enable this flag during session offer processing to have the SBC assume preconditions support for entities on the egress trunk group.

  • disable (default)
  • enable

NOTE: The SBC does not associate semantics with this field from the ingress IPTG perspective.

UPDATEPreconditionsPolicyN/A

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.

  • disable (default)
  • enable

NOTE: This flag is significant when egress leg supports precondition based on the configuration.

UPDATEPreconditionsPriority

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.