Text us or call us on : 011 33 20 30 40

Interface

Developing and implementing your SMPP based application can be difficult to do without an industry standard test platform. We offer a fully compliant SMPP test profile as part of our wholesale service. The test profile allows your developers to simulate a real production environment (including delivery receipting) without incurring the costs of sending messages.

Introduction to the aql SMPP Service

aql supports SMPP v3.4. The following contains a list of the PDUs supported by aql:

Client to aql

  • BIND_TRANSMITTER
  • BIND_RECEIVER
  • BIND_TRANSCEIVER
  • ENQUIRE_LNK
  • SUBMIT_SM
  • QUERY_SM
  • UNBIND
  • DELIVER_SM_RESP

aql to Client

  • BIND_TRANSMITTER_RESP
  • BIND_RECEIVER_RESP
  • BIND_TRANSCEIVER_RESP
  • DELIVER_SM
  • ENQUIRE_LINK
  • ENQUIRE_LINK_RESP
  • SUBMIT_SM_RESP
  • QUERY_SM_RESP
  • UNBIND_RESP
  • GENERIC_NACK

Binding to aql

There are 2 options available when binding to aql. You can either bind using the transmitter and receiver pair from SMPP v3.3 or bind using the transceiver mode new to SMPP v3.4

When the SMPP account is set up for you, you will be given a username (system_id), password and a system_type value to connect with.

Maximum number of Binds

You are initially restricted to the number of binds you can make to aql. Depending on the version of SMPP you are using it will be either 1 transceiver connection or 1 transmitter and 1 receiver connection. In most cases this is sufficient. If, however, you require this configuration changing on your account, please raise a support ticket via our support system (see bottom of page 1). We will then be able to discuss your needs and make the appropriate changes.

IMPORTANT:

You can only connect to aql via certain IP addresses that you have registered. If you wish to connect from multiple IP addresses, please raise a support ticket via our support system.

Submitting messages to aql

The following table gives a breakdown of the SUBMIT_SM pdu. It contains details regarding each of the parameters of the pdu and how they should be used when passing messages to the aql servers.

