NOTE (1): ActiveXperts SMS Component provides developers with a fast and reliable SMPP API. Simply connect to the SMPP provider, bind using your credentials and call SubmitSms to send out the messages. Read more »
NOTE (2): ActiveXperts SMS Messaging Server is an SMS messaging framework to allow sending, receiving and processing SMS messages. It is designed to implement any project that requires SMS messaging. Read more »
In this interface, all time/date related fields will be in ASCII with the following format:
|'YY'||last two digits of the year (00-99)|
|'t'||tenths of second (0-9)|
|'nn'||Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48).|
|'p' - "+"||Local time is in quarter hours advanced in relation to UTC time.|
|"-"||Local time is in quarter hours retarded in relation to UTC time.|
|"R"||Local time is relative to the current SMSC time.|
Where responses are reported by the SMSC the local time of the SMSC will be given, and the format will be "YYMMDDhhmmss", with the same definitions as above.
This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol '+' or '-''
Relative Time can be indicated by setting the UTC orientation flag to 'R' instead of '+' or '-'. In this form, the SMSC interprets the time format as the number of years, months, days, hours, minutes and seconds from the current SMSC time. Values for tenths of seconds 't' and UTC offset 'nn' are ignored and should be set to '0' and '00' respectively.
For example, the following time format "020610233429000R":
An SMSC operator may choose to impose a limit on relative time offsets, thus either rejecting a message that exceeds such a limit or reducing the offset to the maximum relative time allowed.
For example:- a typical validity period might be 7 days and a typical scheduled delivery times might be 14 days from the submission time.
It is recommended that the following timers be implemented for SMPP transmitter and receiver sessions. All timers should be configurable.
Note: Definition of the various timer values is outside the scope of this SMPP Protocol Specification.
|Timer||Action on expiration||Description|
|Timer: session_init_timer||Action: The network connection should be terminated.||Description: This timer specifies the time lapse allowed between a network connection being established and a bind_transmitter or bind_receiver request being sent to the SMSC. This timer should be active on the SMSC.|
|Timer: enquire_link_timer||An enquire_link request should be initiated.||This timer specifies the time lapse allowed between operations after which an SMPP entity should interrogate whether it's peer still has an active session. This timer may be active on either communicating SMPP entity (i.e. SMSC or ESME).|
|Timer: inactivity_timer||The SMPP session should be dropped.||This timer specifies the maximum time lapse allowed between transactions, after which period of inactivity, an SMPP entity may assume that the session is no longer active. This timer may be active on either communicating SMPP entity (i.e. SMSC or ESME).|
|Timer: response_timer||The entity which originated the SMPP Request may assume that Request has not been processed and should take the appropriate action for the particular SMPP operation in question.||This timer specifies the time lapse allowed between an SMPP request and the corresponding SMPP response. This timer may be active on either communicating SMPP entity (i.e. SMSC or ESME).|