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). > > >
