☰
Navigation :

Action Rules

Action Rules

Many of the N2IWF’s rule definitions are “action rules” - rules that specify that an action be taken on the network. Such rules require an action parameter to be given. Other parameters within the rule can be used for selector rule matching or to supply additional information for the action.

Rules are applied in the order listed until a match is made.

If a rule does not specify any matching criteria, it will always match; this should only be used as a catch-all.

Once matched, various actions can be taken according to the input protocol.

Common Actions

The following actions are available for all input protocols.

Action Applies To Description
continue (all except
Error Handling)		 Continue the network session normally with rating interaction where applicable.
release (all) Release the network session immediately.
free (all except
Error Handling)		 Allow the network session to continue unmonitored on the network with no further rating interaction.
grace (all except
Post-Rating)		 Allow the network session to continue monitored on the network within limits with no further rating interaction.

Input protocols may allow additional parameters for these actions, as well as allow other protocol-specific actions to be taken.

Error Handling Rules

If a session cannot be handled normally due to an error (e.g. failure to find a value for a mandatory variable), N2IWF can be configured to behave differently depending on the available information.

Error handling rules are defined in the ERROR_HANDLING LogicApp service global variable.

An example of error handling rules using the SCP input protocol for CAMEL/INAP calls might be:

<global name="ERROR_HANDLING" type="array">
    <rule forwarding="1" var_1="msc" value_1="6421001100" action="abort" />
    <rule var="network" value="home" action="divert" divert_to="123" announcement="ann99" />
    <rule var="network" value="national_roaming" action="release" announcement="ann98" />
    <rule var_1="network" value_1="roaming" var_2="bearer" value_2="voice" action="divert" divert_to="123" />
    <rule var_1="network" value_1="roaming" var_prefix="msc" value="61" action="abort" />
</global>

The below default rules are always applied after all configured error handling action rules to act as a fallback. They may not be disabled, but earlier rules will be used in preference (including rules with no selectors which will always be chosen as fallbacks):

    <rule action="release" />

Pre-Rating Rules

Some sessions may not need to be sent to the OCS for rating and can be handled directly by the N2IWF. Pre-rating rules can be defined that allow behaviour to be specified in such cases. Note that any action other than continue in a pre-rating rule will cause the session to not be sent to the OCS for rating.

Pre-rating rules are defined in the PRE_RATING LogicApp service global variable.

An example of pre-rating rules using the SCP input protocol for CAMEL/INAP calls might be:

<global name="PRE_RATING" type="array">
  <rule service.cug="!" service.cug.list_disallowed="1" action="release" />
  <rule normalised_called_party="123" action="free" />
  <rule normalised_called_party="787" action="grace" seconds="300" />
</global>

Pre-rating rules do not have any default rules. If no rules apply, no pre-rating will occur.

Post-Rating Rules

Post-rating rules may be defined to control N2IWF behaviour at the conclusion of a session.

All post-rating rules are only applicable after the session has been completed (whether successfully or unsuccessfully).

No action will be performed if the calling party is no longer connected or if the action is not supported by the input protocol during post-rating, but other directives such as notifications may still apply.

An example of post-rating rules using the SCP input protocol for CAMEL/INAP calls might be:

<global name="POST_RATING" type="array">
  <rule service.edp="busy" action="release" cause="edp" />
  <rule service.edp="no_answer" service.forward="1" action="free" />
</global>

Looping

Looping can be requested by any matched rule during processing, up to and including post-processing rules.

When a loop has been requested, the N2IWF will finish processing post-rating rules and then jump back to variable population. As part of this jump:

In practice, this means that a looped session is presented identically the next time through. This can be useful for cases such as First Call Activation where the caller is required to be diverted to another destination before being allowed to continue their original call.

Note that only one loop can occur. If looping is requested while looping, it will be ignored during post-rating.

Result-Code Rules

When Diameter answer messages are received from the OCS, the application can be configured to behave differently depending on the Result-Code value received. Rules are applied in the order listed until a match is made to the received value.

Result-Code rules are defined in the RESULT_CODES LogicApp service global variable.

Each rule can specify either a single code or an inclusive range of codes for matching.

An example of error handling rules using the SCP input protocol for CAMEL/INAP calls might be:

<global name="RESULT_CODES" type="array">
  <rule class="free" action="free" />
  <rule code="2002" service.loop_number="0" service.at_update="0" service.at_terminate="0" action="divert" divert_to="234" loop="1" />
  <rule code="2003" service.at_update="0" service.at_terminate="0" var="network" value="!roaming" action="continue" sci="sci-100" />
  <rule code="2004" service.at_terminate="0" var="network" value="!roaming" action="continue" notification="notf1" />
  <rule code="4012" service.at_terminate="0" var="network" value="home" action="release" announcement="ann1" />
  <rule code="4012" service.at_terminate="0" var="network" value="national_roaming" action="divert" announcement="ann5" divert_to="123" />
  <rule code="4012" service.at_terminate="0" var="network" value="roaming" action="release" cause="16" notification="notf2"/>
</global>

The below default rules are always applied after all configured Result-Code action rules to act as a fallback. They may not be disabled, but earlier rules will be used in preference (including rules with no selectors which will always be chosen as fallbacks):

    <rule class="success" action="continue" />
    <rule class="free" action="free" />
    <rule class="comm_fail" is_bf="true" action="release" />
    <rule action="release" />

Selector Rule Extensions

In addition to the standard IWF selector rule extensions, Result-Code rules support additional parameters:

Attribute Type Description
from Integer [Required with to] The start (effective)[#effective-result-code] Diameter Result-Code for an inclusive range match. If provided, to must also be set, and must be greater than or equal to the from value. Mutually exclusive with code and class.
to Integer [Required with from] The end (effective)[#effective-result-code] Diameter Result-Code for an inclusive range match. If provided, from must also be set, and must be less than or equal to the to value. Mutually exclusive with code and class.
code Integer A single (effective)[#effective-result-code] Diameter Result-Code to match on for rule selection. Mutually exclusive with from, to, and class.
(Default: all codes)
class String A single (effective)[#effective-result-code] Diameter [Result-Code class](#result-code-classes] to match on for rule selection. Mutually exclusive with from, to, and code.
(Default: all classes)
is_bf Boolean Whether this rule represents a failure at the billing layer (and therefore may require post-call adjustment). When matched, will mark the EDR created as experiencing a billing failure.
(Default: false)

Effective Result-Code

The Result-Code at the Diameter Multiple-Services-Credit-Control level, if any, takes priority over the Result-Code at the root level. If the action applied for the Multiple-Services-Credit-Control → Result-Code is anything other than continue, the rating session will be closed on the OCS if required (i.e. if the root Result-Code was 2xxx).

Note that there are two special cases where a Result-Code will be generated and used to determine the action to take:

Result-Code Classes

Result-Code values received from the OCS are mapped into a class, in order:

These classes can be used within Result-Code rules using the class selector rule extension.