EMG 5.5.1 - User's Guide
E. SMSC inter-connectivity checklist
When interacting with an operator in order to set up a connection to an SMSC the following checklist may be useful.
E.1 Your requirements
E.1.1 Send messages
The most common and basic functionality. Message price? Price differences whether the recipient is a subscriber of an other operator, domestic or foreign etc.?
E.1.2 Receive messages
If you want to receive messages addressing the message to the application (EMG) and being able to receive messages sent from phones with SIM cards from different operators can be problematic issues. Pricing?
E.1.3 Type of messages
Will you send plain text messages (max 160 characters) or will you need to send binary message with User-Data Header (ringtones, logos etc). WAP push messages over SMS is another type of message that requires UDH and 8-bit messages. Possibility to send more complex messages also depends on the protocol being used.
When sending text messages the character set is also relevant. What kind of national characters will be sent and how are they supported and handled?
E.1.4 Performance or message volume
What kind of message volume are you calculating with? This is usually measured in messages per second or messages per day. 1 message per second equals to 86400 messages in 24 hours. Pricing usually depends on volume to a high degree.
E.1.5 Support and service
Your operator may have different service and support plans for different types of customers.
E.2 SMSC connection
E.2.1 Type of connection
Does your operator provide TCP/IP, dial-up or X.25 connections. If relevant, how are incoming messages handled. Who initiates the connection, the ESME or the SMSC or both?
Are static connections allowed or should ESME disconnect immediately after sending message(s)? If yes, should keepalives be sent and if so, how often?
Is an idle timeout allowed, that is EMG waits for a specified period of time when the connection is idle before disconnecting?
What messaging protocol is used for communicating with the SMSC.
CIMD2, OIS, SMPP and UCP are the common protocols used. Protocol version is also of interest. There is for example a big difference between SMPP 3.3 and SMPP 3.4. Make sure the type of messages you want to send/receive can be transmitted using the protocol in question.
Are there any restrictions as how many messages per second can be sent?
Can more than one connection be used? (Defined by the INSTANCES keyword. More than one instance for an outgoing connection is usually not necessary.)
What is the maximum throughput the SMSC can handle?
The protocol being used may be asynchronous meaning that it may be possible to send an operation without waiting for the response to the previous operation sent. This enhances performance but makes the application a bit more complex since it must keep track of outstanding operations. However, EMG supports this and it makes sense to find out if the SMSC handles outstanding operations and if so how many.
None of the messaging protocol mentioned above provide any means of security apart from basic authentication with plain text usernames and password. Does the operator provide other kinds of security mechanisms? In case of an TCP/IP-connection access to the service should be restricted based on the ESME source IP address. You will probably have to pay the bill if a malicious person gets hold of the username and password and sends unauthorized messages using your account.
E.3 Getting started
E.3.1 Account information
After installing EMG you need to set up an outgoing connector to the SMSC in question. In order to do this you need your account information. For a TCP/IP connection this includes:
Using this information you should be able to configure your connector and start the EMG server.
E.3.2 Sending the first message
When both EMG and the SMSC are set up it is time to test the connection. The best way to do this is simply to send a message from EMG routed via the outgoing connector to the SMSC. This will verify the connection to the SMSC, the authentication process and finally the delivery of a message.
The behavior in the following situations should also be verified (if relevant):
E.3.3 Receiving a message
If relevant, messages should be sent from a phone to the application.