On this page
Connecting an SMPP application
Bind identity, submissions, message IDs, receipts and multipart handling.
Connection contract#
Ask the instance operator for the SMPP host and port, system ID, password, allowed source IP, sender rules and delivery-receipt expectations. The example runtime listener is SMPP_LISTEN_ADDR=:2775. Keep internal control endpoints private.
Submission sequence#
- Establish the permitted SMPP bind using the configured client identity.
- Submit the sender and destination addresses with the required TON/NPI and data coding.
- Set the receipt request as required by your workflow.
- Save the submit response ID and correlate subsequent delivery receipts.
- Distinguish a successful submission response from a final delivery outcome.
PDU field example#
This describes fields, not a new HTTP sending endpoint.
submit_sm
source_addr: YOUR_APPROVED_SENDER
destination_addr: YOUR_TEST_NUMBER
registered_delivery: request receipt
data_coding: 0x00 (GSM) or 0x08 (UCS-2)
short_message: Your verification code is 123456
Encoding and multipart#
Use correct GSM/UCS-2 encoding and a consistent UDH or SAR scheme for multipart messages. The switch buffers multipart groups within its configured timeout and group limit. Reassembled content can be transformed and resegmented; malformed or incomplete multipart traffic should be investigated in event traces.
Voice clients#
The application still submits over SMPP when the account's delivery channel is VOICE. The selected Voice group processes the OTP job. The receipt relay returns results through the existing DLR pipeline.
Diagnose before retrying#
Check bind error, submit status, submit ID, outgoing provider message ID and receipt. Retries without correlation can create repeated customer messages.
Screenshots show fictional data from the public demo. Your instance may have different records and permissions.