Java SMPP library comparison

Question

We're about to begin a project which requires the use of SMPP as the primary integration exchange channel. Now since SMS isn't necessarily core to our business, I'd like to use an SMPP library for Java that will be the least hassle. Aside from riding on the actual protocol, its unlikely we'll need fancier abilities or to ever tweak under the hood.

To that end, I've shortlisted some of the possible options that we have:

• Logica's Open SMPP
• Apache's Camel
• JSMPP
• Twitter's Cloudhopper

Can someone who's more experienced in their uses throw some of their experiences my way ?

EDIT: Just to give scope to the use cases, we'll be both sending and receiving SMS'es so the library should hopefully make life easy with both client action and also server listener implementation.

Speculation

Answer 1

I have used both jSMPP and cloudhopper-smpp for separate projects which involved sending and receiving SMS's over smpp in circumstances which involved:

• Receiving medium-high number of MOs.
• Sending high number of MTs (up to 70/second).

Both the libraries fared well, and IMO jSMPP is more user-friendly to jump in and start coding right away. But I had came across a few bugs while using the latest version from GitHub, which still remain unfixed.

After having used cloudhopper, I reckon it is well worth the learning curve, which is a wee bit steep compared to jSMPP (subjective).

Verlaverlee

Hi Farhan, where did you start to learn about cloudhooper ? just by the source code ? or did you find any docs besides the source code ? Thanks – Coquelicot

Hi David, the examples included with the library was the best resource i could find (github.com/twitter/cloudhopper-smpp/tree/master/src/test/java/…) . If you already know how SMPP works, spending a bit of time fiddling with the source code would be enough to grasp the control flow. For SMPP related doubts, you can refer the SMPP Specification(turkcell.com.tr/downloads/hakkimizda/pdf/SMPP_v3_4_Issue1_2.pdf) – Verlaverlee

For the record as of mid 2020 jsmpp is maintained by jsmpp.org community here github.com/opentelecoms-org/jsmpp. – Isbella

Answer 2

Just an updated to what I finally decided (and how libraries reviewed):

1. Logica: Seems promising but I was concerned about the lack of updates/activeness of the community in general. The last meaningful build was yonks ago so not really an investment I wanted to make.

2. Apache Camel: We started off using this but there were some limitations to their library (we needed to insert custom heads to our SMPP packets). To be fair they were fairly prompt in responding to issues on their forums but their build cycles took a little too long for my sprints, so we scratched this.

3. JSMPP: This is the one we ended up using. Was pretty straightforward overall tho it did feel like it expected you to already have a fairly good idea of SMPP in general. Things are in staging so I can't tell you how it performs under production load. Will update when it goes live.

4. Cloudhopper: To be honest this was the one I was keen to use but more because like any geek I wanted to jump on the shiniest newest toy available. I didn't really get adequate responses to any queries we made from the off so was apprehensive to get on board. No reason to adopt a library that will require me to wade thru their codes when other more documented options were available.

Speculation

Based on the answers to this question, I started with a shortlist of Cloudhopper & jSMPP. To get jSMPP working with Nexmo I had to fiddle with the example params and fix a bug - and I'm still getting a non-fatal(?) IOException - whereas Cloudhopper worked out of the box with Nexmo; the fact it has a server as well is a big plus for testing. – Roseannaroseanne

Answer 3

I am currently implementing a SMPP solution over Java using Logica's library. It is very easy to use. The following information states the result of the tests:

Application: Enterprise Java Beans Application deployed in Glassfish 3.1.2.2
Language: Java (using JMS)
Library: Logica SMPP (version 1.3)
Origin (ESME): localhost
Destination (SMSC): Logica SMSC simulator at development server (hosted in Amazon Web Services)
Type: Transciever Asynchronous
Avg sending rate (80%): 246 msg / sec
Low sending rate (15%): 50 msg / sec
High sending rate (5%): 255 msg /sec

