Overview

This article explains how to troubleshoot Mobile Terminating(MT) Messages being stuck in the queue. Some of the common symptoms related to this topic are:

• MO messages are received with an SRI response InformServiceCentre (InformSC) parameter with an MW-Status of "sc-AddressNotIncluded(0289)."

• This status is resulting in the MT never being sent, and instead the messages are being perpetually queued.

• MT messages are being sent to the same Foreign Operator without issue when the InformServiceCentre message is not included within the SRI response.
  
  

Workflow

 

 

Instructions

1. Collect a Trace and Verify the MT Delivery Parameters
2. Review Trace of the message containing the InformServiceCentre parameter
3. Verify the MAP Phase of the failed messages
4. Collect More Info for Engineer Review

 

 

Collect a Trace and Verify the MT Delivery Parameters

When you encounter issues with the MT messages not being sent out, this can be the result of the expected behavior of the product. To help verify this, as a first step, you will want to capture a full trace of the failing messages as well as the MT Delivery Parameters on your system to verify whether or not you are currently using the Optimized MT Delivery setting.

There are two common ways of verifying the Optimized MT Delivery parameter:

1. Execute tp_walk smsPropOptimisedMtDelivery and collect the output.
2. In the case of an A2P flow you may check the above parameter directly in the GUI:
   1. Navigate to /SMS Applications/Applications/.
   2. Select the application generating this traffic.
   3. Identify whether the check box for this setting is on or off.

If this parameter has been set to True, you will need to take a closer look at the Trace to verify whether the MNR and MCE flags have been set on the failed messages.

If this parameter is currently set to False, you will need to review the Trace to verify the MAP Phase of the failed messages.

 

 

Review Trace of the message containing the InformServiceCentre parameter

1. Open the full trace PCAP within your preferred Packet Analysis tool (ex. Wireshark).
2. Filter the traffic on the Packet Details using the String "InformServiceCentre."
3. Review the mw-Status section for this invoke and review the Flags.
4. Verify whether the MNRF, MCEF, or MNRG flags have been set to True.

If these flags have been set to True, this indicates that the failed delivery is expected. InformServiceCentre is added based on the standard when the MNRF, MCEF, or MNRG flags are present. Please investigate further why these flags have been set to isolate the cause of the delivery failure.

If these flags appear as False, you will need to Verify the MAP Phase of the failed messages to determine whether the Foreign Operator's Home Location Register has correctly handled the use of this parameter.

 

 

Verify the MAP Phase of the failed messages

Within the Trace for the failed message, you can check for the presence of a TCAP Dialog context to determine whether or not the sendRoutingInfoForSM(SRISM) was being sent over Phase 1 or not.

Within the TCAP details associated with the SRISM, confirm whether or not the dialog context exists. If this is not present, this indicates that the message was sent over Phase 1.

If this is the case, it indicates that the Foreign Operator's HLR is likely mishandling the use of the InformSC operation by including this in the MAP Phase 1 message. You can potentially reach out to them directly to request that they make the necessary adjustments to bring their handling to specifications.

Alternatively, you can make adjustments to the configuration within your environment to prevent the use of MAPv1 using the guidance within SRI result includes mw-Status: sc-AddressNotInlcluded and MT is not sent for certain SFR numbers.

 

 

Collect More Info for Engineer Review

If you find that the failing messages with this InformServiceCentre operation included were being sent over MAP Phase 2 or 3, please collect the following information from your environment and open a support ticket to facilitate a more detailed review:

• Full Trace PCAP
• Output of tp_walkall
• If an LGP node is in use:
  • The output of the following Mysql query:

    • • mysql -uroot -p<password> -Dlgp -e"select * from lgp_inb_msg_<current_date> where mapMsisdn_gsmAddress_number=\"<gsmAddress>\" and smsSubmit_smsRecipient_gsmAddress_number=\"<Recipient_gsmAddress>\" \G" |grep -v NULL

  • Note: Adjust the <Tokens> with the appropriate details before running. If more than one LGP node is in use, it should be run on each of the nodes.
• Output of the following command while the messages are stuck in the queue:

  • tp_qcli -s -r=<Recipient_gsmAddress> -v=3

  • Note: Adjust the <Token> with the appropriate details before running.
• The SMSC software release version.
• Detail any recent Home Location Register changes.
• Copy of common_config.txt and one of the 'hostname’_config.txt files.