ParameterDescription
command_lengthAs in SMPP Specification
command_idAs in SMPP Specification
command_statusAs in SMPP Specification
sequence_numberAs in SMPP Specification
service_typeUse the system_type parameter that is given to you by aql
source_addr_tonSee explanation of source_addr_ton and source_addr_npi at end of this section
source_addr_npiSee explanation of source_addr_ton and source_addr_npi at end of this section
source_addrThe originator to be used for this message. If left blank, the default originator on your account will be used. Either 16 digits (in international format) for a mobile number or 11 alphanumeric characters for text.
dest_addr_tonThe destination number in international format (eg 447911111111
esm_classSee explanation of esm_class and data_coding at end of table
protocol_idNot supported, use any value in accordance with SMPP Specification
priority_flagNot supported, use any value in accordance with SMPP Specification
schedule_delivery_timeIf left blank the message will be sent immediately. To send message at a different time, set the time as defined in the SMPP specification.
validity_periodNot supported, use any value in accordance with SMPP Specification
registered_deliveryIf a delivery report is required set to 1 otherwise set to 0 (zero)
replace_if_present_flagNot supported, use any value in accordance with SMPP Specification
data_codingSee explanation of esm_class and data_coding at end of table
sm_default_msg_idNot supported, use any value in accordance with SMPP Specification
sm_lengthLength in octets of the short_message parameter
short_messageThe short message itself as defined by the SMPP specification.

NOTE: Optional parameters are not required by aql and are not supported.

esm_class and data_coding parameters

The following table describes the values that need to be set for the esm_class and data_coding parameters depending on what type of content you require to be sent.

Message typeesm_classdata_coding
Text0000001111110001 or 00000000
Flash0000001111110000
UDH0000001101000000

source_addr_ton and source_addr_npi parameters

When mimicking a mobile number, international format must be used. In this case both source_addr_ton and source_addr_npi must be set to 1. In other cases, it is generally acceptable to leave these parameters set to 0 (zero).

Querying a previously submitted message

aql support the QUERY_SM pdu. This can be used to determine the state of a message at a time that is suitable to you. The table below gives a breakdown of the QUERY_SM pdu and how it should be used with aql.

ParameterDescription
command_lengthAs in SMPP Specification
command_idAs in SMPP Specification
command_statusAs in SMPP Specification
sequence_numberAs in SMPP Specification
message_idThe message id that was originally sent back in the SUBMIT_SM_RESP pdu
source_addr_tonMust be 0 (zero). This is auto-detect mode
source_addr_npiMust be 0 (zero). This is auto-detect mode
source_addrNot used. Set to NULL

The QUERY_SM_RESP pdu is as defined in the SMPP specification.

Error response codes

The error responses that can be sent back are as defined in the SMPP specification. The additional error codes specific to aql are outlined in the table below.

Error codeDescription
0x00000400You do not have enough credits to send message. Please contact us to credit your account.

Delivery Responses

If the register_delivery parameter is set to 1 in the original SUBMIT_SM pdu then a DELIVER_SM response will be sent back to you when the message has reached a final state. This could take anywhere between seconds and hours. Some cases could take even longer.

The following table shows a breakdown of the parameters that are sent in a DELIVER_SM and how to interpret them when received from aql.

ParameterDescription
command_lengthAs in SMPP Specification
command_idAs in SMPP Specification
command_statusAs in SMPP Specification
command_numberAs in SMPP Specification
service_typeThe system_type value that the connection that the message was submitted with is echoed in this parameter
source_addr_tonWill always be 0 (zero).
source_addr_npiWill always be 0 (zero).
source_addrThis is the mobile number that the original message was sent to
dest_addr_tonWill always be 0 (zero).
dest_addr_npiWill always be 0 (zero).
destination_addrThis is set to the originator of the original message.
esm_classAlways set to 4 (00000100)
protocol_idNot used, will always be 0 (zero).
priority_flagNot used, will always be 0 (zero).
schedule_delivery_timeAlways set to NULL
validity_periodAlways set to NULL
registered_deliveryAlways set to 0
replace_if_present_flagAlways set to 0
data_codingAlways set to 0
sm_default_msg_idAlways set to 0
sm_lengthLength in octets of the short_message parameter
short_messageThe short message itself as defined by the SMPP specification.

The short message for a delivery receipt is a string and will look like the following:

"id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . ."

The fields in the delivery receipt are explained in the following table:

FieldSizeTypeDescription
ID10(max)NULL Terminatedid supplied by aql in the original SUBMIT_SM pdu
sub3(max)NULL TerminatedAlways 000
dlvrd3NULL TerminatedAlways 000
submit date10NULL TerminatedDate + time submitted. See SMPP Specification for the format
done date10NULL TerminatedDate + time submitted. See SMPP Specification for the format
stat7NULL TerminatedFinal status of the message. See table below
err3NULL TerminatedAssociated error code. See table below
text20String without NULL terminationWill always contain the text ‘Not available’ (without quotes)

The stat parameter contains the status of the message. The values it can take along with associated error codes are described below:

'stat' value'err' valueDescription
DELIVRD000The message has been delivered
UNDELIV101The message is undeliverable
UNKNOWN102The message is in a final invalid state. It is unknown if the message has been delivered.

In the near future we will be adding additional status codes. This will allows us to pass along more detailed information.

As with all SMPP communications, the aql servers expect a DELIVER_SM_RESP pdu in response to a delivery report.

Terminating the connection

In order to stop the connection to aql you must first issue the UNBIND pdu. aql will send back an UNBIND_RESP pdu at which point it is safe to terminate the connection.

Additional Notes

You will require an SMPP client to send messages via the aql SMPP server. The following section may prove useful in this regard.

There is an excellent open source SMPP client for Linux available at http://www.kannel.org. This provides functionality above and beyond what is required to send messages via aql. It is fairly complex to configure but it is extremely reliable and worth considering.

There is a small SMPP client written in PHP located at:
http://www.phpclasses.org/browse/package/1373.html

If you would like to develop your own SMPP client then there is a Java API available to download. This can be found at:
http://www.logicacmg.com/wirelessnetworks
http://opensmpp.logica.com/
https://sourceforge.net/projects/smstools/

An equivalent Perl API is available at:
http://search.cpan.org/author/SAMPO/Net-SMPP-1.03/SMPP.pm

SMPP Specification

If you require the SMPP v3.4 specification, this can be downloaded from the following site:
http://www.smpp.org/doc/public/index.html

If you need further information relating to SMPP, a good starting point is:
http://www.smpp.org