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