Wissenszentrum

Entdecken Sie unsere Bibliothek mit Informationen zu unseren Produkten und Dienstleistungen

Create new SMPP account (system_id)

You can view the list of existing SMPP accounts in the SMPP section. For each account, you can view the status of SMPP binds (connected accounts), troughput of SMS per second, country coverage, list of IP addresses allowed to connect, and the settings. From this page, you may also delete the SMPP account or disconnect any active SMPP bind.

To create a new SMPP account (also called system_id), go to SMPP > New Account

On the next page enter the new account name (only letters and numbers, between 3 and 15 characters) and password (only letters and numbers, maximum 8 characters).

Our SMPP server offers some advanced features that can be customized for each SMPP account directly from the SMS Connexion Dashboard when the account is created.

In the following section, we give more detail on each of these features:

Allowed IP address

The SMPP server can only be accessed by IP addresses on this allowed list. If the list is left blank, any IP address can connect.

You can enter single IP addresses on by line, or you can use a wildcard (*) to enter multiple IP addresses.

Traffic type

Select what kind of traffic you'll be sending through this SMPP account. You can choose between transactional or promotional.

Allowed destination countries

Only SMS sent to the countries in the allowed list will be accepted by the SMPP server. SMS sent to other countries will be rejected. If you leave the list empty, all international traffic will be allowed.

Enforce sender ID (originator)

If this is sender ID is set, it will overwrite the originator with which your SMPP client software has sent the SMS.

Transliterate text

Using this feature the content of your submitted text message will be modified based on the transliteration option you selected.

Transliteration is a character replacement procedure, used in this case to replace Unicode characters or specific alphabet characters to letters in the GSM alphabet. So, our SMPP server will identify the characters that are not part of the 7-bit GSM character set, to avoid the splitting of the SMS in multiple parts, thus saving money with the SMS campaigns.

For example, if your submit_sm command has sent the following text message:

"Votre code de vérification est 55443. Ne le partagez pas avec d'autres s'il vous plaît"
(86 characters, 2 SMS parts, encoding Unicode)

after transliteration, the Unicode letter ⟨î⟩ will be replaced with GSM-7 character ⟨i⟩:

"Votre code de vérification est 55443. Ne le partagez pas avec d'autres s'il vous plait"
(86 characters, 1 SMS part, encoding GSM-7)

You just saved 1 message part from being billed.

Possible transliteration options you can select:

  • NON GSM
  • POLISH
  • TURKISH
  • GREEK
  • ROMANIAN
  • RUSSIAN
  • BULGARIAN
  • UKRAINIAN
  • BELARUSIAN
  • SERBIAN

If "NON GSM" is selected, then all Unicode characters that are not present in the GSM alphabet (standard and extended) will be replaced. This include special characters (© « ± ¢), emojis, cyrillic, arabic, accents, etc.

For transliteration to perform as expected, your SMPP client software must submit long SMS messages using the "message_payload" TLV option in a single submit_sm command, not in multiple segments with UDH headers.

Remove Emojis

This feature will remove all emojis from your submitted SMS messages. This feature can help save money with SMS costs if the message is longer than one SMS part.

For emoji removal to work as expected, your SMPP client software must submit long SMS messages using the "message_payload" TLV parameter in a single submit_sm command instead of sending them in multiple segments with UDH headers.

Quiet Hours

With this feature, you can avoid upsetting clients outside of business hours by mistake. Set a quiet hour interval (usually between 21:00 and 9:00 / 9 PM - 9 AM) and all the SMS sent in this interval will be scheduled to be sent at the end of the interval.

For example, if you set quiet hours from 21:00 to 09:00 and your SMPP client software sends an SMS at 23:05, our SMPP server will schedule the SMS to be sent at 09:01, when the quiet hours end.

The default action for a message detected in quiet hours is to SCHEDULE the SMS delivery, but you can alternatively choose to REJECT the SMS delivery.

Note: The SMPP server time is in UTC. Our SMPP server determines the time for the destination phone number based on its local timezone, and checks if this time is between the Quiet Hours.

Here are some examples to help you understand how "Quiet Hours" work:

  • [ITALY example] If your SMPP client program sends a submit_sm command on 18 August at 20:25 UTC to an Italian phone number, our SMPP server will recognize that the recipient is currently in the interval of "Quiet Hours" because 20:25 UTC translates to 22:25 in Italy (GMT+2).
    The SMPP server will responds with a submit_sm_resp PDU, indicating the success of the request, and schedule the SMS to be sent on August 19 at 9:01 local time in Italy (19 August 07:01 UTC).
  • [UNITED KINGDOM example] If your SMPP sends an SMS on 18 August at 20:25 UTC to a phone number from United Kingdom, our SMPP server will determine that the recipient is the period of "Quiet Hours" because 20:25 UTC translates to 21:25 in United Kingdom (GMT+1).
    The SMPP server will responds with a submit_sm_resp PDU, indicating the success of the request, and schedule the SMS to be sent on August 19 at 9:01 local time in United Kingdom (19 August 08:01 UTC).
  • [SPAIN example] If your SMPP sends an SMS to a Spanish phone number on 18 August at 20:25 UTC, our SMPP server will detect that the recipient is currently in the interval of "Quiet Hours" because 20:25 UTC translates to 22:25 in Spain (GMT+2).
    The SMPP server will responds with a submit_sm_resp PDU, meaning success, and schedules the SMS for August 19 at 9:01 local time in Spain (19 August 07:01 UTC).

Delivery Reports (DLR) Callback

Even though your SMPP client is connected to our SMPP server and gets the delivery report through the deliver_sm command, there may be times when you want to save the delivery report to an external database.

