1. Check that incoming message has been detected by the system using web interface.
For this enter Message detail report for suspected peer and search for the message.
If message is found - go to i.8.
2. On this stage we know that EDR is absent in suspected peer.
Search for EDR on all peers.
For this use Messaging -> Reports -> Message details.
If message is found, then incoming message has been associated not with the peer you suspect but with some other peer.
Perform i.1 for new peer. Check system configuration.
3. On this stage we know that the message is absent in system's EDR.
Check if the IP address of peer has been blocked by the Fail2Ban application.
You can check it by looking for peer's IP address in Network -> Firewall tables -> SMPP deny -> Hosts.
4. Enable Pcap capturing on originator.
Ask originator to send a message once more.
After sending a message, search the message in Pcap report on expected originator.
If not found - search on all peers in Messaging -> Reports -> Pcap, using a filter by B-number.
If message is found, then incoming message has been associated not with the peer you suspect but with some other peer, which has the same authorization settings.
In case if the message is absent in the system-wide Pcap report - likely the message hasn't come to Smartswitch at all.
You can re-check this with manual pcap capturing which is described in section Debug SMPP message with Wireshark.
In case you don't see a message when manually capturing pcap - you need to pass a problem to the originator.
5. On this stage we know that message comes ingress to Smartswitch.
Check if the message handling starts.
For this use instruction Debug call handling.
In case if you see in log file /var/log/asterisk/messages message handling execution in response to incoming message - association with peer has been found and message handling has been started.
EDR should be present in the system.
Therefore, i.1 and i.2 have been performed incorrectly.
Repeat them.
6. On this stage we know, that message arrives, but message handling is not started.
Possible reasons: a mistake of definition of a branch entering inside Call handler, mistake of peer definition in the system, malformed SMPP message.
Turn on logging of debug 10 and verbose 10 using instruction Debug Asterisk.
For SMPP additionally turn on debuging using instruction Debug SMPP protocol in Asterisk.
In log file /var/log/asterisk/messages you'll need to search for output lines after SUBMIT_SM from originator.
They will contain information of why Asterisk hasn't found association with peer and hasn't started execution of Call handler.
Usually the reason is malformed SMPP message.
Debug the message contents using pcap file, Wireshark and SMPP specification and pass the issue either to originator or to Streamco tech support , if the message is completely correct but is discarded by Smartswitch.
7. Check that message handler is executed according to expected logic.
For this use instruction Debug call handling.
8. In case if message handling is performed correctly and Softswitch application is invoked,
however outbound message is not generated to a terminator, then Check routing with the same parameters as the RouteMessage application is executed in the call handling log in /var/log/asterisk/messages.
In case if during Checking routing you immediately see an error message - then this error is in orignator settings. Fix settings.
In case if during Checking routing you see an originator price but you don't see expected routes, enter in field outbound peer the name of expected outbound peer and system will show you why there is no route to it. Fix settings.
9. In case if Check routing shows properly and the route is to a dynamic peer (which doesn't have static IP address and is expected to bind to Smartswitch) -
check if the dynamic peer is bound on Smartswitch in System live -> SMPP ESME.
10. Enable following log levels in System -> Logging -> asterisk: info, error, debug.
Check log file /var/log/smartswitch/asterisk.log.
Find the time of a call and its B-number and see log messages related to routing a message - it could hint you about the reason of the issue.
11. Check if the concurrent limit or attempts per second in configured on a terminator.
When these restrictions apply, the outbound message won't be generated.
Also check all other non-default limitations configured on a terminator.