SMPP (Short Message Peer-to-Peer) is an open, industry standard protocol designed to provide a flexible data communications interface for the transfer of short message data between External Short Message Entities (ESME), Routing Entities (RE) and Message Centres (MC). The SMPP protocol is a means by which applications can send SMS messages to mobile devices and receive SMS from mobile devices.
Services from Melrose Labs (e.g. Tyr SMS Gateway) support SMPP v5 and the earlier versions, v3.3 and v3.4. The v5 specification is the latest and final version of SMPP that was published, is the most capable version, and is the best version to read for an understanding of SMPP. To secure the link between the ESME and the MC, SMPP over TLS, or SMPP over VPN can be used.
Tyr SMS Gateway
This section provides details specific to the use of SMPP with the Tyr SMS Gateway service. Accounts may be configured different to the defaults shown below and therefore you should check your SMPP Account Details issued by Melrose Labs for details specific to your account.
Connect to any of the following hosts using your SMPP account details:
|London, United Kingdom|
|af-za.mlsmpp.net||Cape Town, South Africa|
|na-us.mlsmpp.net||North Virginia, USA|
|sa-br.mlsmpp.net||São Paulo , Brazil|
Live Coming Soon Planned
Non-TLS and TLS connections can be made depending on port use:
SMPP over TLS
We strongly recommend the use of SMPP over TLS to secure sessions between applications and our access node hosts. TLS v1.1 and v1.2 are supported. Earlier versions of TLS and SSL are deliberately not supported.
For legacy applications that do not support TLS, we recommend the use of stunnel for using SMPP over TLS.
|Bind types||SMPP versions||Maximum binds||Submit window size||Max. submit rate||Character Sets|
|TX, RX, TRX||v3.3, v3.4 (default) or v5||10 per host||20||2000 SMS/sec||GSM (data_coding=0)
|Session Management||Message Submission||Message Delivery||Anciliary Submission|
Full details of the Tyr SMS Gateway SMPP support can be found in the SMPP Protocol Implementation Conformance Statement (PICS).
Delivery receipts and intermediate notifications have the following format and are contained in the
short_message field of the
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE text:
- id: message ID returned in submit_sm_resp (up to 64 characters in length)
- sub: number of messages originally submitted (set to 001)
- dlvrd: number of messages delivered (000 or 001)
- submit date: When message was submitted by ESME
- done date: When message reached final state
- stat: State of message (see Name field below)
- err: Error encountered during delivery (if any)
Additionally, the following TLVs are present in the delivery receipt:
|receipted_message_id||MC message ID of message being receipted. Should be present for MC Delivery Receipts and Intermediate Notifications.|
|message_state||Delivery state as shown in below table.|
|network_error_code||Error code specific to a wireless network (see error codes below).|
|0||Scheduled||SCHEDLD||The message is scheduled. Delivery has not yet been initiated. (Intermediate)|
|1||Enroute||ENROUTE||The message is in enroute state. (Intermediate)|
|2||Delivered||DELIVRD||Message is delivered to destination. (Final)|
|3||Expired||EXPIRED||Message validity period has expired. (Final)|
|4||Deleted||DELETED||Message has been deleted. (Final)|
|5||Undeliverable||UNDELIV||Message is undeliverable. (Final)|
|6||Accepted||ACCEPTD||Message is in accepted state. (Final)|
|7||Unknown||UNKNOWN||Message is in invalid state.|
|8||Rejected||REJECTD||Message is in a rejected state. (Final)|
|9||Skipped||SKIPPED||The message was accepted but not transmitted or broadcast on the network. (Final)|
|1||Unknown subscriber||MSISDN is unknown or invalid|
|27||Absent subscriber||Mobile is switched off or unreachable|
|31||Subscriber busy for MT SMS||MSC is busy communicating with the handset for another transaction (may be receiving another SMS simultaneously)|
|34||System failure||SS7 protocol or network failure|
Session Management Operations
These operations are used to establish and maintain an SMPP session.
The purpose of the SMPP bind operation is to register an instance of an ESME with the MC system and request a SMPP session over this network connection for the submission or delivery of messages. Thus, the Bind operation may be viewed as a form of MC login request to authenticate the ESME entity wishing to establish a connection.
- bind_transmitter / bind_transmitter_resp
- bind_receiver / bind_receiver_resp
- bind_transceiver / bind_transceiver_resp
- unbind / unbind_resp
Message Submission Operations
Message submission operations provide an ESME with the ability to submit messages for onward delivery to mobile stations.
Message Delivery Operations
Message delivery operations provide the means of delivering short messages from a MC to an ESME. These messages typically originate from mobile stations.
Message Broadcast Operations
Message broadcast operations provide Cell Broadcast services to ESMEs.
- broadcast_sm / broadcast_sm_resp
- Broadcast TLVs
Anciliary Submission Operations
Ancillary submission operations provide additional management of messages submitted by ESMEs. This includes cancellation, querying and replacement of messages.
- cancel_sm / cancel_sm_resp
- query_sm / query_sm_resp
- replace_sm / replace_sm_resp
- Message Replacement TLVs
Anciliary Broadcast Operations
Ancillary broadcast operations provide additional management of messages submitted by ESMEs. This includes cancellation and querying of messages.
- query_broadcast_sm / query_broadcast_sm_resp
- Query Broadcast TLVs
- cancel_broadcast_sm / cancel_broadcast_sm_resp
- Cancel Broadcast TLVs
SMPP PICs statement (based on SMPP PICS at smpp.org ) for Melrose Labs Tyr SMS Gateway and SMPP SMS Gateway.
For the full SMPP v5 specification , and further information on the SMPP protocol, see SMPP - Short Message Peer-to-Peer protocol at smpp.org .