Overview

A partner or foreign SMSC reports one or both of the following about traffic that your SMS firewall handles with Home Routing:

• The SendRoutingInfoForSm (SRI-SM) responses it received for two different MSISDNs contained the same IMSI value (the value is sometimes reported as an "IMEI"), typically a few minutes apart.
• An SMS intended for one subscriber was delivered to a different subscriber.

In the MGR Log Viewer (Logging ► Messages ► Search) you can see two suspectSriSmWithCountryAndNetworkInfo records for different mapMsisdn values that carry the same scrambledImsi value, each with a different real mapImsi and mapMsc returned by the HLR.

Information

This article applies to deployments where an SRI-SM Response (Home Routing) rule with an IMSI generation range is configured ("scrambled" Home Routing / MT anti-spoofing). With "plain" Home Routing (no generation range), the real IMSI is used as the correlation key and the behaviour described below does not occur.

What the repeated value is

When an SRI-SM Response (Home Routing) rule with an IMSI generation range is applied (MGR: Routing ► Home Routing / the SRI-SM Response rule), the firewall does not return the recipient's real IMSI to the SMSC. It stores the HLR's answer (real IMSI, MSISDN, serving MSC/SGSN) in a correlation record, selects a random value from the configured generation range as the key of that record — the generated or "scrambled" IMSI — and returns that key, together with its own Global Title (or an address from firewallmscsgsnaddressinsuspectsrismresponse), in the SRI-SM response.

The value is therefore not an IMEI and not the subscriber's IMSI. The firewall never receives or uses the IMEI in this flow, and the HLR data plays no role in which key is chosen. If the reported value lies inside your IMSI generation range, it is a generated correlation key.

How the MT-ForwardSM is correlated

An MT-ForwardSM carries no recipient MSISDN. The firewall identifies the recipient solely by looking up the IMSI carried in the MT-ForwardSM in its correlation database and installing the MSISDN, real IMSI and MSC/SGSN from the record it finds. Each record exists only on the RTR node that answered the SRI-SM; that is why the SRI-SM response carries that node's own address as the MSC.

Record lifetime and key re-use

• A correlation record lives for firewallmaxintervalbetweensrismandmtfwdsm seconds (SNMP object fwPropMaxIntervalBetweenSriSmAndMtFwdSm, default 60). The timer restarts every time an MT-ForwardSM is correlated with the record.
• When the record expires it is removed and its value returns to the pool. A value is never issued twice while a record for it is still active on the same node, but once released it can be randomly assigned to any subscriber's next SRI-SM.
• Consequently, the same generated value appearing in SRI-SM responses for two different MSISDNs some minutes apart is normal and expected. The two subscribers were not held in the correlation cache at the same time; the value was handed out twice in sequence. With thousands of SRI-SMs per minute, some value is re-issued within minutes all the time.

What happens when an SMSC re-uses old routing information

If the sending SMSC re-uses the routing information (generated IMSI + firewall address) obtained from an earlier SRI-SM — for example on a retry after a timeout, or for a new message to the same recipient — after the record has expired, one of two things happens:

1. The value is currently free. The MT-ForwardSM cannot be correlated and is treated as unsolicited. It is handled according to firewallmtactionforunsolicitedmtfwdsm (fwPropMtActionForUnsolicitedMtFwdSm, default blockwithnoresponse: dropped without any response). The SMSC times out and normally starts the next attempt with a new SRI-SM. These events are counted in smsCntRecvMtWithoutPrecedingSriSmCounter and logged with reject cause unsolicitedMessage. The typical symptom on the SMSC side is a delivery delay of one or two minutes, with the message released right after a fresh SRI-SM (see also Delivery result shows tcapAborted when multiple SMS sent from the same Sender ID).
2. The value has meanwhile been re-issued to another subscriber. The MT-ForwardSM matches that subscriber's live record and, provided the SMSC address checks pass, is delivered to that subscriber. From the firewall's point of view this is a correctly correlated delivery: it cannot distinguish a value issued seconds ago from one that was issued, expired and re-issued.

This is the documented design of the correlation mechanism, not a defect. The firewall's rejection of MT-ForwardSMs "without a preceding SRI-SM" protects only while a stale value is unassigned; the protection against misdelivery relies on the sending SMSC performing a fresh SRI-SM for every delivery attempt that is not part of the original delivery session.

Troubleshooting

Collect the following instead of generic syslog or full tp_walkall outputs:

1. Confirm the value is a generated key. Check the IMSI generation range of the Home Routing / SRI-SM Response rule in the MGR, or run tp_walk sripRtgRuleGeneratedImsiRange on the RTR.
2. Read the settings of the node that answered the SRI-SMs (the Global Title returned as MSC in the SRI-SM responses identifies it):
   tp_walkall | grep -E 'fwPropMaxIntervalBetweenSriSmAndMtFwdSm|fwPropMtActionForUnsolicitedMtFwdSm|sripRtgRuleGeneratedImsiRange|sccpActualAddrGtAddressInfo|smsCntRecvMtWithoutPrecedingSriSmCounter|sysDescr'
   This gives the record lifetime, the unsolicited-MT action, the generation range, the node's own GT, the count of MT-ForwardSMs that could not be correlated (read sysUpTime as well to turn it into a rate) and the software version.
3. Log Viewer search by IMSI value, not by MSISDN (Logging ► Messages ► Search, with a filter on the IMSI fields equal to the reported value, a window of some minutes before and after the incident, and the Hostname column). This lists every SRI-SM that received the value and every MT-ForwardSM that carried it. Compare the timestamps with the record lifetime: records that are more than the lifetime apart (counted from the last MT-ForwardSM that used the value) are sequential re-use. Records on other hosts are expected, because every node draws independently from the same range; they only matter if an MT-ForwardSM reached a node other than the one that issued the value.
4. Log Viewer search for all MT-ForwardSMs from the partner SMSC address in the incident window, including rejected ones (reject cause unsolicitedMessage). This proves or refutes stale delivery attempts. A typical pattern is a message with an older service-centre timestamp that is only delivered right after a fresh SRI-SM.
5. From the partner SMSC (only their records show which subscriber a given MT-ForwardSM was meant for): the recipient MSISDN the disputed message was submitted for; every delivery attempt for that recipient with the IMSI and MSC address used and the result; whether and for how long their SMSC retains routing information between messages or retries, and whether it performs a new SRI-SM after a delivery timeout.
6. STP routing: confirm that MT-ForwardSMs addressed to an individual RTR Global Title are always routed to that node and never load-shared across RTRs (see High SUB busy with foreign network home-routed MT-MT traffic - Troubleshooting Article).

Solution

• Sending SMSC (root fix): perform an SRI-SM before every delivery attempt that is not part of the original delivery session — in particular before every retry after a timeout — or keep routing information no longer than the firewall's record lifetime. This removes both the delivery delays and the exposure to delivery to the wrong subscriber.
• Firewall record lifetime: firewallmaxintervalbetweensrismandmtfwdsm can be increased following the procedure and the IMSI generation range sizing guideline in Delivery result shows tcapAborted when multiple SMS sent from the same Sender ID. This only helps when the SMSC's re-use interval falls inside the new lifetime, and a longer lifetime increases the number of values in use at any moment; agree the value with the partner's retry schedule before changing it. The change is made in the semi-static configuration file through your normal change process; our Professional Services team can assess or implement it on request.
• IMSI generation range: a larger range lowers the probability that a stale value coincides with a value that is currently assigned to another subscriber.

When the lifetime, counters and log records match the behaviour described above, the firewall is working as designed and no software fix is involved.