Overview

SMS messages from the same foreign Short Message Service Center (SMSC) are being discarded when processed by certain routers, but are delivered by another router. Within the traces, you see that messages are rejected with TCAP-Abort reason of “Application-context-name-not-supported.” No SRI SM request to HLR from the SMSC.

Solution

This behavior is most often seen when the affected source MSISDN is not correctly defined within the Network Ranges for the Operator, or the Operator has not been defined within Lithium.

Verifying the Operator Configuration

1. Open WireShark and collect and a trace of the rejected message.

2. Filter on TCAP messages and look for TCAP aborts in the failed case trace response to the incoming sendRoutingInfoForSM (SRISM) Message. 
   
   
   
   

   1. Expand the Transaction Capabilities Application Part (TCAP) section.

   2. Look for the “application-context-name-not-supported” reason within the dialogueResponse to confirm you identified the correct packet:
      ​​

3. Within the paired SRISM message, this failed message abort was responding to: 

   1. Expand the Signalling Connection Control Part (SCCP) section and collect the Called Party address/digits and verify the Operator for this address:
      ​

   2. Expand the Transaction Capabilities Application Part (TCAP) section and collect the Map version of the message:
      ​ 

4. Using the details collected from the trace above, execute tp_walkall for the identified Operator of the Called Party address.

   1. Within the tp_walkall output, identify the network range.

      1. For Example:

         1. mobNetworkCountry.1 = STRING: "AA"
            mobNetworkOperator.1 = STRING: Example
            mobNetworkNumberRange.1.1 = STRING: "123456789-123456789"

   2. Verify whether the Called Party Address appears within the identified Operator range.

5. Collect the Default Map Phase by running the following:

   1. If the Operator is not defined in the MGR GUI:

      1. tp_walkall | grep -i smsPropDefaultMapPhase.0

   2. If the Operator is defined in the MGR GUI:

      1. tp_walkall | grep -i  mobNetworkMapPhase.<index-number>

      2. Note: <index-number> is the index number within MGR GUI for the specific Operator.

   3. Example:

      1. mobNetworkMapPhase.1 = INTEGER: phase2plus(3)
         ===================================
         smsPropDefaultMapPhase.0 = INTEGER: phase2(2)
         ===================================

   4. Verify whether the Map Phase collected matches the Map version collected from the trace above.

      If the Map Phase value is mismatched with the defined default and either the failing Called Party Address does not appear within the Operator Network Ranges, or the Operator is not defined within Lithium MGR GUI, you will need to make adjustments within the MGR GUI for the Operator.

Correcting the Operator Definitions

To correct the operator definitions, you must either Define the New Operator with the correct Network Ranges including the address identified, or adjust the Network Ranges of the existing Network to include this failing address.

Testing

After making the changes to your Operator definitions within the MGR GUI, the ‘unknown’ MSISDNs will be added to the defined Network Ranges. The SMS should be delivered to the destination MSISDN from the same origins. 

If you encounter any trouble, please open a support ticket, and include the following details:

• Trace of the scenario (Failed case vs. Successful Case)

• Log records from both examples of the same scenario (Failed and Successful cases)

• syslog (/var/log/messages)

• tp_walkall output