Configuration of layer: Difference between revisions

Revision as of 10:45, 9 September 2022

The configuration of the ISUP layer (or addition of new elements to an existing layer) must follow a specific sequence. The following sections will detailed the different resources configuration, their parameters and their use.

General guidelines for the configuration of ISUP for a proper operation include the following:

The ISUP general allocation* must precede all other messages (other configuration ISUP allocation, get, states and stats). The response of this message is an ISUP handle.
The ISUP Network allocation must be made (with the ISUP handle from step 1) for a particular network. The response of this message is an ISUP network handle.
The ISUP userpart allocation must be made (with the ISUP handle from step 1) for a particular switch variant. The response of this message is an ISUP userpart handle.
The ISUP interface allocation must be made (with the ISUP handle from step 1, network handle from step 2 and the userpart handle from step 3) for a particular OPC/DPC. The response of this message is an ISUP interface handle.
The ISUP circuit allocation must be made (with the ISUP handle from step 1 and the interface handle from step 4). The response of this message is an ISUP circuit handle associated with a host-provided handle called the “circuit ID”.

NOTE: For any reconfiguration with an ISUP message, all reconfigurable parameters must be filled appropriately even if the intention is to modify a single parameter, unless specified otherwise.

NOTE: When a reconfiguration is requested through a ISUP API, the effect may not be observed immediately. This is especially true for timers and thresholds as the targeted event might already be active when the reconfiguration occurs. [1] All fields of a configuration (allocation) message must be filled unless explicitly optional or not defined for certain variants.

= All fields of a configuration (allocation) message must be filled unless they are explicitly optional or not defined for certain variants.

@@ Line 1: / Line 1: @@
-The configuration of the [[ISUP]] layer (or addition of new elements to an existing layer) must follow a specific sequence. The following sections will detailed the different resource configuration, their parameters and their respective use.
+{{DISPLAYTITLE:Configuration of layer}}
+The configuration of the [[ISUP]] layer (or addition of new elements to an existing layer) must follow a specific sequence. The following sections will detailed the different resources configuration, their parameters and their use.
-General guidelines for configuration of ISUP for a proper operation include the following:
+General guidelines for the configuration of ISUP for a proper operation include the following:
 # The ISUP general allocation* must precede all other messages (other configuration ISUP allocation, get, states and stats). The response of this message is an ISUP handle.
@@ Line 11: / Line 12: @@
-'''NOTE:''' For any reconfiguration with an ISUP message, all reconfigurable parameters must be filled appropriately even if the intention is to modify only single parameter unless specified otherwise.
+'''NOTE:''' For any reconfiguration with an ISUP message, all reconfigurable parameters must be filled appropriately even if the intention is to modify a single parameter, unless specified otherwise.
-'''NOTE:''' When a reconfiguration is requested through a ISUP API, the effect may not be observed immediately.  This is especially true for timers and threshold as the targeted event might already be active when the reconfiguration occurs.
+'''NOTE:''' When a reconfiguration is requested through a ISUP API, the effect may not be observed immediately.  This is especially true for timers and thresholds as the targeted event might already be active when the reconfiguration occurs.
 [1] All fields of a configuration (allocation) message must be filled unless explicitly optional or not defined for certain variants.