Am 12.11.2013 19:01, schrieb Porter, Kelvin:
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?
just wanted to jump into the discussion here to clear out the way how
bearerbox performs "routing".
# Understanding the routing architecture
# --------------------------------------
#
# The most common mistake made by new users is about routing. Please keep in
# mind that we have a 2 tier architecture in Kannel, typically:
#
# SMSCs <-SMPP/UCP/HTTP/GSM/..-> bearerbox <-Msg-> smsbox <-HTTP-> users
#
# for the HTTP abstraction of all supported client side SMSC protocols, or:
#
# SMSCs <-SMPP/UCP/HTTP/GSM/..-> bearerbox <-Msg-> smppbox <-SMPP-> users
#
# for the SMPP abstraction of all supported client side SMSC protocols, and
# so on for other foobox daemons that dock to bearerbox as smsbox
connection.
#
# In this chain we call bearerbox tier 1, and [sms|smpp|foo]box tier 2, in
# addition we call the flow directions:
#
# SMSCs <-upstream- bearerbox <-> smppbox -downstream-> users
#
# So a MT messages is always in a 'upstream' direction, and a MO messages is
# always in a 'downstream' direction. This is pure definition.
#
# Routing is done in EVERY tier INDEPENDENTLY. Which means, we assign a
smsc-id
# tag to a message at smppbox, but this is NOT A FINAL routing decision for
# the bearerbox tier, since it routes again on it's own behalf. Think of the
# routing process more like a TAGGING of the messages, where the bearerbox
# will then interpret that tag and decide on its own behalf which SMSC
# upstream connection to take.
# Understanding bearerbox's MT routing
# ------------------------------------
#
# Kannel's bearerbox performs MT routing in a four step process. It can be
# described by the following procedure:
#
# step 1: Provide a set of sms-ids that are currently online, and
hence can
# be potentially used directly to forward the message to a SMSC.
# This provides result-set-1.
#
# step 2: From result-set-1, provide a set of smsc-ids that are allowed
# according to [allowed|denied]-[prefix|smsc-id] config directive
# constraints.
# This provides result-set-2.
#
# step 3: From result-set-2, provide a set of smsc-ids that are preferred
# according to preferred-[prefix|smsc-id] config directive for the
# given msg->sms.smsc_id tag.
# This provides result-set-3.
#
# step 4: From result-set-3, pick a random one.
#
# Typically the outcome of step 4 is one remaining smsc-id, but may be also
# a group of alternatives, where a random pick is then performed.
this was taken from the Kannel SMPP v5.0 server (smppbox) documentation
sections. I hope they provide some explanatory 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
-------------------------------------------------------------------
