Possible bug where SMSC can go into loop sending multiple SRIs #297
Description
https://github.com/RestComm/smscgateway/blob/master/core/slee/services/sbbs/src/main/java/org/mobicents/smsc/slee/services/mt/SriSbb.java#L361
Is this a BUG REPORT:
/kind bug
What happened:
The MAP version fallback code in SriSbb has a logical bug where it does not check if the supported/suggested ACN is lower than the original one sent and thus ends up sending the SRI blindly to the version supported. This can cause issue with faulty HLRs where it might send the same ACN over and over again, thus causing a loop and exhausting the network.
What you expected to happen:
The code should verify if the new supported ACN is different from the one previously used to send the SRI. In case it is not different, the system should error out.
This process is defined in MAP Procedures in the 3GPP specs
https://www.etsi.org/deliver/etsi_ts/100900_100999/100974/07.15.00_60/ts_100974v071500p.pdf
Page 793 (Figure 25.1/2: Macro Receive_Open_Cnf )
How to reproduce it (as minimally and precisely as possible):
Setup a simulator that sends abort to a MAP dialog for SRI and sends the same ACN in tcap-abort with supportedApplicationContextName as received
For example application-context-name: 0.4.0.0.1.0.20.3 (shortMsgGatewayContext-v3)
Anything else we need to know?:
This seems a rare case but has been seen in the networks.
Environment:
- Restcomm SMSC Gateway version (from startup logs): latest master
- Cloud provider or hardware configuration:
- OS (e.g. from /etc/os-release): Debian
- Kernel (e.g.
uname -a): 3.16.0-4-amd64 Gather basic usage stats #1 SMP Debian 3.16.51-3 - Deployment method (e.g. application server version + config + method): manual/test machine
- Others: