RE: Follow-up : Proposal for Real-time Routing in opensmppbox and bearerbox

Hi,

I have been dealing with shifting business priorities.  Ironically, I had just returned to work on the code change outlined in the proposal some more the past day or two.  And now my priorities have been shifted yet again.

The reason that I wanted to reuse the infrastructure set forth by the DLR code is that it already establishes all the connection code necessary for connecting with the database and rather than duplicate that entire structure, it is easier (and generally a better idea) to reuse it.  We know that the current code can successfully connect and query with all the different flavors of database.  And reusing the code keeps the database-related code to a single area of the bearerbox/smsbox/opensmppbox codebase.  The idea was to add new functionality to the code with as little disruption to the code and currently underlying design as possible.  I do not know whether other developers would approach it differently...

I will continue to work on the code as I am able, but I cannot promise a particular delivery date.

Regards,

Kelvin R. Porter

-----Original Message-----
From: devel [mailto:[email protected]] On Behalf Of Mick Burns
Sent: Tuesday, September 24, 2013 7:25 PM
To: [email protected]
Subject: Follow-up : Proposal for Real-time Routing in opensmppbox and bearerbox

Dear Kannel friends,

I would like to revive the nice thread (*) started by Kelvin Porter back in July in respect to adding new routing capabilities to bearerbox and opensmppbox.  This functionality is of great importance for me and I would like to actively help in testing it out.
I am x-posting this on the users and dev lists like the original thread.

Now, I don't quite understand why it should hook with dlr code, please note that I am not a proficient coder at all.
Perhaps Kelvin is just pointing out existing routines that can be used as an example or starting point to implement the concept.

In short, I would like to avoid having to use (for fined-grain
control) smsbox-route statements for each of the customers provisioned DNs.  Instead, for each message received by an upstream SMPP, bearerbox does a lookup into a RDBMS (mysql/pgsql) for each message and the reply to the query contains the smsbox-id to route the message to.
Otherwise, currently all messages goes to a single smsbox which delivers the message to an HTTP-based service via the sms-service stanzas.

Example of the smsbox-route statements to avoid with this new feature:
group = smsbox-route
smsbox-id = osmppbox1
shortcode = "+18885551212;+18665551212;2222"


I quickly put together a block diagram of what I am thinking:
http://pastebin.com/raw.php?i=BSYC88UZ

I really wonder how other carriers/aggregators implements "carrier-grade"
routing between bearerbox's upstream smpp connections and downstream towards either smppbox(es) or smsboxes depending on where the message should normally route to.  It also adds agility to the routing on a global basis and in a dynamic manner (no need to stop/start services).

Thank you
Mick B.

(*) Link to original thread from Mr. Porter:
http://www.kannel.org/pipermail/users/2013-July/019991.html