Errors and limits

The bind is refused

After any refused bind the server sends unbind and closes the connection. The reason is in the command_status of bind_resp:

Code	What it means	What to do
0x0F	The login or the password does not match	Check that system_id is the phone number in international format and the password is the cabinet one. See below if both are right
0x0D	The account may not bind	Turn on the SMPP switch on the API settings screen; check that the address you connect from is in the IP address field, or leave the field empty; make sure the account is active
0x05	The account already has as many sessions as allowed, or this connection is already bound	Close the sessions you no longer use, or ask support to raise the limit. One connection carries one bind

0x0F with the right login and password has three more causes:

• Too many failed attempts. After twenty failed binds from one address or for one login within five minutes, every further bind is refused until those five minutes are over — even with the right password. Fix the settings, wait, and connect again.
• The account is locked after failed sign-ins. Failed binds count together with failed sign-ins to the cabinet; past the limit the account stops accepting the password. Ask support.
• The password was set in the old cabinet and never changed since. Set a new password in the cabinet: the bind accepts only the current kind of password.

0x0D can also come for a few seconds during maintenance on our side: if the settings are right, connect again in a minute.

submit_sm is refused

These errors come straight in submit_sm_resp, and the message is not accepted:

Code	What it means
0x0A	source_addr is empty or too long: up to 11 characters for a name, up to 15 digits for a number
0x0B	destination_addr has no digits or more than 20 of them
0x45	Unsupported data_coding, or the UDH length does not match the message
0x0D	The account was blocked during the session
0x14	A temporary failure on our side — send the same message again a little later
0x08	An internal error — send again; if it repeats, ask support

Everything else — the balance, the recipient, the sender name, the text — is checked after the message is accepted, and a message that fails comes back as a REJECTD receipt with a code in err:: see Delivery receipts.

What the session does not understand

The session handles bind_transmitter, bind_receiver, bind_transceiver, submit_sm, deliver_sm_resp, enquire_link and unbind. query_sm, cancel_sm, replace_sm, submit_multi and data_sm are answered with 0x03 — the session stays up, but nothing is done. The status of a message comes only in its receipt.

Limits

What	Limit
Sessions per account	Limited; a bind over the limit gets 0x05
Unanswered submit_sm (window)	No fixed limit: the PDUs of one connection are handled one by one, in order, and every answer comes before the next PDU is taken
Sending speed	No limit per session
Unacknowledged receipts per session	20
short_message	255 octets
One PDU	64 KB
Silence from your side	About three minutes without a single PDU, and the session is closed
Failed binds	20 in five minutes from one address or for one login

When something does not work

• The connection does not open. Check the outgoing rules of your firewall: the addresses are on the page IP addresses. The commands on the page SMPP connection show whether the entry is reachable from your server.
• TLS does not connect. Connect by the name smpp-tls.…, not by the address, and make sure your client sends the name (SNI): the certificate is chosen by it.
• The session drops every few minutes. Send enquire_link every 30–60 seconds.
• No receipts. Receipts come only to receiver and transceiver sessions — a session bound as a transmitter gets none. Check that you answer every deliver_sm, and that another session of the account does not take the receipts.