With this feature, you can set a callback URL (also called a "webhook") where our server will send HTTP POST requests with the SMS delivery reports.

Example JSON of delivery report request to your webhook URL

{
    "event": "dlr_update",
    "data": [
        {
            "campaignId": "4dd5e899-6ced-4fd5-bbb6-34e51507e3df",
            "msgId": "4dd5e899-6ced-4fd5-bbb6-34e51507e3df",
            "trackData": "",
            "statusCode": 1,
            "status": "DELIVERED",
            "errorCode": null,
            "datetime": "2022-03-03 15:30:24"
        },
        {
            "campaignId": "a710a44a-e784-4199-b73c-a2c8bfd41b59",
            "msgId": "a710a44a-e784-4199-b73c-a2c8bfd41b59",
            "trackData": "",
            "statusCode": 1,
            "status": "DELIVERED",
            "errorCode": null,
            "datetime": "2022-03-03 15:30:24"
        },
        {
            "campaignId": "4dd5e899-6ced-4fd5-bbb6-34e51507e3df",
            "msgId": "4dd5e899-6ced-4fd5-bbb6-34e51507e3df",
            "trackData": "",
            "statusCode": 1,
            "status": "DELIVERED",
            "errorCode": null,
            "datetime": "2022-03-03 15:30:24"
        }
    ]
}

Note: If multiple delivery reports occurred at the same time, they could be grouped together in the "data" object. One callback request with multiple data object can have up to 200 delivery reports. Therefore, your endpoint must be able to parse and iterate over the entire data object.

If your server can't manage bulk event grouping for any reason, please inform us and we'll change your callback setup to one event per request. You can also request for more or less data objects to be grouped together (eg. 40 events per request, 500 events per request, etc.)

Receive SMS Callback

This allows to enter a a callback URL (or webhook) to which our server will make HTTP POST request with inbound SMS.

SPAM Filter

Use this feature if you want to filter your traffic based on certain rules. When your SMPP client software make a new submit_sm command, our SMPP server will first check if your SPAM filter rules match and REJECT the SMS message if they do.

You can add up to 10 filter rules and use logical conditions OR and AND.

To determine if the conditions have been met, a filter rule uses the "Field", "Condition", and "Value" that have been specified.

The "Field" option indicates where to perform the matching:

  • To: the destination number
  • From: the sender ID (originator)
  • Text: the body of the text message

The "Condition" option instructs how the matching should be done:

  • Contains
  • Does not contain
  • Begins with
  • Ends with
  • Does not begin with
  • Does not end with
  • Matches Regex
  • Does not match Regex

Example 1 - reject messages that contain links

You can use a rule to filter all SMS messages that contain a URL / link. From the "Field" drop-down select Text, the "Condition" needs to be Matches Regex and in the condition value field put this regular expresion that matches any URL in a text:

http(s)?:\/\/)?(www\.)?[-a-zA-Z0-9@:%._\+~#=]{2,256}(\.[a-z]{2,6})?\b([-a-zA-Z0-9@:%_\+.~#?&\/\/=]*)

Now, any SMS sent by your SMPP client software that includes a URL will be rejected.

Example 2 - reject messages with numeric sender ID or a stop word

Create a rule to filter all SMS messages that contain a stop word you define or are sent from a numeric sender ID. From the "Field" drop-down choose Text, the "Condition" should be Contains and in the condition value field put the stop word you want to find (e.g. InvestmentBank).

Click on "Add another rule" with logical "OR", and select field "From", condition "Matches Regex" and set the value ^\d+$

Now, any SMS sent by your SMPP client software that contains the word "InvestmentBank" or is sent from a numeric sender ID will be rejected.

Example 3 - reject messages sent to specific network prefix

Create a rule to filter all SMS messages that are sent to a specified carrier prefix. From the "Field" drop-down choose To, the "Condition" must be Begins with and in the condition value field put 49151. Add another condition with the same rules except you put the value +49151.

Now, any SMS sent to phone numbers that have prefix 49151 (Germany, T-Mobile network) will be rejected.

To use this feature, set your SMPP client software to submit long messages using the "message_payload" TLV parameter in a single submit_sm command.

Text edit

Use this feature if you want to change the content of an SMS message, based on a set of rules. When your SMPP client sends a new submit_sm command, our SMPP server will check to determine whether the text body matches the conditions and replace any matches with your new values.

You can add up to 10 rules to text replacement.

The SMPP server will check if your replace conditions are met to determine if the text of the SMS needs to be changed. If it does, it will change the text of the SMS with the "Replace value" you choose.

The "Condition" option instructs how the matching should be done:

  • Contains
  • Matches Regex

Example 1 - replace SMS that contains links

You can use a rule to detect if the text of an SMS contains links and replace it with different text, or remove it completely. From the "Condition" drop-down select Matches Regex, and in the condition value field put this regular expresion that matches any URL in a text:

http(s)?:\/\/)?(www\.)?[-a-zA-Z0-9@:%._\+~#=]{2,256}(\.[a-z]{2,6})?\b([-a-zA-Z0-9@:%_\+.~#?&\/\/=]*)

In the "Replace value" field type the replacing text. Leave this field empty so the detected links to be removed completely.

Now, any SMS sent by your SMPP client software that includes a link will be changed and links removed.

To make use of this feature, configure your SMPP client to send long messages with the "message_payload" TLV parameter in a single submit_sm command. Refer to sections 4.4.1 and 5.3.2.32 of the SMPP 3.4 specification.

Last updated: Sep 8, 2022

Was this page helpful?

Share