It is very efficient as long as you stick to the asynchronous mode. If you need to keep a correlation between the message and its response use the "sequence number" that is both in the message and the response.

Chemical

Can you please tell me how you run your SMPP client within GlassFish? Is it possible to use GlassFish for non-web applications? – Deuteragonist

You can use you Glassfish for non-web applications. It depends of what you are looking for. You could, for example, create a Bean container (Java Bean Project) and create an EJB with the SMPP client logic. How we did it? We created a MDB (Message Driven Bean). MDB can be used as an asynchronous queue system. Here we have an active SMPP session that is in charge of building the SMPP message (from the data that the MDB messages have) and submitting it. – Chemical

Hello I am looking for anyone who has used openSmpp client. For me it works fine expect the registration of delivery. I am using version 3.0.0 from maven and delivery set to 0x01 seem not to work for me. Only thing I get is submit_sm. both synch and asynch. How to make this work. I am also expecting some normal dlr string like : "id:0123456789 sub:001 dlvrd:001 submit date:0809011130 done date:0809011131 stat:DELIVRD err:000 text:" – Aspire

Answer 4

Our SMSC was written on Logica SMPP (v 1.3), it still works really well with enterprise loadings. There has been only a few small issues regarding the library mainly with message_payload, honestly I don't remember other issues. But it's easy to repair because it's an opensource product.

Although I personally trust logica's sources, for small clients I use jsmpp. I agree with @Farhan that it's a bit more user friendly and developing of a simple client takes less time.

Jessen

Answer 5

I've used both jsmpp and smppapi and found the latter much nicer because jsmpp had only synchronous blocking mode at that time (2010) - not sure if that's still the case.

The blocking nature of jsmpp become source of big problems when the SMPP server I was connecting to were experiencing some performance problems and responded slower than usual. Suddenly I found all of my threads to be waiting for responses. Migration to smppapi solved the problems obviously.

Bulb

Hello Can anyone confirm if this is still the case (2014) thank you – Aspire

Answer 6

I've used Logica SMPP for a production project. It's not actively maintained anymore and there are a few inherent bugs which resulted in having to produce workarounds or actually forking the codebase to fix. Having said that, I've found the API to be very stable and performant (300msg/s).

I've briefly looked at JSMPP and it has a much nicer API than Logica although there seems to be a large number of defects have not been fixed despite there being on the issue list for a long time.

Just came across Cloudhopper SMPP which seems to be coded in a more up to date style but again it needs more examples. Having to chore through the code base is not attractive. Examples on gituhub are getting better though.

Astereognosis

I would ditto that re Cloudhopper. I like some of their stuff and its clearly the latest endeavor when you compare it to the rest of the list. Docs (in the rare occasion they have any) leave a lot to be desired tho. I'm in the middle of designing a completely separate SMPP implementation for our use. Its a bit of large project since I need to make the service ambivalent to all calling implementations. Given the async nature of SMPP its almost like designing an ESB. I might revisit Cloudhopper if they get their act together in that regards tho. – Speculation

Answer 7

Cloudhopper is the best choice, Apache's Camel is also good but it's a very big project that has many interfaces to pdf, salesforce.... that you don't need. Other project is not updated to date. Cloudhopper is maintaining by Telestax and they add some useful features and look like they will give strong support it in future

Here's stack for easying config Cloudhopper https://github.com/RestComm/smpp-extensions Here's forked Cloudhopper by telestax (very up to date): https://github.com/RestComm/cloudhopper-smpp Also JainSlee Resource Adapter for whom who's working in telecom field https://github.com/RestComm/jain-slee.smpp

Unlade

Answer 8

presently I am using JSMPP and i found it's okay so far. Cloudhopper seems easier of the lot but i ended up with JSMPP and also found out that JSMPP is also at the heart of Apache camel implementation i might be wrong though.

Chemo

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Prizewinner

The original question might be the source of the issues with the answers. The question leans toward a discussion or opinion format and perhaps shouldn't have been allowed in the first place. – Aegis