SMPP SMSC trunk#

An SMPP SMSC (Short Message Service Center) trunk lets DIDWW connect to your own SMSC as an ESME (External Short Messaging Entity). DIDWW delivers SMS sent to the DIDs assigned to the trunk to your SMSC, and your SMSC can send outbound SMS to DIDWW over the same connection.

Use this trunk type when your SMSC or SMPP server should accept the connection from DIDWW. If your application should connect and bind to DIDWW instead, use an SMPP ESME trunk. To receive inbound SMS on an HTTP endpoint or by email, use an HTTP IN trunk or an SMS to Email trunk.

How DIDWW connects to your SMSC#

In SMPP, an ESME is an external application that connects to an SMSC to send and receive SMS. The SMSC stores, forwards, converts, and delivers the messages. With an SMPP SMSC trunk, your system is the SMSC and DIDWW is the ESME. DIDWW opens the connection and sends the bind request, and your SMSC accepts it.

DIDWW connects from the DIDWW SMPP server of the trunk’s Server location: US, NY or NL, AMS. It uses the Host, ports, System ID, and Password that you enter in the trunk settings, and your SMSC validates these credentials. Your firewall must accept connections from the IP address of the trunk’s Server location. See Server locations and IP addresses.

After you create the trunk, DIDWW starts the bind process automatically. If a connection attempt fails, DIDWW retries it after the trunk’s Connection timeout. The DIDWW User Panel shows whether DIDWW is bound to your SMSC and the reason for the last failed attempt.

Bind direction and message exchange#

The Transceiver mode setting defines how DIDWW binds to your SMSC:

Off (default): DIDWW opens two sessions. The transmitter session on the TX port sends messages to your SMSC. The receiver session on the RX port receives messages from your SMSC.
On: DIDWW opens one transceiver session on the TX port to both send and receive messages. The RX port is ignored.

When Use SSL is on, DIDWW connects to your SMSC over TLS and establishes TLS before it sends the bind request. Use SSL does not change the ports. Your SMSC must accept TLS connections on the ports you enter.

Over the bind, DIDWW and your SMSC exchange messages as SMPP Protocol Data Units (PDUs):

Inbound SMS: DIDWW submits messages sent to the DIDs assigned to the trunk with submit_sm.
Outbound SMS: Your SMSC sends messages to DIDWW with deliver_sm.
Delivery receipts: Your SMSC can return delivery receipts (DLRs) with deliver_sm.

The receiving side acknowledges submit_sm with submit_sm_resp and deliver_sm with deliver_sm_resp. For the bind requests that your SMSC must accept, see Mandatory SMPP SMSC bind parameters. For the PDU details, see SMPP message flow.

        %%{init: {
  "theme": "base",
  "themeVariables": {
    "fontSize": "14px",
    "primaryColor": "#e0f2fe",
    "primaryBorderColor": "#38bdf8",
    "primaryTextColor": "#1f2d3d",
    "secondaryColor": "#ccfbf1",
    "secondaryBorderColor": "#2dd4bf",
    "secondaryTextColor": "#1f2d3d",
    "lineColor": "#0066cc",
    "textColor": "#1f2d3d",
    "nodeTextColor": "#1f2d3d",
    "titleColor": "#1f2d3d",
    "clusterBkg": "#f8fafc",
    "clusterBorder": "#cbd5e1",
    "edgeLabelBackground": "#ffffff"
  }
}}%%

flowchart TB

    subgraph inbound["Inbound SMS"]
        direction LR
        sender["Sender"] --> |"SMS to DID"| did["Assigned DID number"]
        did --> trunk_in["SMPP SMSC trunk (DIDWW as ESME)"]
        trunk_in --> |"submit_sm"| smsc_in["Your SMSC"]
    end

    subgraph outbound["Outbound SMS"]
        direction LR
        smsc_out["Your SMSC"] --> |"deliver_sm"| trunk_out["SMPP SMSC trunk (DIDWW as ESME)"]
        trunk_out --> |"SMS"| recipient["Recipient"]
    end

    inbound ~~~ outbound

    classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px
    classDef process fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px

    class sender,smsc_in,smsc_out,recipient endpoint
    class did,trunk_in,trunk_out process

    style inbound fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d
    style outbound fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d

    linkStyle 0,1,2,3,4 stroke:#0066cc,stroke-width:1.5px

Long SMS are sent as concatenated (multipart) messages. DIDWW submits each part of an inbound multipart SMS to your SMSC in a separate submit_sm that carries a User Data Header (UDH) in the short_message field. Your SMSC must process the UDH and reassemble the parts. When your SMSC sends a long SMS, it sends each part with its own UDH. For encoding limits, concatenation, and how message parts are billed, see SMS encoding reference.

Sender IDs and DID numbers#

DID numbers have a different role in each direction:

Inbound SMS: The trunk, or an SMS trunk group that contains it, must be assigned to one or more DIDs that support inbound SMS. Messages sent to those DIDs are then delivered to your SMSC.
Outbound SMS: DID assignment is not required. The sender ID, also called the source address, depends on the type of message:
- P2P messages use one of your DID numbers as the sender ID. By default, all DIDs with Outbound P2P SMS enabled in your account can be used. In Source Address Settings, you can limit the trunk to specific DID numbers. See P2P Outbound SMS access.
- A2P messages use a verified Sender ID, such as an Alphanumeric Sender ID. Associate an active Sender ID Verification with the SMPP SMSC trunk.

Failover with SMS trunk groups#

An SMPP SMSC trunk can be added to an SMS trunk group with other SMS trunks. When the group is assigned to a DID, DIDWW attempts the member trunks for inbound SMS in priority order, starting with the highest-numbered priority, and tries the next trunk if one is unavailable.