Skip to main content
SMPP is a persistent TCP session. You bind once, keep it open, and submit over it — which is why it outperforms one HTTPS call per message at sustained volume.

​
What you need

Ask your provider for:
An HTTP credential cannot bind, and an SMPP credential cannot use the REST API. Credentials are typed, and the two are not interchangeable. Ask for one of each if you need both.

​
Which bind type

A receiver-only bind sends nothing and looks perfectly healthy. If your session is up and no messages leave, check the bind type before anything else — this is the single most common “bound but nothing happens” cause.

​
The limits that apply to you

Your provider sets these; knowing they exist saves guessing at a refused bind. Window size is the one that shapes your throughput. It is how many submit_sm you may have outstanding without a response. A client that waits for each response before sending the next is limited by round-trip time no matter how large the window is.

​
If your bind is refused

Four causes, and the refusal does not always distinguish them:
1

Wrong credential type

An HTTP login. Refused as an authentication failure.
2

Wrong system_id or password

Case-sensitive, both.
3

A limit already reached

Another session of yours is still open — including a stale one the far end has not yet timed out.
4

Your IP is not allowed

If an allow list is configured, everything else can be right and the bind still fails.
A stale session is the surprising one. If you reconnect faster than the server drops your previous session, you are competing with yourself for a per-user limit. Unbind cleanly on shutdown, and let enquire_link detect a dead peer rather than reconnecting aggressively.

​
Keeping the session alive

Send enquire_link on an interval — every 30 seconds is typical. It is how both ends notice a connection that has died without a FIN, which is the normal outcome of a NAT timeout or a firewall reaping an idle flow. Your library almost certainly does this for you. Confirm it, because a session that is dead but not closed accepts your submit_sm into a socket buffer and loses them.

​
No bind address on the listener

Worth knowing if you are asking your provider to restrict access: both listeners bind every interface, and there is no bind-address setting — the underlying library has no such option. Restricting exposure is done with a firewall, a network namespace, or by binding the container to one interface. If your provider tells you a listener is “only on the internal interface”, that is something they arranged around the gateway, not in it.

Submitting messages

submit_sm, encoding, and the fields that matter.

Listener settings

Every listener and vendor property.