SMPP ESME trunk#

An SMPP ESME (External Short Messaging Entity) trunk lets your application connect directly to the DIDWW SMSC (Short Message Service Center) to send and receive SMS. Once bound, your application can submit outbound SMS. To also receive SMS, assign the trunk to one or more DIDs that support inbound SMS.

Use this trunk type when your application connects to DIDWW as an SMPP client. If DIDWW should bind to your own SMSC instead, use an SMPP SMSC trunk.

How SMPP ESME trunks work#

In SMPP, an ESME is an external application that connects to an SMSC to send and receive SMS. With an SMPP ESME trunk, your application is the ESME and DIDWW is the SMSC. Your application opens the connection and performs the bind with the trunk’s System ID and Password.

Each trunk uses the DIDWW SMPP server of its Server location: US, NY or NL, AMS. The location determines the Host that your application binds to. Your application connects on port 2775 for SMPP over plain TCP or on port 2776 for SMPP over TLS. Both ports use the same credentials. For the TLS requirements, see SMPP over TLS.

Your firewall must allow your application to open connections to the IP address of the trunk’s Server location. The trunk’s Allowed IP addresses setting can also limit the IP addresses that are authorized to connect. If the setting is empty, all IP addresses are allowed.

The DIDWW User Panel shows whether your application is currently bound to the trunk. Checking the status does not connect your application. Only your application can establish the bind.

Inbound and outbound message flows#

Your application and DIDWW exchange messages over the bind as SMPP Protocol Data Units (PDUs):

Outbound SMS: Your application submits each message with submit_sm.
Inbound SMS: DIDWW delivers messages sent to the DIDs assigned to the trunk with deliver_sm.
Delivery receipts: DIDWW returns delivery receipts (DLRs) for outbound messages with deliver_sm.

The receiving side acknowledges submit_sm with submit_sm_resp and deliver_sm with deliver_sm_resp. 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 outbound["Outbound SMS"]
        direction LR
        app_out["Your application (ESME)"] --> |"submit_sm"| trunk_out["SMPP ESME trunk"]
        trunk_out --> |"SMS"| recipient["Recipient"]
        trunk_out -.-> |"deliver_sm (DLR)"| app_out
    end

    subgraph inbound["Inbound SMS"]
        direction LR
        sender["Sender"] --> |"SMS to DID"| did["Assigned DID number"]
        did --> trunk_in["SMPP ESME trunk"]
        trunk_in --> |"deliver_sm"| app_in["Your application (ESME)"]
    end

    outbound ~~~ inbound

    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 app_out,app_in,recipient,sender endpoint
    class trunk_out,trunk_in,did process

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

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

Long SMS are sent as concatenated (multipart) messages. DIDWW delivers each part of an inbound multipart SMS in a separate deliver_sm that carries a User Data Header (UDH) in the short_message field. Your application must process the UDH and reassemble the parts. When your application sends a long SMS, it submits 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 application.
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 ESME trunk.

Failover with SMS trunk groups#

An SMPP ESME 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.