We offer support for SMPP version 3.4 which is the industry standard protocol for sms communication. Our setup provides redundant connection options with an endpoint pointing at two different locations.
In order to connect, you need the following:
|system_id||Individual per account|
|password||Individual per account|
|port||2775 (ssl is required for all connections - no support for non-ssl)|
|ConnectionMode||Individual per account|
In order to get an SMPP system id, please contact us at support@inMobile.com.
Encryption over ssl/tls
As stated previously, all communication must happen on encrypted connections. This requires for the applications to download and use the certificate used at https://mm.inmobile.dk (The certificate is a wildcard certificate for *.inmobile.dk).
Supported messages types
|Data coding||Hex value||Binary encoding|
|Default Class 0||0x10||GSM7|
|UCS2||0x8||UTF-16 (big endian byte order)|
|UCS2 Class 0||0x18||UTF-16 (big endian byte order)|
Data codings are mapped to binary encodings according to the table above, e.g. when using data coding UCS2 the binary data must be UTF-16 encoded. In some languages, e.g. C#, this is known as "Big endian unicode". UCS2 is a subset of UTF-16, so using UCS2 specifically on the client side will also work just fine.
The error code in this example (005) is the absolute value of the message status code -5 defined here:
Example of our delivery report formats
id:ble50673-f8b8-41e8-a143-07a43bb8c86b sub:001 dlvrd:001 submit
date:1911121314 done date:1911121314 stat:DELIVRD err:000
To get deliver_sm or incoming messages via SMPP, you’ll have to log in to your inMobile account, and set up PDU forwarding to your system_id.
Contact support for further help, with setting this up.
The source_addr parameter has a max length of 15 characters. If the source_addr parameter is any longer, anything after the 15th character, will be discarded.
SMPP is an async protocol meaning that multiple requests and replies may be transported over the wire at a given time. In order to avoid losing any data in case of maintenance or updating our SMPP server, we have taken measures ensuring controlled shutdown and restart.
In the event of an SMPP server system restart, any newly sent submitSm-message will be rejected with the reply ESME_RSUBMITFAIL and clients will be sent an unbind message. Right after, the connection will be disconnected. In case a client tries to rebind at the exact time, that a server is about to restart, the bind attempt will be replied with a generic ESME_RBINDFAIL reply.
A typical restart of an SMPP server takes 2 seconds and all planned restarts and maintenance will be informed in advanced to the users of all accounts using our SMPP connection.