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
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:
uname -a): 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3