- Product Manual
- Installation Guide
- User Guide
- Quick Start Guide
- User Interface
- Inbound Routing
- Multiple keywords
- SQL routing
- Outbound routing
- SQL logging
- SMS routing table override
- Sender address
- Content manipulation
- Charset handling
- List Management
- SMS Client software
- Administrator's guide
- Developers Guide
- Examples and Solutions
- SMS FAQ
- Feature list
- Commercial Information
Ozeki brings you outstanding
SMS Gateway technology. Use our SMS Server products on Windows,Linux, or Android
C# SMS API
Developers can use our C# SMS API to send SMS from C#.Net. The C# SMS API comes with full source code
PHP SMS API
The ozeki PHP SMS gateway software can be used to send SMS from PHP and to receive SMS usig PHP on your website
SMPP SMS Gateway
SMS service providers use our SMPP gateway solution, that offers a high performance SMPP server and SMPP client gateway with amazing routing capabilities
Inbound SMS Routing
This page explains how to configure inbound routing for SMS messaging using the graphical user interface of the Ozeki NG - SMS Gateway software. This guide features step-by-step instructions to enable you to successfully configure inbound routing by editing the inbound routing table. It also includes brief analysis of how the inbound routing table applies to example SMS messages.
The term routing refers to selecting paths in a computer network along which to send data. Routing directs forwarding, the passing of logically addressed packets (e.g. SMS messages) from their source toward their ultimate destination through intermediary nodes (called routers).
In inbound routing the source is a GSM service provider (referred to as Provider in the routing table - see the sections below). In outbound routing the source is a user or application (referred to as User in the routing table).
In inbound routing the destination is a user or application (from now on referred to as user). In outbound routing the destination is a service provider connection.
The routing of both incoming and outgoing messages is defined from the user's viewpoint. The user is a person or a program involved in SMS messaging using Ozeki NG - SMS Gateway.
By configuring the routing of incoming messages, you define for the program which user(s) to deliver an incoming message to (inbound routing).
By configuring the routing of outgoing messages, you define for the program which service provider connection to use when sending out a message from a user (outbound routing).
To route incoming and outgoing messages, you need to set routing rules. You can set routing rules by editing the routing tables of Ozeki NG - SMS Gateway.
The construction of routing tables is essential for efficient routing. (You can find an instructive example of configuring outbound routing to reduce the costs of SMS messaging on the Least Cost SMS Routing page.)
The software allows you to configure the routing of both
incoming and outgoing messages.
To find out how to edit the inbound routing table and
how it applies to example SMS messages, read the sections below.
To find out how to edit the outbound routing table and how it applies to example SMS messages, check out the Outbound SMS Routing page.
Editing the inbound routing table
An incoming message can be destined to one or more users. To route incoming messages, you need to edit the inbound routing table of Ozeki NG - SMS Gateway.
The inbound routing table is composed of any number of rows of cells. Each row is a routing rule, and each cell contains a directive.
The engine processes the routing table step by step, from the first to the last row. It compares the Provider and the conditions (Sender, Receiver, Keyword) as directives to the properties of a message.
It goes through the routing rules from top to bottom, checking if the properties of a message match the directives of a routing rule. If there is a match, the message will be delivered to the User specified in the rule.
The Mode directive in a rule can be either move or copy. If the mode is move, the routing will finish, and the subsequent rules will be ignored. If the mode is copy, the routing will continue, and if there is another match, the message will be delivered to another user or other users.
If a message with a given Provider and given conditions is destined to more than one user, you need to set a separate rule for each user. The order of rules in the table matters only if the Mode is move. It should only be move in the last of the rules intended to apply to a message with a given Provider and given conditions.
To set a rule in the inbound routing table, take the following steps:
Click the Edit button in the top right-hand corner of the Inbound routing panel. This panel can be found in the client area (the middle section) of the Management Console. You can also start editing an inbound routing rule by clicking the Inbound routing item in the Edit menu (Figure 1).
This will bring up a panel where you can choose to add, edit or delete a routing rule. These tasks have respective buttons.
Click the Add button to add a new rule to the routing
To edit (modify) a rule which is already included in the table, click the Edit button beside it.
To delete a rule included in the table, click the Del button beside it (Figure 2)
Next, fill in the edit boxes and select the respective items from the dropdown menus. Give a rule any name you like in the Route name edit box.
Select the GSM service provider connection in the Source
(Service provider) menu. Which service provider the message comes from is
one of the properties of the message.
Note that you can only select a service provider connection you have installed and configured. To find out how to install and configure service provider connections, check out the Service Provider Connectivity page.
Next, enter the conditions in their respective edit boxes: the sender's phone number, the receiver's phone number and the keyword. The keyword is the first word of the SMS message. If you do not wish to specify one or any of these conditions, enter ANY in the edit box next to the condition.
Select the destination from the dropdown menu. The destination
is the user that a message is destined to. If you select ANY, all the
installed users will receive the message the rule applies to.
Note that you can only select a user you have installed and configured. To find out how to install and configure users, check out the Users and Applications page.
Select the Mode in the Mode menu. If you
select move, the routing will stop (if the rule matches a message).
The user specified in this rule will be
the last to receive the message. In this case, no other users specified in
subsequent rules will receive a copy of the message, even if those rules
match the message as well.
To make the program match subsequent rules with the message, select copy (Figure 3).
Click OK when you have finished editing the rule.
Then the rule will be included in the inbound routing table.
You can change the position of a rule in the routing table.
To move a rule one position higher, click the green arrow beside it.
To move a rule one position lower, click the red arrow beside it (Figure 4).
Routing analyses of example SMS messages
This section provides brief analyses of how example SMS messages are routed according to the example routing table below (Figure 5).
Facts: Vodafone operates with +3670*
T-mobile operates with +3630*
a) Sender: +3670123456789 Receiver:
+3670987654321 Message: foobar
Routing decision: The message is to be delivered to admin (inbound0) and sql1 (defaultin).
Explanation: The "foobar" SMS is from Vodafone (service provider), as the phone number starts with +3670*. The Provider in the first routing rule (inbound0) in the inbound routing table above (Figure 4) is Vodafone. The property of the message (the fact that it is from Vodafone) matches the directive specified in the rule ("Vodafone"). The other conditions are specified as ANY. As a result, the admin user will receive the message. This routing rule is in copy mode, so the message will be forwarded to the next routing rule (inbound1) for matching. However, this rule only applies to messages from T-mobile (service provider). Therefore, the program will go on to the next one, which is the defaultin routing rule. It applies to any message from any service provider, any sender, any receiver and any keyword. As a result, the message will be delivered to the sql1 user, which is the last step in the routing process.
b) Sender: +36301111111
Receiver: +3670987654321 Message: foobar
Routing decision: The message is to be delivered to sql1 (defaultin).
Explanation: The "foobar" SMS is from T-mobile (service provider), as the phone number starts with +3630*. The Provider in the first routing rule (inbound0) is Vodafone, and not T-mobile. Consequently, the program will go on to the next (second) routing rule (inbound1), where the Provider is T-mobile. The message text ("foobar") does not match the keyword ("GAME1") specified in inbound1. As a result, the program will go on to the next rule (defaultin, the last in the example), and the sql1 user will receive the message. As the last routing rule is in move mode (and there are no further rules), the message will be delivered to sql1, and the routing will finish.
c) Sender: +36301111111
+3670987654321 Message: GAME1
Routing decision: The message is to be delivered to http1 (inbound1).
Explanation: The "GAME1 bar" SMS is from T-mobile (service provider), as the phone number starts with +3630*. The Provider in the first routing rule (inbound0) is Vodafone. As it is not T-mobile, the program will go on to the next (second) routing rule (inbound1), where the Provider is T-mobile. The first word ("GAME1") of the message text ("GAME1 bar") matches the keyword in the routing rule (inbound1). As the route is in move mode, the routing will finish.
Message: GAME1 bar
Routing decision: The message is to be delivered to sql1 (defaultin).
Explanation: The "GAME1 bar" is from a phone number starting with +3620*. The telephone number in this example (starting with +3620*) does not match the Provider (Vodafone) in the first routing rule (inbound0), so the engine will go on to the next rule (inbound1), where the Provider is T-mobile. The +3620* phone number does not match T-mobile either. The third routing rule (defaultin) does not specify a service provider (there is ANY in the cell), and the conditions (Sender, Receiver, Keyword) are not specified either (there is ANY in the respective cells). Consequently, the message will be delivered to the sql1 user. As the last routing rule (defaultin) is in move mode (and there are no further rules), the routing will finish.
Note that the routing will finish after the last rule is matched, regardless of the Mode (move or copy).
- Load Balancing
- SQL SMS routing
- Inbound SMS Routing
- Outbound SMS Routing
- Least Cost SMS Routing
- Backup SMS Routing
- Send message to multiple recepient
- How to schedule an SMS message