Start a conversation Sign in
Start a conversation
  1. NewNet
  2. NewNet Articles
  3. Articles

Fixing Incorrect DLR Routing in RTR/HUB Forwarding Using Intermediate Cache (iCache)

Overview

In an RTR/HUB forwarding scenario, multiple upstream SMPP applications (for example, app1 and app2) may submit messages that are forwarded to a downstream/3rd-party SMSC. If delivery receipts (DLRs) returned from the downstream SMSC are not routed back to the correct originating upstream application/session (for example, DLR1→app1 and DLR2→app2), the most common cause is missing correlation storage.

In the investigated case, ATIR rules appeared to be configured correctly, but Intermediate Cache (iCache) was not actually enabled/active. Enabling the required AMS storage mode for iCache in common_config.txt and restarting TextPass processes allowed iCache to store correlation records needed for correct DLR-to-app routing.

Solution

Issue

DLRs (deliver_sm) returned from a downstream/3rd-party SMSC are not routed back to the correct originating upstream SMPP application when messages are forwarded through an RTR/HUB.

Symptom / customer-visible error (verbatim)

  • “DLR’s are not router to proper app.”

Common impact

  • In multi-app scenarios (for example, app1 and app2 both submitting messages), DLRs cannot be reliably delivered back to the correct upstream bind/session without correlation data.
  • Without correlation storage, the platform cannot map the downstream SMSC’s receipted_message_id back to the correct upstream app/session.

What was found

Even though routing (ATIR) rules appeared to be set up correctly, iCache was not storing any correlation records. This prevented proper DLR routing back to the originating upstream application/session.

Evidence to confirm the condition

  • tp_walkall: amsPropStorageMode was set to messageStore(0) (not compatible with iCache operation).
  • iCache storage counter: queueCntMasterIcacheRecordsStored... = 0 (no iCache records stored during testing).

Resolution (configuration)

Enable the AMS storage mode required for iCache by updating the semi-static configuration and restarting processes so the change takes effect.

Step-by-step

  1. Log in to the MGR node
    • Use your standard administrative access for the RTR/HUB management node.
  2. Back up the common configuration 
    cd /usr/TextPass/etc
cp common_config.txt common_config.txt.<timestamp>
  3. Edit the common configuration 
    vi common_config.txt

    Add the following line:

    amsstoragemode="messageandtransactionstore"
  4. Validate the configuration 
    tp_config --validatecommonconfig /usr/TextPass/etc/common_config.txt
  5. Restart TextPass processes on all Traffic nodes
    • Plan a maintenance window (brief downtime per node during restart).
    • Run the appropriate stop/start commands used in your environment, for example:
  6. tp_stop
tp_start

Important clarification about parameter naming

  • Documentation name: amsstoragemode
  • tp_walkall presentation: amsPropStorageMode

Validation / how to verify it worked

  1. Re-run tp_walkall and confirm the storage mode reflects message + transaction storage (not messageStore(0)).
  2. Confirm iCache begins storing records (the “records stored” counter should become non-zero during active message/DLR testing).
  3. Re-test the scenario:
    • Send test messages from two upstream apps through the same downstream route.
    • Confirm each DLR returns to the correct originating upstream application (DLR1→app1, DLR2→app2).

If the problem persists

  • Reconfirm ATIR rules still match the intended DLR routing behavior.
  • Reconfirm iCache is enabled under Storage > Intermediate Cache and is sized appropriately for expected throughput.
  • Confirm the restart was performed on all relevant traffic nodes.
  • Collect updated tp_walkall output and iCache counters for further analysis.


Frequently Asked Questions

1. How can this issue be recognized quickly?

If you see behavior like “DLR’s are not router to proper app.” in a multi-upstream-app scenario, check whether iCache is actually storing correlation data. A strong indicator is queueCntMasterIcacheRecordsStored... = 0 while testing DLR flows.

2. What specific settings indicate iCache is not enabled correctly?

If tp_walkall shows amsPropStorageMode = messageStore(0), iCache correlation storage will not function as expected. Set the configuration via amsstoragemode="messageandtransactionstore" in common_config.txt.

3. Do service restarts matter for this change?

Yes. The common_config.txt change requires restarting TextPass processes on the traffic nodes for the new storage mode to take effect.

4. How do I verify after the change that DLR routing is fixed?

Validate that iCache records are being stored (a non-zero “records stored” counter during testing), then run a two-app test where both apps submit messages through the same downstream route and confirm each DLR returns to the correct originating application.

5. Why does the manual mention “amsstoragemode” but tp_walkall shows “amsPropStorageMode”?

amsstoragemode is the configuration key used in the semi-static config file; amsPropStorageMode is how the same setting is surfaced in tp_walkall output.

Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Mohammed Amer

  2. Posted

Comments