Hi.
2013/7/24 Porter, Kelvin <[email protected]> > Hi,**** > > ** ** > > Using HTTP RPCs to access the functionality would actually be more work in > implementation on both the client (kannel) side and the server > (application) side. For our application, the routing criteria (for say a > number) will change once and then remain constant for quite some time. > This is perfect for a database (possibly including caching). > About caching: you can implement simple "one-time load" from the database on the start and reload configuration on some trigger, maybe add URL to do so, let's say http://localhost:13000/reload-routes. so if you change rules in the database you hit the url and you're done! > **** > > ** ** > > I think that the billing side is addressed brilliantly with the sqlbox > functionality. At least, it works perfectly for our applications. > Indeed. We're using patched sqlbox with bearerbox only too, deleting DLRs and updating MT records with all needed info. > **** > > ** ** > > Regards,**** > > ** ** > > Kelvin R. Porter**** > > ** ** > > *From:* Rinor Hoxha [mailto:[email protected]] > *Sent:* Tuesday, July 23, 2013 5:33 PM > > *To:* Porter, Kelvin > *Cc:* [email protected]; [email protected] > *Subject:* 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 > I think it would be additional overhead in this case, I'm more into database / memcached idea. Same thing with calling smsbox HTTP url each time sms comes in instead of just updating info in the db directly. Very often there is separate server for sending purposes, so its not really convinient to have multiple HTTP-callbacks. Also if you're doing HTTP callback on WAN network I consider it being insecure, it should be HTTPS at least, no problem tho if its done over VPN / trusted LAN network. > > > 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).**** > > **** > > ** ** >
