Jump to: navigation, search

Olena

Olena's Test Pages

SMS Server Administration

This page provides general information and recommendations for the administration of SMS Server.

[+] SMS Server Supports SMPP v3.4 Operations.


[+] SMS Server Handles Empty Messages.

Handle Empty Messages

SMS provider may deliver empty messages (no text, no payload), which is a normal situation and these messages should be sent to an agent for a processing.

SMS Server has a configurable option x-smpp-empty-message with a text, which is delivered to an agent as a content of an empty message originally received. The substituting text can be specified as empty string as well.

Mask Sensitive Data in SMS Transcripts and Logs

Process Extra Parameters for PDU

Support Message Throttling by Configurable Rate

SMS Server supports the following SMPP v3.4 operations:

  • BIND_TRANSCEIVER
    BIND_TRANSCEIVER_RESP

    The purpose of the SMPP bind operation is to register an instance of an ESME (External Short Messaging Entity) with the SMSC (Short Message Service Center) system and request an SMPP session over this network connection for the submission or delivery of messages.
  • UNBIND
    UNBIND_RESP

    The purpose of the SMPP unbind operation is to deregister an instance of an ESME from the SMSC and inform the SMSC that the ESME no longer wishes to use this network connection for the submission or delivery of messages.

  • SUBMIT_SM
    SUBMIT_SM_RESP

    This operation is used by an ESME to submit a short message to the SMSC for onward transmission to a specified short message entity (SME).

  • DELIVER_SM
    DELIVER_SM_RESP

    DELIVER_SM is issued by the SMSC to send a message to an ESME. Using this command, the SMSC may route a short message to the ESME for delivery.

  • ENQUIRE_LINK
    ENQUIRE_LINK_RESP

    This message can be sent by either the ESME or SMSC and is used to provide a confidence check on the communication path between an ESME and an SMSC.

 
The protocol referred to in this section is described in Short Message Peer to Peer Protocol Specification v3.4, 12-Oct-1999 Issue 1.2

SMS Server Administration

This page provides general recommendations for the administration of SMS Server. See also how to:

SMS Server supports the following SMPP v3.4 operations:

  • BIND_TRANSCEIVER
    BIND_TRANSCEIVER_RESP

    The purpose of the SMPP bind operation is to register an instance of an ESME (External Short Messaging Entity) with the SMSC (Short Message Service Center) system and request an SMPP session over this network connection for the submission or delivery of messages.
  • UNBIND
    UNBIND_RESP

    The purpose of the SMPP unbind operation is to deregister an instance of an ESME from the SMSC and inform the SMSC that the ESME no longer wishes to use this network connection for the submission or delivery of messages.

  • SUBMIT_SM
    SUBMIT_SM_RESP

    This operation is used by an ESME to submit a short message to the SMSC for onward transmission to a specified short message entity (SME).

  • DELIVER_SM
    DELIVER_SM_RESP

    DELIVER_SM is issued by the SMSC to send a message to an ESME. Using this command, the SMSC may route a short message to the ESME for delivery.

  • ENQUIRE_LINK
    ENQUIRE_LINK_RESP

    This message can be sent by either the ESME or SMSC and is used to provide a confidence check on the communication path between an ESME and an SMSC.

 
The protocol referred to in this section is described in Short Message Peer to Peer Protocol Specification v3.4, 12-Oct-1999 Issue 1.2


SMS Server

  • MASK SENSITIVE DATA IN SMS TRANSCRIPTS AND LOGS (SensitiveData)
    • Data filtering specification
    • Examples of log messages and filtering
    • Examples of log messages and filtering


  • PROCESSING OF EXTRA PARAMETERS FOR PDU

Some SMPP commands (a.k.a. PDU – Protocol Data Unit) may contain a set of optional parameters, which detail additional properties of a command. SMS providers may require to place these optional parameters to correctly process SMPP protocol. SMS Server supports this functionality – it allows to define PDU’s optional parameters: - For an individual PDU’s send operation, i.e. for an individual ESP request, - For all send operations, i.e. for all ESP requests, which do not specify its individual options, by setting a default set of optional parameters. SMPP’s optional parameter is defined as a triplet (tag, length, value), which is referred as TLV value. SMS Server implements the next format of optional parameters: { 

 tlvItems:
 [
   { tag:<tag value>, typ:<value type – str or int or short or byte>, val:<value> }
   . . . MORE TLV SPECIFICATIONS SEPARATED BY COMMAS
 ]

} A parameter’s type defines encoding and data size placed in PDU: - ‘str’ is coded as ASCII sequence (“C-string”) with a length, defined by the string content, - ‘int’ is coded as 4-bytes integer binary value, - ‘short’ is coded as 2-bytes integer binary value, - ‘byte’ is coded as 1-byte integer binary value.


  • HANDLE OF EMPTY MESSAGES

SMS provider may deliver empty messages (no text, no payload), which is a normal situation and these messages should be sent to an agent for a processing. SMS server should have a configurable option with a text, which is delivered to an agent as a content of an empty message originally received, this substituting text may be specified as empty string as well.


  • SUPPORT MESSAGE THROTTLING BY CONFIGURABLE RATE

SMS service provider may impose limits on a rate of SMPP messages they can accept. SMS Server have configurable options that define and limit a rate of sending out messages to the SMSC: - x-smpp-sar-max-segments - x-smpp-submit-window-size - x-smpp-submit-window-timespan - x-smpp-response-max-waiting-time.


Universal Contact Server

Stat Server

This page was last edited on September 16, 2020, at 15:32.
Comments or questions about this documentation? Contact us for support!