RE: OpenSMPPBox :: SMS ID issue
Hi, It appears that sms.id is a uuid instance, and has to be parsed (via uuid_unparse). You might also check the source for where the id is displayed. Regards, Kelvin R. Porter From: users [mailto:users-boun...@kannel.org] On Behalf Of Saurabh Pandey Sent: Monday, April 28, 2014 12:00 PM To: users@kannel.org Subject: Re: OpenSMPPBox :: SMS ID issue I would really appreciate any help here. This small fix will fix my whole system. Thanks in advance On Mon, Apr 28, 2014 at 9:08 PM, Saurabh Pandey sam.it.develo...@gmail.commailto:sam.it.develo...@gmail.com wrote: Hi everyone, I have the following setup: SMSC bearerbox Sqlbox Opensmppbox- smpp client Now I have done some changes in source of OpenSMppbox and there is one issue that I can't seem to understand. DLRs are checked using msg ID. Now I am trying to fetch msg id from msg object but I am getting garbage value. The weird part is that when I dump the msg object I am getting the msg id in there. How do i fetch it am I making some logical mistake? Here is the code I've written: opensmppbox: line 725 info(0, received msg dumping manually by sam); msg_dump(msg, 0); info(0, msg id: %S,msg-sms.idhttp://sms.id); The output I'm getting in the logs is: -- 2014-04-28 11:43:58 [27013] [9] INFO: received msg dumping manually by sam 2014-04-28 11:43:58 [27013] [9] DEBUG: Msg object at 0x7f25d80039e0: 2014-04-28 11:43:58 [27013] [9] DEBUG: type: sms 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.sender: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8003b60: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 8 2014-04-28 11:43:58 [27013] [9] DEBUG:size: 9 2014-04-28 11:43:58 [27013] [9] DEBUG:immutable: 0 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 54 45 53 54 20 53 4d 53 TEST SMS 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string dump ends. 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.receiver: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8003b90: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 10 2014-04-28 11:43:58 [27013] [9] DEBUG:size: 11 2014-04-28 11:43:58 [27013] [9] DEBUG:immutable: 0 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 39 30 30 31 38 35 33 33 39 39 90018X 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string dump ends. 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.udhdata: 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.msgdata: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8003db0: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 112 2014-04-28 11:43:58 [27013] [9] DEBUG:size: 113 2014-04-28 11:43:58 [27013] [9] DEBUG:immutable: 0 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 69 64 3a 35 39 31 30 37 31 33 39 38 36 39 36 32 id:5910713986962 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 33 38 36 37 35 32 32 20 73 75 62 3a 30 30 31 20 3867522 sub:001 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 64 6c 76 72 64 3a 30 30 30 20 73 75 62 6d 69 74 dlvrd:000 submit 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 20 64 61 74 65 3a 31 34 30 34 32 38 32 30 31 33date:1404282013 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 20 64 6f 6e 65 20 64 61 74 65 3a 31 34 30 34 32done date:14042 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 38 32 30 31 33 20 73 74 61 74 3a 55 4e 44 45 4c 82013 stat:UNDEL 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 49 56 20 65 72 72 3a 30 30 35 20 74 65 78 74 3a IV err:005 text: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string dump ends. 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.time: 1398696238 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.smsc_id: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8003560: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 8 2014-04-28 11:43:58 [27013] [9] DEBUG:size: 9 2014-04-28 11:43:58 [27013] [9] DEBUG:immutable: 0 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 6d 76 2d 70 72 6f 6d 6f mv-promo 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string dump ends. 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.smsc_number: 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.foreign_id: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8004200: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 20 2014-04-28 11:43:58 [27013] [9] DEBUG:size: 21 2014-04-28 11:43:58 [27013] [9] DEBUG:immutable: 0 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 35 39 31 30 37 31 33 39 38 36 39 36 32 33 38 36 5910713986962386 2014-04-28 11:43:58 [27013] [9] DEBUG:data: 37 35 32 32 7522 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string dump ends. 2014-04-28 11:43:58 [27013] [9] DEBUG: sms.service: 2014-04-28 11:43:58 [27013] [9] DEBUG: Octet string at 0x7f25d8004230: 2014-04-28 11:43:58 [27013] [9] DEBUG:len: 8
RE: SMPP DLR
Hi, Yes. Rene is correct. I think that I was misreading the SMPP v3.4 Section 5.2.17 registered_delivery. If I set the value to 1. Everything appears to work up to a point. I see DLR records created in my bearerbox DLR queue and in my opensmppbox DLR queue. The DLR entries look correct. My next question is about the fact that the DLRs stay in their respective queues. Is that because I have separate transmit and receive binds for my client(s)? Does delivery only occur on transceiver binds? Any pointers are appreciated. Thank you. Regards, Kelvin R. Porter From: devel [mailto:devel-boun...@kannel.org] On Behalf Of Porter, Kelvin Sent: Friday, February 14, 2014 3:45 PM To: Rene Kluwen Cc: de...@kannel.org Subject: RE: SMPP DLR Hi, Thank you for the corrections. I will investigate further. Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Friday, February 14, 2014 6:13 AM To: Porter, Kelvin Cc: de...@kannel.orgmailto:de...@kannel.org Subject: RE: SMPP DLR Your implementation is not correct. Also the original value of 0x1f for registered_delivery is invalid. Setting both the 2 last significant bits is a reserved value and hence not supported. If you follow the smpp specifications, you will get proper results. == Rene [...elided erroneous proposal...]
RE: SMPP DLR
Hi Renee, Thank you for your response. I will try it with the registered_delivery set to 1. Can you please give a hint as to where you think that the bug might reside in opensmppbox? I can take a look at the source and see if anything sticks out? Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, February 13, 2014 5:12 AM To: Porter, Kelvin; users@kannel.org Subject: RE: SMPP DLR I see that's a bug in opensmppbox. Try to set registered_delivery to 1 instead, meanwhile I come up with a fix. == Rene From: users [mailto:users-boun...@kannel.org] On Behalf Of Porter, Kelvin Sent: woensdag 12 februari 2014 23:52 To: users@kannel.orgmailto:users@kannel.org Subject: SMPP DLR Hi, I have a simple problem. I have the following set up: Client -[SMPP]-- opensmppbox -- sqlbox -- bearerbox -[SMPP]-- SMSC My clients sends a submit_sm request into the opensmppbox, I can see that the submit_sm message is marked requested_delivery: 31 = 0x001f in the logs; however, when I see the corresponding submit_sm sent to the SMSC, I see that requested_delivery is set to 0, in the logs for the SMSC connection. The only impediment that I can think of is that my client(s) bind as transmitter and receiver separately and not as a transceiver. I can send and receive messages with no problem. What do I need to do to insure that the requested_delivery flag is correctly relayed to the SMSC? Thank you. Regards, Kelvin R. Porter
SMPP DLR
Hi, I have a simple problem. I have the following set up: Client -[SMPP]-- opensmppbox -- sqlbox -- bearerbox -[SMPP]-- SMSC My clients sends a submit_sm request into the opensmppbox, I can see that the submit_sm message is marked requested_delivery: 31 = 0x001f in the logs; however, when I see the corresponding submit_sm sent to the SMSC, I see that requested_delivery is set to 0, in the logs for the SMSC connection. The only impediment that I can think of is that my client(s) bind as transmitter and receiver separately and not as a transceiver. I can send and receive messages with no problem. What do I need to do to insure that the requested_delivery flag is correctly relayed to the SMSC? Thank you. Regards, Kelvin R. Porter
RE: SMSC-ID routing based on to/from on SMSBox?
Hi Stipe,
Thank you for the response. These two architectures give me some options,
until I arrive at a more permanent fix.
Regards,
Kelvin R. Porter
-Original Message-
From: Stipe Tolj [mailto:st...@kannel.org]
Sent: Wednesday, November 13, 2013 3:16 PM
To: Porter, Kelvin
Cc: users@kannel.org
Subject: Re: SMSC-ID routing based on to/from on SMSBox?
Am 11.11.2013 19:56, schrieb Porter, Kelvin:
Hi,
I am writing to insure that I have not overlooked an option. In my
application, I have a need to specify SMSC based on where the message
is being sent to (the users will not specify the smsc in the HTTP request).
Basically, I need to insure some MT destinations are treated
differently that the others, independent of what is specified in the
request. I have looked at the source and it does not appear that this
functionality is implemented. Have I missed something?
I am looking for something akin to the smsc-route option in the
opensmppbox. I may attempt to splice in this code from the
opensmppbox, if I must. Is there any interest in this functionality?
Hi Kelvin,
now, as far as I get you, you want some kind of man in the middle
process that is able to tag the MT with the corresponding smsc-id (that is then
routed for on the bearerbox level), while the external users
(ESMEs) are injecting the MTs in standard fashion way via the smsbox HTTP
sendsms interface, correct?
There are several ways to do this. Let me give you a glance of options:
a) HTTP bridging: means, in a communication chain diagram this:
users -HTTP- smsbox - bearerbox(SMSC HTTP) -HTTP- app -HTTP- smsbox
- bearerbox -SMPP/..- SMSC.
so, the users send the HTTP call, which is always routed (enforced) to a
smsc-id RELAY, which is a HTTP SMSC config that sends again the MT via HTTP to
an application layer, (call is routing layer if you want).
This logical entity can then do MNP (mobile number portability) lookups, decide
which SMSC is in charge to transport the MT, and then tag the MT again with
the correct smsc-id for the successing HTTP call to smsbox, which then get's
routed to the corresponding SMSC instance in bearerbox.
So, effectively you create a HTTP loop to a application layer that does the
routing decision, and then re-inject via smsbox.
b) smppbox bridging: means, in a communication chain diagram this:
users -HTTP- smsbox - bearerbox -SMPP- smppbox - bearerbox -SMPP/..- SMSC
in this case you can utilize the Kannel smppbox plugin API to call for
additional control flows, i.e. via a HTTP callback, or even via
implementation of own plugin logic into the smppbox to resolve the smsc-id you
want to route to.
Option a) is a bit of config mangling, especially if DLRs are involved.
Option b) is faster, but involves the licensing of the commercial Kannel SMPP
v5.0 server (smppbox).
Hope this gives some insight.
Stipe
--
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
RE: SMSC-ID routing based on to/from on SMSBox?
Hi, The scenario is the following... I have customers that are sending HTTP requests to the SMSBox instance to initiate the sending of MT messages. Depending on the intended destination of those messages (i.e., the to/receiver number), I need to direct the message to one set of SMSC links or the other in the BearerBox. The application performing the HTTP requests does not have any way of determining the set of numbers that need to go to a particular SMSC. So, I am looking for a way to configure the SMSBox so that the SMSC is specified for certain MT destinations. In the opensmppbox, I would use the smsc-route option to set which SMSC was specified before it was sent to the bearerbox. I am looking for equivalent functionality. Have I overlooked something or is the functionality, not there? Thank you. Regards, Kelvin R. Porter From: ha...@aeon.pk [mailto:ha...@aeon.pk] Sent: Tuesday, November 12, 2013 10:48 AM To: Porter, Kelvin Cc: users@kannel.org Subject: Re: SMSC-ID routing based on to/from on SMSBox? Can you explain your scenario with an example please? Would be easier to understand what you need. On Mon, Nov 11, 2013 at 11:56 PM, Porter, Kelvin kelvin.por...@h3net.commailto:kelvin.por...@h3net.com wrote: Hi, I am writing to insure that I have not overlooked an option. In my application, I have a need to specify SMSC based on where the message is being sent to (the users will not specify the smsc in the HTTP request). Basically, I need to insure some MT destinations are treated differently that the others, independent of what is specified in the request. I have looked at the source and it does not appear that this functionality is implemented. Have I missed something? I am looking for something akin to the smsc-route option in the opensmppbox. I may attempt to splice in this code from the opensmppbox, if I must. Is there any interest in this functionality? Regards, Kelvin R. Porter
RE: SMSC-ID routing based on to/from on SMSBox?
Hi, I did some looking and it appears that I might be able to accomplish what I want using allowed- and/or denied-prefix. The description is a bit ambiguous though, these variables determines whether a SMS message can be sent through. The routing is unclear as to whether the prefix filtering is being applied to the sender or the receiver. I could look at the code, but does anyone know off-hand which number is being filtered? Thank you for the pointer. Regards, Kelvin R. Porter From: ha...@aeon.pk [mailto:ha...@aeon.pk] Sent: Tuesday, November 12, 2013 11:27 AM To: Porter, Kelvin Cc: users@kannel.org Subject: Re: SMSC-ID routing based on to/from on SMSBox? Have you tried allowed-smsc-id and denied-smsc-id parameters in group=smsc? On Tue, Nov 12, 2013 at 10:10 PM, Porter, Kelvin kelvin.por...@h3net.commailto:kelvin.por...@h3net.com wrote: Hi, The scenario is the following... I have customers that are sending HTTP requests to the SMSBox instance to initiate the sending of MT messages. Depending on the intended destination of those messages (i.e., the to/receiver number), I need to direct the message to one set of SMSC links or the other in the BearerBox. The application performing the HTTP requests does not have any way of determining the set of numbers that need to go to a particular SMSC. So, I am looking for a way to configure the SMSBox so that the SMSC is specified for certain MT destinations. In the opensmppbox, I would use the smsc-route option to set which SMSC was specified before it was sent to the bearerbox. I am looking for equivalent functionality. Have I overlooked something or is the functionality, not there? Thank you. Regards, Kelvin R. Porter From: ha...@aeon.pkmailto:ha...@aeon.pk [mailto:ha...@aeon.pkmailto:ha...@aeon.pk] Sent: Tuesday, November 12, 2013 10:48 AM To: Porter, Kelvin Cc: users@kannel.orgmailto:users@kannel.org Subject: Re: SMSC-ID routing based on to/from on SMSBox? Can you explain your scenario with an example please? Would be easier to understand what you need. On Mon, Nov 11, 2013 at 11:56 PM, Porter, Kelvin kelvin.por...@h3net.commailto:kelvin.por...@h3net.com wrote: Hi, I am writing to insure that I have not overlooked an option. In my application, I have a need to specify SMSC based on where the message is being sent to (the users will not specify the smsc in the HTTP request). Basically, I need to insure some MT destinations are treated differently that the others, independent of what is specified in the request. I have looked at the source and it does not appear that this functionality is implemented. Have I missed something? I am looking for something akin to the smsc-route option in the opensmppbox. I may attempt to splice in this code from the opensmppbox, if I must. Is there any interest in this functionality? Regards, Kelvin R. Porter
SMSC-ID routing based on to/from on SMSBox?
Hi, I am writing to insure that I have not overlooked an option. In my application, I have a need to specify SMSC based on where the message is being sent to (the users will not specify the smsc in the HTTP request). Basically, I need to insure some MT destinations are treated differently that the others, independent of what is specified in the request. I have looked at the source and it does not appear that this functionality is implemented. Have I missed something? I am looking for something akin to the smsc-route option in the opensmppbox. I may attempt to splice in this code from the opensmppbox, if I must. Is there any interest in this functionality? Regards, Kelvin R. Porter
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:devel-boun...@kannel.org] On Behalf Of Mick Burns Sent: Tuesday, September 24, 2013 7:25 PM To: de...@kannel.org 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; 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
RE: Proposal for Real-time Routing in opensmppbox and bearerbox
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). I think that the billing side is addressed brilliantly with the sqlbox functionality. At least, it works perfectly for our applications. Regards, Kelvin R. Porter From: Rinor Hoxha [mailto:rinorho...@gmail.com] Sent: Tuesday, July 23, 2013 5:33 PM To: Porter, Kelvin Cc: de...@kannel.org; users@kannel.org 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 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).
Proposal for Real-time Routing in opensmppbox and bearerbox
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).
RE: Proposal for Real-time Routing in opensmppbox and bearerbox
Hi, In the straightforward implementation, the load on the database would be 1 query per message sent (MT) and 1 query per message received (MO) (excluding situations where loopback occurred). A caching component could be added separately afterwards. The trade-offs would involve added code complexity, and the increasing latency in having database changes affect message routing. Different applications (e.g., A2P vs. P2P) might or might not see much benefit depending on how long the caching interval is, the rate of back-and-forth conversation, and the size of the cache. I am not familiar with all aspects of the code base, is there a caching mechanism that can be reused? I think that if caching is added that it should be configurable as to size and duration. Regards, Kelvin R. Porter From: spameden [mailto:spame...@gmail.com] Sent: Monday, July 22, 2013 3:55 PM To: Porter, Kelvin Cc: de...@kannel.orgmailto:de...@kannel.org; users@kannel.orgmailto:users@kannel.org Subject: Re: Proposal for Real-time Routing in opensmppbox and bearerbox Interesting idea, but what about load on the database? Will it be cached or it's gonna get results from the database everytime SMS arrives? 2013/7/23 Porter, Kelvin kelvin.por...@h3net.commailto:kelvin.por...@h3net.com 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
Question: select smsc based upon receiver number?
Hi,
I have a set up like this...
Client -- opensmppbox -- bearerbox -- {SMSC1 (default), SMSC2}
I am wondering if there is a way to do the routing like smsc-route in the
latest versions of opensmppbox, but for the receiver of the SMS message, not
the sender. I have a large set of diverse numbers that I want to divert from
the default smsc. The set of numbers are diverse (i.e., they do not share any
prefixes in common). How can I redirect this set of diverse numbers away from
the default smsc?
If there is not a good way to do this, I can modify the code to the bearerbox
and/or opensmppbox. Does anyone have a preferred way of seeing it implemented?
I am thinking that I could add a new parameter to the smsc-route group,
perhaps called receiver-shortcode, which would be a list of receiver numbers
that trigger the smsc overwrite. I believe that this should be a higher
precedence match than the sender.
Thank you for any feedback.
Regards,
Kelvin R. Porter
