Overview

You may have a delta filter with the following configuration:

• Recv Sent Percent = 50%
• Message Limit = 15

Based on that, you perform the following test: you send 15 messages to different recipients and receive more than 8 messages. The result is that the MSISDN is blocked after sending the 15th message. Then, the MSISDN receives more than 8 messages but is still blocked from sending more messages. You expected that the MSISDN would not be blocked after receiving more than 8 messages (50% of the message limit as set in the filter).

Solution

For the application to behave as expected, please follow these steps:

1. In the MGR GUI, create a new EC application with "Distribution Key Dynamic" enabled. That requires configuration in the MGR GUI and the /usr/TextPas/etc/host_config.txt files of each RTR.

2. Create a MOX rule for sending the message to FAF using the new EC application created.

3. Create an MTOX rule and select Message Type as Short Message for sending the message to FAF using the new EC application created.

4. Create a Filter and add Content Condition based on External Application Rule name in the first place. The Delta Filter condition with the desired parameters should come in second place. Then, if you want to enable the Delta filter in monitoring mode at first, keep the Filter Action = Return True so that you can monitor counters and logs.

5. Ensure all other Filters have a Content Condition based on External Application Rule name to avoid duplicated matches.

The changes must be applied to the lab environment and tested before being applied to production.

If needed, you can enable the FAF Delta Debug Mode with the following command:

tp_set --tp_faf fafDeltaDebug.3=2

You can check the current settings with:

tp_walk --tp_faf fafDeltaTable

Here are some excerpts of the FAF Operator Manual that might help you better understand the reasoning behind the instructions above:

3.6.2.9 Filter Conditions

If a condition returns true, the next condition of the same filter is evaluated. If all conditions in the filter return true, the filter is matched. The filter’s action is applied. If a condition returns false, the filter is not matched. The next filters are processed according to their priority.

If a filter does not have any conditions, FAF considers the filter to be matched.


​

4.10.3 Incompatibility With Other FAF Conditions
The delta condition working approach is not compatible with the other FAF conditions. This is because it not only requires different EC application distribution key, but also the fact that a single message will be received by the FAF twice for both originator and recipient counting.
There are two kinds of FAF filter conditions:
1. Those decision making on an individual message like content, EMS and expression filters.
2. Those decision making on historical information of the messages satisfying the same conditions, like bulk, flooding, duplicate and volume filters.
For FAF conditions in category (1), the blocking logic is not affected, but we are wasting FAF resource by doing the match twice. For FAF conditions in category (2), the blocking logic is broken by recording the message twice.
Therefore, it is highly recommended to configure FAF instances to perform the delta condition alone without the other FAF filter conditions.

Testing

Rerun the test to confirm the application is behaving as expected.