Introduction to EMG - Nordic Messaging

This article gives a brief introduction to the EMG concepts and workings.

What is EMG?

EMG is a messaging gateway / router that receive and forward messages, normally SMS, via different protocols such as SMPP, HTTP, SMTP (e-mail) and more.

EMG stands for high performance, flexibility and reliability.

EMG Portal is a web based add-on providing an easy to use frontend for managing the EMG server and client accounts.

There are different EMG use cases but two common ones are

EMG as a SMS aggregator / service provider platform
Protocol conversion (SMPP <-> UCP, e-mail <-> SMS etc)

Operating environment

EMG runs in Linux and we currently recommend running EMG on CentOS / RedHat Linux 7, 64-bit.

Standard server hardware such as a Dell PowerEdge server or equivalent from another hardware supplier will be able to handled several hundred messages per second (mps).

For storage, SAS or SSD disk in a RAID configuration using a hardware RAID controller will provide the necessary I/O throughput and reliability.

The EMG platform can be installed with EMG, EMG Portal and a MySQL database running on a single server.

Connectors

A connector in EMG implements one of the supported protocols and handle incoming or outgoing connections using that protocol.

For example a connector definition for a connector that handles incoming SMPP connections from customers would look something like this:

CONNECTOR smpp-in1 <
TYPE=INCOMING
PROTOCOL=SMPP
ADDRESS=0.0.0.0:2775
INSTANCES=10
USERDB=emg
>

An incoming SMPP connector that listens to port 2775 on all local ip addresses on the server. A max of 10 simultaneous connections are handled and inbound connections are authenticated from database.

A sample outbound connector for connecting to providerA via SMPP:

CONNECTOR smpp-providerA <
TYPE=OUTGOING
PROTOCOL=SMPP
ADDRESS=192.168.0.1:2775
INSTANCES=1
USERNAME=myUsername
PASSWORD=secret
STATIC
KEEPALIVE=60
IDLETIMEOUT=90
>

An outbound connector initiating a single SMPP connection to IP address 192.168.0.1 and port 2775. Login credentials are specified and the connector being “static” means it will always try to bind even if there is currently no messages to send.

A keepalive packet will be sent every 60 seconds if there is no other traffic and if 90 seconds has passed without any activity the connection will be torn down (and a reconnect will then be made since the connector is static).

The above are sample definitions from the EMG configuration files. When using EMG Portal the configuration is done in the EMG Portal web interface.

Basic message flow

The most basic message flow would be that EMG receives a message from a client on one connector (A), makes a routing decision and forwards the message to an operator / provider via another connector (B).

Normally a delivery report (DLR) would be requested for the message as well and when delivery to the recipient has been completed EMG would receive the delivery report from operator via connector B and route it back to the client via connector A.

Delivery reports (DLRs)

Delivery reports will, in most cases, be provided from the operator after succesful (or failed) delivery of the SMS to the receiving handset, if such a delivery report has been requested.

When a message is received from a client, EMG will create a “open delivery report” entry which will be used later to match the delivery report received back from the operator / provider.

EMG provides a lot of functionality in regards to delivery reports and it is also possible to inject delivery reports into EMG when delivery reports will not be automatically received from remote entity.

Queues

EMG keeps an outgoing queue per connector. It is usually not desirable to let queues grow within EMG expect for a shorter period of time with connectivity problems towards a provider, for example.

It is possible to limit the max total queue size within EMG or per connector. When the queue size has reached the specified limit, any attempts to send new messages to EMG will be rejected.

EMG Portal provides an easy way to clear a queue or move a queue from one connector to another.

Routing

Virtually any kind of message routing can be implemented in EMG but in the standard set up with EMG Portal a routing table can be managed that enabled routes to be defined based on recipient prefix, sending account, receiving and sending connector.

A more specific route will take priority over a more general route.

Billing

In the same way that routes are defined, price (and cost) per message can be defined depending on recipient number prefix, sending account and connectors involved.

EMG does not generate invoices but each message will be tagged with the price information from the matching price entry and that price information will be stored in the message log in the database (table “routelog”).

It is then possible to generate invoice data from the database per client account for a specific period in time.

EMG can also keep track of a “charge balance” per account and each account can be defined as pre-paid or post-paid. For a post-paid account a negative balance is allowed but not for a pre-paid account.

Reporting

In EMG Portal there a a few different messages reports available directly in the web interface “out of the box” but in addition to this custom reports can be generated directly from the database.

Since the message log (table “routelog”) in the database can grow rapidly in a server with high traffic, an aggregation script is provided which will aggregate message data per hour thereby enabling much faster generation of reports.

Extending EMG

EMG can be extended and its behaviour customized through the use of plugins and custom connectors. Such plugins and custom connectors can be implemented in Perl.

A plugin hooks in to the message flow and allows custom code to be executed.

Sample use cases for plugins can be rejecting message based on message properties such as addresses or content, routing based on information in external systems and more.

EMG watchdog

The EMG watchdog enables external entities to monitor and control the EMG server process.

For example the EMG watchdog can be used from within the EMG Portal web interface to stop and start the EMG server process.

It also enables displaying EMG server log files in the web interface thereby eliminating the need to use the Linux command-line interface for many tasks.