Overview

At times, there could be a failure to deliver an SMS for a specific B-number, and there is no rule to block it.

This article explains how to troubleshoot and solve such situations by following these steps:

1. Investigate the Rule Blocking the Traffic
2. Investigate the GSM Address Conversion Rules

 

---

 

Process

A possible solution is to investigate the rule blocking the traffic (after the B-number has been modified). In this case, there are two issues:

• A change in the B-number.
• A number has been blocked (which should be unblocked ideally).
  

Step 1: Investigate the Rule Blocking the Traffic

1. From the LGP log, identify the rule blocking the traffic:
   
   

   1,trustedMoFwdSm,,2024567890,,,,2,,,3,,,,,,,discardWithNak, matchingMoRoutingRule,MO_BLOCK,,4,,\N,,,,,,,,

   
   
   
2. From the tp_walkall output, investigate the routing rule conditions:
   
   

   moRtgRuleName.11 = STRING: MO_BLOCK moRtgRuleAction.11 = INTEGER: discardWithNak(4) moRtgRuleRecipientCondition.11 = STRING: L6

   
   
   
3. Check the contents of the list condition related to the rule ID identified on the previous step:
   
   

   listName.6 = STRING: BLACKLIST Egypt networks listCondition.6.1 = STRING: M2013* listCondition.6.2 = STRING: M206* listCondition.6.3 = STRING: M207* listCondition.6.4 = STRING: M203* listCondition.6.5 = STRING: M208* listCondition.6.6 = STRING: M204* listCondition.6.7 = STRING: M209* listCondition.6.8 = STRING: M202* listCondition.6.9 = STRING: M205*

   
   
   
   • Based on the recipient list condition, the prefix 202* should be blocked, so the rule works fine.

 Back to top

---

 

Step 2: Investigate the GSM Address Conversion Rules

1. From the tp_walkall output, search for the string gsmAc to find the GSM address conversion rules.
2. Check for the possible matches based on the gsmAcInputAddressPrefix and gsmAcOutputAddressPrefix entries.
   
   For this example, the following two normalization rules can change the prefix to 202.
   • Rule 1
     
     

         gsmAcInputAddressPrefix.1 = STRING: "201"
     
         gsmAcInputNumberingPlanIdentification.1 = INTEGER: isdnTelephony(1)
     
         gsmAcInputTypeOfNumber.1 = INTEGER: unknown(0)
     
         gsmAcInputMinimumAddressLength.1 = Gauge32: 10
     
         gsmAcInputMaximumAddressLength.1 = Gauge32: 15
     
         gsmAcOutputAddressPrefix.1 = STRING: "202"
     
         gsmAcOutputType.1 = INTEGER: msisdn(1)

   • Rule 2
     
     

         gsmAcInputAddressPrefix.2 = STRING: "1"
     
         gsmAcInputNumberingPlanIdentification.2 = INTEGER: isdnTelephony(1)
     
         gsmAcInputTypeOfNumber.2 = INTEGER: unknown(0)
     
         gsmAcInputMinimumAddressLength.2 = Gauge32: 9
     
         gsmAcInputMaximumAddressLength.2 = Gauge32: 9
     
         gsmAcOutputAddressPrefix.2 = STRING: "202"
     
         gsmAcOutputType.2 = INTEGER: msisdn(1)

3. Please check in the traces if other rule conditions (TON, NPI, address length) are met to have a match. If the rule conditions are met, then the system is working as designed. It would then be necessary to modify the configuration if it is not the desired behaviour.
4. For more details, check the rule's ID in MGR GUI > Routing > Address Conversion > Conversion Rules, as well as in the MGR and RTR operator manuals available in the NewNet Download Center.

Back to top

---