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:[email protected]] Sent: Wednesday, November 13, 2013 3:16 PM To: Porter, Kelvin Cc: [email protected] 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 -------------------------------------------------------------------
