Re: Proposal for Real-time Routing in opensmppbox and bearerbox

How about using (implementing or adapting) HTTP-based callbacks.
So you could implement routing, billing or whatever you may need based
on callback responses.

Br, Rinor
 

On 07/22/2013 10:45 PM, Porter, Kelvin wrote:
>
> *Hi,*
>
> * *
>
> *I have included a proposed enhancement for routing message based on
> database contents below.*
>
> * *
>
> *I am looking for feedback.*
>
> * *
>
> *Please share your thoughts as to whether this would be of interest.*
>
> * *
>
> *Thank you.*
>
> * *
>
> *Regards,*
>
> * *
>
> *Kelvin R. Porter*
>
> * *
>
>  
>
> I would like to propose an enhancement to the source code to kannel
> bearerbox and opensmppbox.  The enhancement would supercede the
> existing configuration groups:
>
>  
>
> "smsbox-route" in the bearerbox, and
>
> "smsc-route" in the oppensmppbox.
>
>  
>
> The enhancement dynamically consults a database table/view to
> determine the mapping based on the sender, receiver and original
> connection (smsc or box).  The purpose of this enhancement is to allow
> dynamically changing the message routing without requiring a change to
> the configuration file(s) and then the subsequent restart of the
> opensmppbox and/or bearerbox.
>
>  
>
> The enhancement works by taking advantage of the database access
> functionality currently used for storing DLRs in a database.
>
>  
>
> The DLR code currently supports the following databases: "mysql",
> "oracle", "pgsql", "mssql", and "sdb" (where  SDB is the simplified DB
> interface).  The "internal" option refers to storing DLRs in memory
> and would not apply to this enhancement.  I can write the code for
> these databases, but may require some assistance from the kannel
> community in testing them.
>
>  
>
> The enhancement adds two new table parameters to the group "dlr-db":
>
>  
>
> "table-smsc" specifies the name of the table/view mapping a message to
> a smsc-id, and
>
> "table-box" specifies the name of the table/view mapping a message to
> a (sms)box.
>
>  
>
> The enhancement is selectively enabled by configuring the parameters
> above.
>
>  
>
> The following existing fields parameters of the group "dlr-db" are
> re-used:
>
>  
>
> "field-source" specifies the name of the field that matches the sender
> of a message, and
>
> "field-destination" specifies the name of the field that matches the
> receiver of a message, and
>
> "field-smsc" specifies the name of the field that matches the smsc, and
>
> "field-boxc-id" specifies the name of the field that matches the name
> of the box.
>
>  
>
> The following are two routines added to the dlr.h interface:
>
>  
>
> /** Given message, then map to smsc id. */
>
> Octstr * map_to_smsc(Msg *msg);
>
>  
>
> /** Given message, then map to boxc-id. */
>
> Ocstr *map_to_box(Msg *msg);
>
>  
>
> If these methods return a (non-NULL) result, then they supercede the
> configuration-based routing.  If the results are NULL, then the
> default configured routing can be applied.
>
>  
>
> The queries for this the match look something like the following:
>
>  
>
> 1.       To determine the smsc...
>
> "SELECT <field-smsc> FROM <table-smsc> WHERE ((<field-sender> = NULL)
> OR (<field-sender> = ?)) AND
>
>     ((<field-destination> = NULL) OR (<field-destination> = ?)) AND
>
>     ((<field-boxc-id> = NULL) OR (<field-boxc-id> = ?))"
>
>  
>
> 2.       To determine the (sms)box...
>
> "SELECT <field-boxc-id> FROM <table-box> WHERE ((<field-sender> =
> NULL) OR (<field-sender> = ?)) AND
>
>     ((<field-destination> = NULL) OR (<field-destination> = ?)) AND
>
>     ((<field-smsc> = NULL) OR (<field-smsc> = ?))"
>
>  
>
> The queries are written in this fashion where a column with a NULL
> value will always match (in essence a row with a NULL in a column will
> always match).  That way a subset of the column values (e.g., receiver
> only or sender and boxc-id ) can be used to match as a criteria.
>
>  
>
> New debug level logs would be added to indicate the input to the
> queries and the result.  In addition, certain configuration panics
> might be added like attempting to configure "table-smsc"  or
> "table-box" in conjunction with the "internal" database option.
>
> This enhancement would enable the directing of messages on the fly.  I
> think that the approach would serve as a good foundation in case
> additional routing criteria were desired (i.e., language/encoding
> based routing).
>
>  
>