SMPP is an industry standard for sending and receiving SMSs. SMPP Tangerine is the current version of our high performance SMPP server, available to high volume customers on request. Please contact Support to enable this feature on your account.
Ensure that your account password is no longer than 8 characters, to maintain compatibility with the SMPP specification.
smpp.bulksms.com on port 2775 (with TLS support on port 3550);2000012345, and not your BulkSMS.com username;| status | code |
|---|---|
UNKNOWN_STATUS |
0x400 |
INVALID_MESSAGE_BODY |
0x401 |
If a deliver_sm contains an MO SMS which is in reply to a previously sent MT SMS, this optional parameter will be set to the message_id that was originally returned in the submit_sm_resp when the MT SMS was accepted.
| Tag code | 0x1400 |
| Value data type | C-Octet String (null-terminated) |
| Value Length | variable |
service_type field. As per the SMPP 3.4 specification, this is a C-octet string, so for the three routing options, the value can be a literal string containing one of “1”, “2” or “3”. If unspecified or invalid, routing group 2 will be used.network_id as supported by some of our other APIs is currently not supported on our SMPP API.SUBMIT_SM limitations apply:
priority_flag is limited to the default settingschedule_delivery_time is limited to the default settingvalidity_period: maximum 21 days after submission time, but destination networks are likely to impose their own, more restrictive limitsreplace_if_present_flag is limited to the default settingsm_default_msg_id is limited to the default settingregistered_delivery supports:
0x00 (no status reports)0x01 (final delivery status outcome of “success” or “failure”)0x01user_message_reference is not currently used but may be used in the future, e.g. to allow customers to implement message duplication avoidance strategies0x05 (alphanumeric TON)0x00 (Unknown NPI)0x01 (International TON)0x01 (ISDN NPI)0x01 (International TON)0x01 (ISDN NPI)+” character)0” digitSUBMIT_MULTI, DATA_SM, QUERY_SM, CANCEL_SM, ALERT_NOTIFICATION.The ESME (SMPP client) is expected to either respond to LINK_ENQUIRE within 60 seconds, or issue its own LINK_ENQUIRE regularly (every 30 seconds recommended), failing which, the session will be dropped.
The BulkSMS SMSC will rate-limit received PDUs at 40 per second. Bursting above this rate into a limited-size buffer can occur but once the buffer is full, PDUs will initially be rejected with an ESME_RTHROTTLED (0x58) status. If the ESME persists in sending at an excessive rate, ignoring throttling responses, PDUs will be dropped without a response. At very high excessive rates, the session may be dropped completely.
ESME_RTHROTTLED (0x58) status.The optional parameters message_state and receipted_message_id are available in deliver_sm PDUs.
Delivery Receipts are also available via the short_message parameter in deliver_sm PDUs. The format is based on the example format in Appendix B of the SMPP specification (which, while just an example in the specification, is widely in use). An example:
id:ab021099504969 stat:DELIVRD err:000 sub:001 dlvrd:001 submit date:1704181518 done date:0101010101 text:...
done date is currently not available for many countries/networks. If unavailable, the field will be set to 0101010101.text is currently always set to ....err: the numeric values used are:
INSUFFICIENT_CREDITS and INSUFFICIENT_QUOTA produce a delivery receipt with:
8 (REJECTED) (see SMPP spec §5.2.28);stat:REJECTD.Advanced usage: for the typical use case you can ignore this feature.
Multiple concurrent binds for the same account are enabled through the use of bind groups. This allows a customer, for example, to have two transmitter binds connected, with MOs and status reports received via a single third receiver bind. The scheme employed allows for various permutations and is controlled by the customer without intervention by BulkSMS.
Binds are grouped by SMPP system type specified by the ESME when binding. Typical ESME system types normally seen are “Logica”, “VMS” and “OTA”. This system type normally has no effect on the operation; the SMPP 3.4 specification describes it as used to “categorize the type of ESME”. In our implementation, the customer can optionally specify a system type that is a numeric string (with supported values from 0 to 99), to indicate which “bind group” this bind should fall under. All transmitter, receiver and transceiver binds using the same numeric system type are seen to form a single “bind group”. Status reports for messages received from transmitters in each bind group will be sent to receiver binds in that same bind group.
Note that we limit the number of concurrent connections per user account, across all that user’s bind groups. The limit is currently set at 10; please contact us if this is a problem.
For example, you have four transmitter binds (we’ll arbitrarily call them A, B, C and D) and two receiver binds (E and F), organised like this:
Delivery reports for messages received on A and B (bind group “0”) will be sent to E, because that is the receiver that is also in bind group “0”. Similarly, reports for messages from C and D will be sent to F. You can have as many bind groups as you need, but the system will limit the number of concurrent SMPP connections in total. You should, however, have at least one transmitter and one receiver/transceiver for each group. Transceivers are also supported, so a single transceiver bind is perfectly acceptable and is the most common configuration.
Any Mobile Originating (MO) messages routed to an SMPP user will always be sent to the “0” bind group, so users should at least have one receiver or transceiver bind in bind group “0”, or MO messages will queue until the system expires them.
Any bind which specifies a system type that is NOT numeric, e.g. “ABCDE”, or “Logica” will be treated as if it specified “0”. The same applies for a bind that doesn’t specify a system type (uses null). The effect of this is that customers who only need a single bind group (the most common case) can use their system’s default settings and their connections will be in group “0”, where it will receive any MO messages as well as all status reports.
A transceiver bind can serve the function of either a transmitter or receiver bind, or both. Consider the following example:
In this example, all four binds are able to send mobile terminating (MT) messages, but only binds C and D can receive status reports (additionally, bind C can also receive MO messages). Status reports for messages sent via transmitter A as well as transceiver C will be sent to the only suitably-capable bind in bind group “0”, which is transceiver C. Status reports for B and D will be sent to D.
The system currently only supports routing MO messages and status reports to one connection per bind group at a time, being the connection to bind and join the bind group last. As a result, load balancing of status reports or MO messages for the same bind group over more than one connection in parallel is currently not supported. Since MO messages are always sent to bind group 0, this means there can currently only be one active bind receiving MOs for a customer at any point in time.
For example, referring to the configuration used in example 1 above, again:
If an additional receiver “G” now connects after the above binds are connected and specifies system type / bind group “0”, then it will replace receiver E’s role and E will stop receiving status reports for group “0” as well as all MO messages. Any further status reports and MOs will now be sent to receiver G instead. Bind group “1” will be unaffected. If receiver E then disconnects and reconnects, still using group “0”, it once again becomes the receiver bind to most recently join group “0”, so status reports and MOs once again revert to E and bind G will no longer receive them.