You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

 Overview

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.

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

NOTEThe termIOI parameter is configured in the Signaling SIP Trunk Group.

For additional details, refer to Reserving Network Resources.

The following is an example of ingress preconditions interworking:

Creating the Preconditions Profiles

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.

Ingress IPSP

 To create the preconditions profile in ingress IPSP, enter the following command:

% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions State enable
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions SupportIfEgressIPTG disable
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions StrengthMandatoryPolicy enable
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions StrengthMandatoryPriority 12
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions StrengthOptionalPolicy disable
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions StrengthOptionalPriority 1
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions UPDATEPreconditionsPolicy enable
% set profiles signaling ipSignalingProfile INGRESS commonIpAttributes preconditions UPDATEPreconditionsPriority 1
commit

 Egress IPSP

 To create the preconditions profile in egress IPSP, enter the following command:

% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions State enable
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions SupportIfEgressIPTG disable
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions StrengthMandatoryPolicy disable
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions StrengthMandatoryPriority 20
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions StrengthOptionalPolicy disable
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions StrengthOptionalPriority 1
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions UPDATEPreconditionsPolicy disable
% set profiles signaling ipSignalingProfile EGRESS commonIpAttributes preconditions UPDATEPreconditionsPriority 2
commit

 Attaching the Ingress and Egress IPSPs to the Trunk Groups

 To attach the ingress IPSP to the ingress Trunk Group, enter the following command:

% set addressContext default zone ZONE1 sipTrunkGroup INGRESS_TG policy signaling ipSignalingProfile INGRESS 
commit

To attach the egress IPSP to the egress Trunk Group, enter the following command:

% set addressContext default zone ZONE1 sipTrunkGroup EGRESS_TG policy signaling ipSignalingProfile EGRESS 
commit

  • No labels