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.

Introduction

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

opening the rouing editor panel in sms gateway
Figure 1 - Opening the panel for editing the routing table

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 table.
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)

adding a new rule in sms server
Figure 2 - Starting to add a new rule to the routing table

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

editing a new rule in sms server
Figure 3 - Editing a new rule

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

finishing the new rule in sms gateway
Figure 4 - New rule in the routing table

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

an example of a routing table in sms gateway
Figure 5 - Example routing table

Facts: Vodafone operates with +3670*
            T-mobile operates with +3630*

Examples:

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 Receiver: +3670987654321 Message: GAME1 bar
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.

d) Sender: +36202222222 Receiver: +3670987654321 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).

FAQs

What is outbound SMS routing and how can I use it?

Outbound SMS routing is a crucial aspect of managing SMS messaging. When you want to send an SMS message, outbound routing comes into play. It helps you decide which SMS service provider connection to use for sending the message. If your system has multiple SMS service provider connections available, you can configure outbound routing to achieve various goals. Here are some common scenarios:

Backup SMS Routing: Imagine you have two or more connections. In this case, you can designate one connection solely for backup purposes. If the primary connection fails, the backup connection takes over.

Least Cost Routing: To optimize costs, you can route messages based on telephone number prefixes. For example:

  • If an SMS is sent to a phone number starting with +3670, route it through MTN.
  • If it starts with +3630, route it through T-Mobile.
  • If it starts with +3620, route it through Orange.
  • All other SMS messages can be routed to Vodafone1.

Load Balancing: Outbound routing can also distribute the message load across different connections, increasing overall message throughput.

You set up outbound routing by editing the outbound routing table. This table defines conditions (such as sender phone number, receiver phone number, or message text) and maps them to specific service provider connections. For example, if the message is sent by user “sqlexpress” and matches certain conditions, it will be sent using the “HttpServer” service provider connection.

Is there a way to define outbound rules by phone ranges. I want to route a certain prefix to a certain carrier, is this possible?

To define outbound rules based on phone number ranges, you can use regular expressions in the outbound routing table.

Regular expressions allow you to create flexible patterns for matching phone numbers. You can define these patterns for both sender and recipient phone numbers in the routing conditions.

Recipient Phone Number Prefix Routing:

Suppose you want to route outgoing messages based on the recipient phone number prefix (e.g., +3620).
In your outbound route configuration, set up “condition 2” with the following regular expression:
/^[+]3620.*/

Let’s dissect this:

  • The ^ character indicates that the matching should start from the first character.
  • [+] means that the phone number starts with a plus sign.
  • 3620 specifies that the phone number should start with +3620.
  • The .* wildcard allows any phone number to follow.
Example:
If a message is destined for a phone number like +36201234567, it will match this condition and be routed accordingly.

More information