In this section:
Modified: for 6.2.2
The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases. Refer to the SBC SIP Transparency Implementation Guide for additional information.
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 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 The SBC adds a P-Charging-Vector header with the 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.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.
The CLI syntax is shown below:
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> services preconditions [none | required | supported] % set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> services transmitPreconditions [none | required | supported]
Refer to SIP Trunk Group - Services - CLI for configuration details.
The preconditions interworking is provided based on a new Preconditions Profile (PP), and the interpretation of what IPTG configuration to apply is driven by the ingress/egress PP configuration. This is required to provide flexibility for environments where mixed combinations of functionality is required as shown in the following table:
Preconditions Interworking Properties
Ingress | Egress | Preconditions Interworking |
---|---|---|
IPTG-1 | IPTG-2 | Requires preconditions interworking in one direction, but not the other direction |
IPTG-1 | IPTG-3 | Does not require preconditions interworking |
IPTG-1 | IPTG-4 | Requires preconditions interworking for all calls |
Interworking functionality is triggered, and ingress/egress PP is evaluated only under the following two circumstances:
SupportIfEgressIPTG
is disabled.SupportIfEgressIPTG
is enabled.
Under any other circumstances, precondition interworking is not present and the Preconditions Profile does not have any effect.
Refer to the table below for flags interactions between the ingress and egress trunk groups. For a description of the flags, go to .
Case 1:
Ingress session offer has precondition attributes and egress TG PP SupportIfEgressIPTG
is disabled.
Precondition Profile Flags Interaction and Outcome
Scenarios | Ingress Flags Assumptions | Egress Flags Assumptions | SBC Behavior |
---|---|---|---|
1 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled/Enabled Preconditions Strength Mandatory: Policy: Disabled Preconditions Strength Mandatory: Priority: 2 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled Preconditions Strength Mandatory: Policy: Enabled Preconditions Strength Mandatory: Priority: 1 | As Egress Preconditions Strength Mandatory: Priority has highest value, its policy is considered Interworking is desired |
2 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled/Enabled Preconditions Strength Mandatory: Policy: Disabled Preconditions Strength Mandatory: Priority: 1 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled Preconditions Strength Mandatory: Policy: Enabled Preconditions Strength Mandatory: Priority: 2 | As Ingress Preconditions Strength Mandatory: Priority has highest value, its policy is considered Interworking is not desired. As Egress IPTG has preconditions: Transparent is configured, Preconditions Parameters is transparently sent to Egress |
3 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled/Enabled Preconditions Strength Mandatory: Policy: Disabled Preconditions Strength Mandatory: Priority: 1 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled Preconditions Strength Mandatory: Policy: Enabled Preconditions Strength Mandatory: Priority: 1 | As priority is same Ingress Preconditions Strength is considered Interworking is not desired As Egress IPTG has preconditions: Transparent is configured, Preconditions Parameters is transparently sent to Egress |
Priority 1 (lowest value) has the highest priority.
Case 2:
Ingress session offer has no precondition attributes and egress TG PP “Preconditions Support If Egress IPTG” = Enabled.
Precondition Profile Flags Interaction and Outcome
Scenarios | Ingress Flags Assumptions | Egress Flags Assumptions | SBC Behavior |
---|---|---|---|
1 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled/Enabled Preconditions Strength Mandatory: Policy: Enabled/Disabled Preconditions Strength Mandatory: Priority: 2 Use UPDATE when Signaling Preconditions Locally Met: Policy:Enabled Use UPDATE when Signaling Preconditions Locally Met: Priority:2 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Enabled Preconditions Strength Mandatory: Policy: Enabled/Disabled Preconditions Strength Mandatory: Priority: 1 Use UPDATE when Signaling Preconditions Locally Met: Policy: Disabled Use UPDATE when Signaling Preconditions Locally Met: Priority: 1 | As Egress Preconditions Support If Egress IPTG: Enabled Irrespective of Preconditions Strength Mandatory: Policy/Priority Interworking is desired and Outgoing Offer will have preconditions with preconditions strength as "mandatory"
As value is disabled in initial outgoing Invite local: met is sent |
2 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Disabled/Enabled Preconditions Strength Mandatory: Policy: Enabled/Disabled Preconditions Strength Mandatory: Priority: 2 Use UPDATE when Signaling Preconditions Locally Met: Policy: Enabled Use UPDATE when Signaling Preconditions Locally Met: Priority:1 | IPTG Flags: Preconditions: Transparent 100rel Support: Enabled
IPSP PP flags: Preconditions Support If Egress IPTG: Enabled Preconditions Strength Mandatory: Policy: Enabled/Disabled Preconditions Strength Mandatory: Priority: 1 Use UPDATE when Signaling Preconditions Locally Met: Policy: Disabled Use UPDATE when Signaling Preconditions Locally Met: Priority: 2 | As Egress Preconditions Support If Egress IPTG: Enabled Irrespective of Preconditions Strength Mandatory: Policy/Priority Interworking is desired and Outgoing Offer will have preconditions with preconditions strength as "mandatory"
As value is Enabled in initial outgoing Invite local: not met is sent |
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.
The SBC supports preconditions interworking for generic call flows based on the ingress IPTG or on the message content of the same IPTG. A new SIP Message Manipulation (SMM) variable is used to determine the applicable IPTG configurables for an initial INVITE, SUBSCRIBE, REGISTER, or an Out-Of-Dialog request.
If support of an IPTG prefix-based Call Admission Control (CAC) together with SMM-based ingress IPTG selection is desired, use IPTGs which are selected based on the SMM. The SMM rules in the same profile are used for the selection, and each profile is associated with an IP prefix (by virtue of being attached to an IPTG which is selected based on IP prefix). A Parent IPTG is defined covering all such SMM-based IPTGs, and the parent IPTG CAC corresponds to the IP prefix-based IPTG.
The presence, absence, or value of a SIP information element such as a proprietary Header or a proprietary Parameter are examples of the type of message contents that trigger the enhanced preconditions.
The message content policy selection is supported through Flexible Policy.
The SBC Flexible Policy supports the selection of the IPTG for the ingress leg though SIP SMM rules. The IPTG that is selected using SMM configuration is applied to all the incoming initial INVITE, initial SUBSCRIBE, initial REGISTER, and/or Out-Of-Dialog request. The CAC is applied to both the IP-prefix based IPTG and the SMM based IPTG.
Support of a IPTG prefix based CAC, along with SMM based ingress IPTG selection, it is accomplished as follows:
The SBC also provides preconditions support for 183 responses using following CLI syntax, (This flag is for specific call flows and is not intended for generic use)
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> services preconditionIntwkUsing183 <disable|enable>
preconditionIntwkUsing183
are configured, the Preconditions Profile takes a higher precedence. Settings of “preconditions=transparent”/”100rel support=yes” on both legs is the only supported configuration for proper precondition interworking functionality.preConditionIntwkUsing183
when End-to-End Prack is configured.