Monthly Archives: July 2014
This post is just a reminder for me. It may be useful one day for someone else too.
I worked on an application that sends short text messages (SMS) through an SMS gateway based on SMPP3.4 protocol; The work is based on a Java library called SMSLib (v3), which is based on JSMPP itself. The SMS library introduced the “Service” idea on top of the AbstractJSMPP gateway already specified on JSMPP. This “Service” allows many other capabilities such as redundunt and load balanced gateways.
However, the integration with different plateforms was not as easy as I thought because of specific features and configuration on each SMSC.
For instance, I was facing a weird “Session not bound exception” while dealing with Nokia SMSC 8.1. Actually, the server answer was:
Bind Response header (31, 80000002, 00000450, 1)
The server response code is 0x000000450. The first step to solve this issue is to understand this error. The problem is, that this code does not belong to standard SMPP 3.4 protocol standard errors!
I gathered the vendor documentation for the client SMSC (Nokia SMSC Center 8.1), and the error mentioned is “Too many users with this login ID”.
Actually the process of sending messages was a background scheduled task using Quartz. It gathers a queue from an oracle table and tries to send items one by one. When it fails to send and the application gets no more connected to the SMSC, it tries to reconnect. It seems that the SMSC is not handling correctly the disconnection on session unbind event(send failure). So, the number of opened session with the same ID keeps growing until it fails to create a new session. The administrator of the SMSC told me after a while(4 months approximately!), that the maximum number of session to open with same ID is 10 🙂
Another ambiguous error received from another type of SMSC (I don’t know even the vendor of this one) is 0x00000008 (System Error – ESME_RSYSERR) . In this type of errors, only the SMSC logs can help you. I want to thank the guy on the other side who was very helpful to get rid of it quickly. Actually, it was related to numbering format and to mandatory params. This is a specific configuration too. In this case, the SMSC is configured to reject any SMS without a source phone number. So, adding the instruction (setFrom) to the outgoing message solved the issue. In the first SMSC, the parameter was not mandatory, and it was gathered by the SMSC from the client ID.
I also added a custom implementation of JSMPPGatway to handle variable transaction timer; Due to some network latency, the transaction time was exceeding the default value assigned on Jsmpp abstract definition (on session creation); The default value is 2000 ms(=2s). I managed to get it longer by overriding the constructor of JSMPPGateway to handle the transaction timer parameter.