Versions Compared

Old Version 6

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Add_workflow_for_techpubsAUTH1REV5REV6REV3REV1
Panel

In this section:

Table of Contents

Info
iconfalse

Related articles:

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

Preconditions Interworking

excerpt
Multiexcerpt
MultiExcerptNamePreconditions Summary

The

Spacevars
0series4
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 

Spacevars
0series4
supports preconditions interworking functionality only when one leg of a call supports preconditions and other does not. The SBC
Spacevars
0product
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 inter-workinginterworking, and provides transparency by dropping/adding of preconditions attributes between supporting or non-supporting peers. The preconditions are configured from the

Spacevars
0product
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.

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.


The CLI syntax is shown below:

Code Block
% 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]
Info
titleInfo

Refer to SIP Trunk Group - Services - CLI for configuration details. 

Preconditions Interworking Using 183 Response

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.

Note
iconfalse
titleNote

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:

  1. IPTGs selected based on the SMM, uses the SMM rules in the same profile for selection and each profile is associated with an IP prefix (since it is attached to an IPTG, which is selected based on an IP prefix).
  2. A parent IPTG is defined as covering all the SMM based IPTGs, and the parent IPTG CAC corresponds to the IP prefix based IPTG.

 

Note
iconfalse
titleNote
  • If an IPTG configured using SMM, and configured in the system, the call is rejected with a code 488 "Request not acceptable here" message.
  • The IPTG is not validated while configuring via SMM; it is validated at the time of execution since IPTGs can be added/deleted in between SMM.

The

Spacevars
0product
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)

Code Block
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> services preconditionIntwkUsing183 <disable|enable>
Note
iconfalse
titleNote
Do not enable preConditionIntwkUsing183 when End-to-End Prack is configured.

Preconditions Interworking Properties

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:

Caption
0Table
1Preconditions Interworking Properties
3Preconditions Interworking Properties
IngressEgressPreconditions Interworking
IPTG-1IPTG-2Requires preconditions interworking in one direction, but not the other direction
IPTG-1IPTG-3Does not require preconditions interworking
IPTG-1IPTG-4Requires preconditions interworking for all calls
The PP is present in  the "Common IP Attributes" of the IP Signaling Profile (IPSP) for the PSX/ERE.

Interworking functionality is triggered, and ingress/egress PP is evaluated only under the following two circumstances:

  • Ingress session offer has precondition attributes and egress TG PP SupportIfEgressIPTG is disabled.
  • Ingress session offer has no precondition attributes and egress TG PP SupportIfEgressIPTG is enabled.
note

 

false
icon
Info
titleNote

Under any other circumstances, precondition interworking is not present and PP the Preconditions Profile does not have any effect.


Precondition Profile Flags Interaction and Outcome

Refer to the table below for flags interactions between the ingress and egress trunk groups. For a description of the flags, see  go to 

Link_in_new_tab
TextSIP Trunk Group - Services - CLI
URLSIP Trunk Group - Services - CLI
section below.

 Case 1:

Ingress session offer has precondition attributes and egress TG PP SupportIfEgressIPTG is disabled.

Caption
0Table
1Precondition Profile Flags Interaction and Outcome
ScenariosIngress Flags AssumptionsEgress Flags AssumptionsSBC Behavior
1IPTG 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

Noteinfo
iconfalse
titleNote

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

Caption
0Table
1Precondition Profile Flags Interaction and Outcome
ScenariosIngress Flags AssumptionsEgress Flags AssumptionsSBC 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 Egress Use UPDATE when Signaling Preconditions Locally Met: Policy will be considered as its priority is more

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 Ingress Use UPDATE when Signaling Preconditions Locally Met: Policy is considered as its priority is more

As value is Enabled in initial outgoing Invite local: not met is sent

Note
iconfalse
titleNotes
If both PP and the flag preconditionIntwkUsing183 is configured, PP has

Multiexcerpt
MultiExcerptNamepreconditions Notes
Info
titleNote
  • 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
    Spacevars
    0product
    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

    Spacevars
    0product
    processes it and sends the INVITE towards the egress.

 

Preconditions Interworking Using 183 Response

The

Spacevars
0product
 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.

Info
titleNote

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

Spacevars
0product
 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:

  1. IPTGs selected based on the SMM, uses the SMM rules in the same profile for selection and each profile is associated with an IP prefix (since it is attached to an IPTG, which is selected based on an IP prefix).
  2. A parent IPTG is defined as covering all the SMM based IPTGs, and the parent IPTG CAC corresponds to the IP prefix based IPTG.
Info
titleNote
  • If an IPTG configured using SMM, and configured in the system, the call is rejected with a code 488 "Request not acceptable here" message.
  • The IPTG is not validated while configuring via SMM; it is validated at the time of execution since IPTGs can be added/deleted in between SMM.

 

The 

Spacevars
0product
 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)

Code Block
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> services preconditionIntwkUsing183 <disable|enable>

Multiexcerpt
MultiExcerptNamepreconditionIntwkUsing183 Notes
Info
titleNote
  • If both Preconditions Profile and the flag 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.
  • Do not enable preConditionIntwkUsing183 when End-to-End Prack is configured.

P - Early Media Preconditions

interworking configured as “Use UPDATE”, user should configure Allow UPDATE flag as well
  • Preconditions interworking configured as “Use UPDATE”, But 183 from peer does not have UPDATE in Allow header, SBC will not send UPDATE and does not take any other action either, so that call timeout timer fires to terminate the call.

    • Interworking

    The parameter pemInterworking is added to the Trunk Group Signaling configuration to control when to send the PEM header during ingress Preconditions interworking for SIP-SIP calls.

    For SIP - SIP / SIP-SIP-T  with preconditions interworking

    The 

    Spacevars
    0series4
    does not add P-early media in the first 183 which is sent to ingress as a part of preconditions interworking. The
    Spacevars
    0product
     relays P-early media received from Egress peer except for the case where the
    Spacevars
    0product
     provides Ringback Tone (RBT). Note that the
    Spacevars
    0product
     must create and send 180 ringing with PEM sendrecv before providing the RBT. If P-early media is not received in 180 ringing coming from the Egress peer, the
    Spacevars
    0product
     needs to create and add P-early media sendrecv to the 180 ringing sent to ingress. 

    For SIP–ISUP with preconditions interworking

    The 

    Spacevars
    0product
    does not add P-early media in the first 183 which is sent to ingress as a part of preconditions interworking. The
    Spacevars
    0product
     needs to create and add P-early media sendrecv to the 180 ringing sent to ingress upon receipt of ACM/CPG from Egress ISUP network before providing the RBT. 

    Call Flows

    This feature supports the following call flows:

    Mobile — “SIP” —

    Spacevars
    0product
     — “GWGW” — GSX — “ISUP” — PSTN
    Mobile — “SIP” —
    Spacevars
    0product
     — “GWGW” —
    Spacevars
    0product
     — “SIP-I/T” — C5IMS
    Mobile — “SIP” —
    Spacevars
    0product
     — “SIP-I/T” — C5IMS

     

    Pagebreak

    Pagebreak