1
votes

I am developing an sms gateway using jsmpp library.

This is my scenario.

I bind to the SMSC(telecoms company) on 2 connections and receive messages on 2 shortcodes, say 30002 and 30003 , assigned to me by the SMSC.

Then, third party binders(companies involved in bulk sms push) who normally should bind directly to the SMSC bind to my gateway via SMPP connections to my SMPP server(which serves as an SMSC of sorts to them)

The third party binder sends messages to the SMPP server and I capture this messages, queue them and send them to the main SMSC(telecoms company).

The telecoms company then responds with delivery reports and messages from the bulk message reports and other data which I forward to the third party binders.

This scenario has worked well for when I have only 1 third party binder.

But now we want to handle a more general case where we have many third party binders.

Since I have only 2 short codes available on which the SMSC forwards messages to me, how do I know which of the third party binders owns the SMSC response?

I have the unsavoury and inefficient option of forwarding the responses to all connected third parties.

The only other option apart from the above is to get a different short code from the SMSC for each third party binder, which is not cost efficient for my scenario.

1
Please clarify, do you need to forward mobile-originated messages (as in "subscriber sent test123 to 30002") or just delivery reports to third parties? Also, mention which packet types do your third parties use and which do you use with telecom SMSC (submit_sm, data_sm, ... ?)jim
I am forwarding MO's and dlrs to the third party. The third party pushes their messages to me with submit_sm and I forward these messages to the SMSC with jsmpp's submit methods. I get DLR's and MO's from the SMSC in onAcceptDeliverSm method and forward them to the third partiesgbenroscience

1 Answers

1
votes

First of all, you can pretty easily forward all DLRs to the correct third parties. In order to do so, you will have to store some extra data in a database of your choice (if you only have 1 application node and low traffic, even SQLite will suffice; otherwise look towards some NoSQL solution):

  1. Every time you receive a submit_sm_resp packet from telecom SMSC, start storing a pair (key-value, actually) message_id -> third_party_id.
  2. Every time you receive a deliver_sm packet from SMSC, retrieve the message_id from the packet, then look for this message_id in your DB to find which third party to forward it to.
  3. Consider removing the message_id -> third_party_id pair after you have successfully forwarded the final DLR for that message_id.

The situation is a lot worse with the MO messages. The only possible (but nonetheless very bad) way of using a single shortcode for multiple clients (third parties) is having a fragile combination of TTLs and timeouts on you data. It also only makes sense when every MO that you expect is a reply to a previous MT message.

  1. Separate incoming MTs that need reply from the receiver using TLV or extra SMPP links. Let us call those MTs Questions.
  2. Handle Questions something like this: MT
  3. Handle MO messages (Answers) like this: MO

UPD. Text elaboration

In order to know the correct third party for MO message (not delivery report) you need some additional info about who the message is addressed to. This info might originate from either the third party or the subscriber (one who has initiated the MO message in the first place). My diagrams formally describe the case where the third party gives you this information.

  1. A third party sends you an MT message that they expect to be Answered by the recipient.
  2. You make a note in the database, that if the recipient sends you an MO message in the next N minutes, then this Answer should be forwarded to the aforementioned third party.

I apologise that my answer is not specific to jsmpp but I have little knowledge of this library, however, I also believe it should be fairly easy to implement an algorithm once you understood it regardless of your instrument.