iPlanet Messaging Server SMS Channel
8 March 2002
The Messaging Server SMS channel is a one-way email to SMS gateway. Mail can be sent to an SMS gateway, but handling of SMS notifications (that is, replies and delivery receipts) and origination of email from SMS users (mobile to email) is presently not supported. The channel converts enqueued email messages to SMS messages as described in Section 3.2. This conversion process includes handling of multipart MIME messages as well as character set translation issues.
The generated SMS messages are submitted to a Short Message Service Centre (SMSC) using the Short Message Peer to Peer (SMPP) protocol. Specifically, SMPP V3.4 is used over a TCP/IP connection to the SMSC's SMPP server. Operating in this capacity, the channel functions as a External Short Message Entity (ESME).
This paper requires that you read the abstract SMS specification, the SMPP specification from Logica, and the SMPP documentation for your SMSC's SMPP server.
In order to use the Messaging Server SMS channel, you must have the following:
The Messaging Server SMS channel is a multi-threaded channel which converts queued email messages to SMS messages and then submits them for delivery to an SMSC. Operation of the channel falls into three categories:
Each of these categories is discussed in the subsections which follow.
When the SMS channel is configured as per Section 4.0, one or more host names will be associated with the channel. For purposes of discussion, let us assume that the host name sms.siroe.com is a host name associated with the channel. In that case, email is directed to the channel with an address of the form
in which local-part is either the SMS destination address (for example, a wireless phone number, pager id, etc.) or an attribute-value pair list (AVPL) in the format
The recognized attribute names and their usages are given in the table below. These attributes allow for per-recipient control over some channel options.
Attribute Name | Attribute Value and Usage |
---|---|
ID | SMS destination address (for example, wireless phone number, pager id, etc.) to direct the SMS message to. This attribute and associated value must be present. |
MAXLEN | The maximum, total bytes (that is, eight bit bytes) to place into the generated SMS message or messages for this recipient. The lower value of either MAXLEN and the value specified by the MAX_MESSAGE_SIZE channel option is used. |
MAXPAGES | The maximum number of SMS messages to split the email message into for this recipient. The lower value of either MAXPAGES and the value specified by the MAX_PAGES_PER_MESSAGE channel option is used. |
NPI | Specify a Numeric Plan Indicator (NPI) value for the destination SMS address specified with the ID attribute. See the description of the DEFAULT_DESTIONATION NPI channel option for information on the accepted values for this attribute. When this attribute is used, its value overrides the value given by the DEFAULT_DESTINATION_NPI channel option. |
PAGELEN | Maximum number of bytes to place into a single SMS message for this recipient. The minimum of this value and that specified with the MAX_PAGE_SIZE channel option is used. |
TON | Specify a Type of Number (TON) value for the destination SMS address given with the ID attribute. See the description of the DEFAULT_DESTINATION_TON channel option for information on the accepted values for this attribute. When this attribute is used, its value overrides the value given by the DEFAULT_DESTINATION_TON channel option. |
And now for some example addresses:
123456@sms.siroe.com
/id=123456/@sms.siroe.com
/id=123456/maxlen=100/@sms.siroe.com
/id=123456/maxpages=1/@sms.siroe.com
An email message queued to the SMS channel is converted to one or more SMS messages. As described below, options allow control over the maximum number of SMS messages generated, the maximum total length of those SMS messages, and the maximum size of any single SMS message. Only text parts (that is, MIME text content types) from the email message are used and the maximum number of parts converted may also be controlled.
Character sets used in the email message's header lines and text parts are all converted to Unicode and then converted to an appropriate SMS character set.
When there is no SMS_TEXT mapping table, an email message queued to the SMS channel receives the following processing.
1. Resent-from: | 4. Sender: | |
2. From: | 5. Envelope From: | |
3. Resent-sender: |
Note that the Resent-from: and Resent-sender: header lines are only considered if the USE_HEADER_RESENT option has the value 1. Otherwise, Resent- header lines are ignored.
As an email message may have multiple recipients, Steps 8 and 9 may need to be done for each recipient address which makes use of the MAXLEN, MAXPAGES, or PAGELEN attributes described in Section 3.1 above.
For example, with the channel's default settings, the email message
From: John Doe <jdoe@siroe.com>
To: 1234567@sms.siroe.com
Subject: Today's meeting
Date: Fri, 26 March 2001 08:17
The staff meeting is at 14:30 today in the big conference room.
Would be converted to the SMS message
jdoe@siroe.com (Today's meeting) The staff meeting is at 14:30 today in the big conference room.
The option settings
CONTENT_PREFIX=Msg:
FROM_FORMAT=From:${pa}
SUBJECT_FORMAT=Subj:$s
would instead produce
From:John Doe Subj:Today's meeting Msg:The staff meeting is at 14:30 today in the big conference room.
Once an email message has been converted to one or more SMS messages, with possibly different sets for each recipient, the SMS messages are then submitted to the destination SMSC. The submissions are effected using SMPP V3.4 over TCP/IP. The hostname of the SMPP server is taken to be the official host name associated with the SMS channel; the TCP port to use is specified with the port channel keyword.
The channel binds to the SMPP server as a transmitter, presenting the credentials specified with the ESME_ channel options described in Section 4.3.3. In a bind_transmitter PDU (Protocol Data Unit), the following fields are set:
Fields in Generated bind_transmitter PDU | |
---|---|
Field | Value |
system_id | ESME_SYSTEM_ID channel option; default value is an empty string |
password | ESME_PASSWORD channel option; default value is an empty string |
system_type | ESME_SYSTEM_TYPE channel option; default value is an empty string |
interface_version | 0x34 indicating SMPP V3.4 |
addr_ton | ESME_ADDRESS_TON; default value is 0x00 indicating an unknown TON |
addr_npi | ESME_ADDRESS_NPI; default value is 0x00 indicating an unknown NPI |
addr_range | ESME_IP_ADDRESS channel option; default value is an empty string |
The SMS messages are then submitted using SMPP submit_sm PDUs. If a permanent error is returned (for example, ESME_RINVDSTADR), then the email message is returned as undeliverable. If a temporary error is returned, then the email message is re-enqueued for a later delivery attempt.
If the SET_SMS_SOURCE_ADDRESS option has the value 1, then the source address for the submitted SMS message is set. The value used is derived from the originating email message and is chosen to be the most likely (email) address to which any replies should be directed. Accordingly, the source address taken from one of the following seven sources, shown in decreasing order of preference:
1. Resent-reply-to: | 5. Resent-sender: | |
2. Resent-from: | 6. Sender: | |
3. Reply-to: | 7. Envelope From: | |
4. From: |
Note that the Resent-reply-to: and Reply-to: header lines are only considered if the USE_HEADER_REPLY_TO option has the value 1. Moreover, the Resent-reply-to:, Resent-from:, and Resent-sender: header lines are only considered if the USE_HEADER_RESENT option has the value 1. (Note that this means that both of those options must have the value 1 for the Resent-reply-to: header line to be considered.) The default value for both of these options is the value 0. As such, only items 4, 6, and 7 are considered by the default configuration. Finally, since the source address in an SMS message is limited to 20 bytes, the source address chosen will be truncated if it exceeds that limit.
In a submit_sm PDU, the following fields are set:
Mandatory Fields in Generated submit_sm PDUs | |
---|---|
Field | Value |
service_type | DEFAULT_SERVICE_TYPE channel option; default value is an empty string |
source_addr_ton | DEFAULT_SOURCE_TON channel option; if SET_SMS_SOURCE_ADDRESS=1, then this field is usually forced to the value 0x05 indicating an alphanumeric TON; otherwise, the default value is 0x01 indicating an international TON |
source_addr_npi | DEFAULT_SOURCE_NPI channel option; default value is 0x00 |
source_addr | DEFAULT_SOURCE_ADDRESS channel option if SET_SMS_SOURCE_ADDRESS=0; otherwise, an alphanumeric string representing the originator of the email message |
dest_addr_ton | TON addressing attribute or DEFAULT_DESTINATION_TON channel option; default value is 0x01 indicating an international TON |
dest_addr_npi | NPI addressing attribute or DEFAULT_DESTINATION_NPI channel option; default value is 0x00 indicating an unknown NPI |
dest_addr | Destination SMS address derived from the local part of the email envelope To: address; see Section 3.1 for further details |
esm_class | Set to 0x03 indicating store and forward mode, default SMSC message type, and do not set reply path |
protocol_id | 0x00; unused for CDMA and TDMA; for GSM, 0x00 indicates no internetworking, but SME-to-SME protocol |
priority_flag | 0x00 for GSM & CDMA and 0x01 for TDMA, all indicating normal priority; See the description of the DEFAULT_PRIORITY channel keyword |
schedule_delivery_time | Empty string indicating immediate delivery |
validity_period | DEFAULT_VALIDITY_PERIOD channel option; default value is an empty string indicating that the SMSC's default should be used |
registered_delivery | 0x00 indicating no registered delivery |
replace_if_present_flag | 0x00 indicating that any previous SMS messages should not be replaced |
data_coding | 0x00 for the SMSC's default character set; 0x08 for the UCS2 character set |
sm_default_msg_id | 0x00 indicating not to use a pre-defined message |
sm_length | Length and content of the SMS message; see Section 3.2 for further details |
short_message | |
Optional TLV Fields in Generated submit_sm PDUs | |
Field | Value |
privacy | See the description of the DEFAULT_PRIVACY channel keyword; default is to not provide this field unless the email message has a Sensitivity: header line |
sar_refnum | See the description of the USE_SAR channel keyword; default is to not provide these fields |
sar_total | |
sar_seqnum |
The channel remains bound to the SMPP server until either it has no more SMS messages to submit, or MAX_PAGES_PER_BIND has been exceeded. In the latter case, a new connection is made and bind operation performed if there remain further SMS messages to send.
Note that the SMS channel is multithreaded. Each processing thread in the channel maintains its own TCP connection with the SMPP server. For example, if there are three processing threads each with SMS messages to submit, then the channel will have three open TCP connections to the SMPP server. Each connection will bind to the SMPP server as a transmitter. Moreover, any given processing thread will only have one outstanding SMS submission at a time. That is, a given thread will submit an SMS message, then wait for the submission response (that is, submit_sm_resp PDU) before submitting another SMS message.
Sites may wish to apply validity checks or translations to SMS destination addresses encoded in the recipient email addresses described in Section 3.1. For example,
The first two tasks can be done specifically with the DESTINATION_ADDRESS_NUMERIC and DESTINATION_ADDRESS_PREFIX channel options. In general, all three of these tasks, and others can be implemented using mapping tables: either mapping table callouts in the rewrite rules or by means of a FORWARD mapping table. Using a mapping table callout in the rewrite rules will afford the most flexibility, including the ability to reject the address with a site-defined error response. The remainder of this section will focus on just such an approach -- using a mapping table callout from the rewrite rules.
Let us suppose that destination addresses need to be numeric only, be 10 or 11 digits long, and be prefixed with the string "+1". This can be accomplished with the following rewrite rule
sms.siroe.com ${X-REWRITE-SMS-ADDRESS,$U}@sms.siroe.com sms.siroe.com $?Invalid SMS address
The first rewrite rule above calls out to the site-define mapping table named X-REWRITE-SMS-ADDRESS. That mapping table is passed the local part of the email address for inspection. If the mapping process decides that the local part is acceptable, then the address is accepted and rewritten to the SMS channel. If the mapping process does not accept the local part, then the next rewrite rule is applied. Since it is a $? rewrite rule, the address is rejected with the error text "Invalid SMS address".
The X-REWRITE-SMS-ADDRESS mapping table is shown below. It performs the necessary validation steps for local parts in either attribute-value pair list format or just a raw SMS destination address.
X-VALIDATE-SMS-ADDRESS
! Iteratively strip any non-numeric characters $_*$[$ -/:-~]%* $0$2$R ! Accept the address if it is of the form 1nnnnnnnnnn or nnnnnnnnnn ! In accepting it, ensure that we output +1nnnnnnnnnn 1%%%%%%%%%% +1$0$1$2$3$4$5$6$7$8$9$Y %%%%%%%%%% +1$0$1$2$3$4$5$6$7$8$9$Y ! We didn't accept it and consequently it's invalid * $N
X-REWRITE-SMS-ADDRESS */id=$_*/* $C$0/id=$|X-VALIDATE-SMS-ADDRESS;$1|/$2$Y$E */id=$_*/* $N * $C$|X-VALIDATE-SMS-ADDRESS;$0|$Y$E * $N
With the above set up, be sure that DESTINATION_ADDRESS_NUMERIC option has the value 0 (the default). Otherwise, the "+" will be stripped from the SMS destination address.
Sites may customize Steps 1 - 6 of Section 3.2 with a table of conversion rules. These rules are specified via a mapping table in the MTA's mapping file.
The name of the mapping table should be x_TEXT where x is the name of the SMS channel; for example, SMS_TEXT if the channel is named sms or SMS_MWAY_TEXT if the channel is named sms_mway.
Two types of entries may be made in this mapping table. However, before explaining the format of those entries, let it be made clear that an understanding of how to use the mapping file is essential in order to understand how to construct and use these entries. An example mapping table is given after the description of these two types of entries.
Now, the two types of entries are:
H|pattern replacement-textIf a message header line matches the pattern
pattern
then it will be replaced with the replacement text replacement-text
using the mapping file's pattern matching and string substitution facilities.
The final result of mapping the header line will then be included in the SMS
message provided that the metacharacter $Y was specified in the replacement
text. If a header line does not match any pattern string, if it maps to a
string of length zero, or if the $Y metacharacter is not specified in the
replacement text, then the header line will be omitted from the SMS message.
The two entries
H|From:* F:$0$Y H|Subject:* S:$0$Ycause the From: and Subject: header lines to be included in SMS messages with From: and Subject: abbreviated as F: and S:. The entries:
H|Date:* H|D:$0$R$Y H|D:*,*%19%%*:*:* H|D:$0$ $5:$6$R$Ycause the Date: header line to be accepted and mapped such that, for instance, the header line
Date: Wed, 16 Dec 1992 16:13:27 -0700 (PDT)will be converted to
D: Wed 16:13Very complicated, iterative mappings may be built. Sites wishing to set up custom filters will first need to understand how the mapping file works. The H| in the right-hand-side of the entry may be omitted, if desired. The H| is allowed in that side so as to cut down on the number of table entries required by sets of iterative mappings.
B|pattern B|replacement-textIf a line of the message body matches a pattern
pattern
then it will be replaced with the replacement text replacement-text
.
Again, very complicated, iterative mappings may be constructed using this
facility. The B| in the right-hand-side
of the entry may be omitted, if desired.
SMS_TEXT H|From:* H|F:$0$R$Y (1) H|Subject:* H|S:$0$R$Y (1) H|F:*<*>* H|F:$1$R$Y (2) H|F:*(*)* H|F:$0$2$R$Y (3) H|F:*"*"* H|F:$0$2$R$Y (4) H|F:*@* H|F:$0$R$Y (5) H|%:$ * H|$0:$1$R$Y (6) H|%:*$ H|$0:$1$R$Y (6) H|%:*$ $ * H|$0:$1$ $2$R$Y (7) B|*--* B|$0-$1$R (8) B|*..* B|$0.$1$R (8) B|*!!* B|$0!$1$R (8) B|*??* B|$0?$1$R (8) B|*$ $ * B|$0$ $1$R (7) B|$ * B|$0$R (6) B|*$ B|$0$R (6)
In the example above, the metacharacter $R is used to implement and control iterative application of the mappings. By iterating on these mappings, powerful filtering is achieved. For instance, the simple mappings to remove a single leading or trailing space (6) or reduce two spaces to a single space (7) become, when taken as a whole, a filter which strips all leading and trailing spaces and reduces all consecutive multiple spaces to a single space. Such filtering helps reduce the size of each SMS message.
The order of the entries is very important. For instance, with the given ordering, the body of the message From: header line
From: "Daniel C. Newman" <dan@siroe.com> (Hello)will be reduced to
danThe steps taken to arrive at this are as follows:
From: "Daniel C. Newman" <dan@siroe.com> (Hello)The pattern in the first mapping entry matches this and produces the result
F: "Daniel C. Newman" <dan@siroe.com> (Hello)The $R metacharacter in the result string causes the result string to be remapped.
F: dan@siroe.comThe $R in the mapping causes the entire set of mappings to be re-applied to the result of this step.
F: danThe $R in the mapping causes the entire set of mappings to be re-applied to the result of this step.
F:danThe $R in the mapping causes the entire set of mappings to be re-applied to the result of this step.
F:danis incorporated into the SMS message.
Note that the imsimta test -mapping utility may be used to test a mapping table. For instance,
# imsimta test -mapping -noimage_file -mapping_file=test.txt Enter table name: SMS_TEXT Input string: H|From: "Daniel C. Newman" <dan@siroe.com> (Hello) Output string: H|F:dan Output flags: [0,1,2,89] Input string: ^D #
While there are no channel options which must be set in all situations, it is likely that one or more of the following options may need to be set: ESME_PASSWORD, ESME_SYSTEM_ID, MAX_PAGE_SIZE, DEFAULT_SOURCE_TON, and DEFAULT_DESTINATION_TON. And, as described, the SMPP server's hostname or IP address and TCP port must be set either through the channel definition in the imta.cnf file or the channel option file.
You may configure more than one SMS channel, giving different characteristics to different SMS channels. See Section 4.4 for further information on the use of multiple SMS channels.
Before adding an SMS channel to the MTA's configuration, you need to pick a name for the channel. The name of the channel may be either sms or sms_x where x is any case-insenstive string whose length is between one and thirty-six bytes. For example, sms_mway.
To add the channel definition, edit the imta.cnf file located in the server-root/msg-instance/imta/config/ directory. At the bottom of the file add a blank line followed by the two lines
channel-name master port p threaddepth t \
backoff pt2m pt5m pt10m pt30m notices 1
smpp-host-name
where channel-name is the name you chose for the channel, p is the TCP port the SMPP server listens on, t is the maximum simultaneous number of SMPP server connections per delivery process, and smpp-host-name is the host name of the system running the SMPP server. For example,
sms_mway master port 55555 threaddepth 20 \
backoff pt2m pt5m pt10m pt30m notices 1
smpp.siroe.com
Presently the use of the master channel keyword is criticial: without it the channel will default to being bidirectional and will generate replyable SMS messages. See Section 4.5 for a discussion of the backoff and notices channel keywords.
If you wish to specify an IP address rather than a host name, then for smpp-host-name, specify a domain literal. For example, if the IP address is 127.0.0.1, then specify [127.0.0.1] for smpp-host-name. Alternatively, consider using the SMPP_SERVER channel option.
The threaddepth channel keyword controls the number of messages to assign to each delivery thread within a delivery process. The SMPP_MAX_CONNECTIONS option controls the maximum number of delivery threads in a delivery process. And, finally, the job_limit option for the Job Controller processing pool in which the channel is run controls the maximum number of simultaneous delivery processes.
Once the channel definition has been added, go to the top half of the file and add a rewrite rule,
smpp-host-name $u@smpp-host-name
For example,
smpp.siroe.com $u@smpp.siroe.com
Then save the imta.cnf file, recompile the configuration with the imsimta cnbuild command, and then restart the SMTP server with the imsimta restart dispatcher command.
With the above configuration, email message are directed to the channel by addressing them to id@smpp-host-name (for example, 123456@smpp.siroe.com). See Section 3.2 for further information on addressing.
If you wish to hide the SMPP server's host name from users or associate other host names with the same channel, then add additional rewrite rules. For instance, to associate host-name-1 and host-name-2 with the channel, add the following to rewrite rules
host-name-1 $U%host-name-1@smpp-host-name
host-name-2 $U%host-name-2@smpp-host-name
For example, if the SMPP server's host name is smpp.siroe.com but you want users to address email to id@sms.sun.com, then add the rewrite rule
sms.sun.com $U%sms.sun.com@smpp.siroe.com
Note that the SMPP_SERVER and SMPP_PORT channel options will override the channel's official host name and port channel keyword settings. When the SMPP_PORT option is used, it is not necessary to also use the port keyword. The advantage of using these two options is that they can be put into effect and subsequently changed without needing to recompile the configuration. An additional use of the SMPP_SERVER option is described in Section 4.4.
The channel options described in the subsequent section are stored in a text file in the
Each option is placed on a single line in the file using the format
PROFILE=GSM
SMSC_DEFAULT_CHARSET=iso-8859-1
USE_UCS2=1
A sample option file named sms_option.sample is distributed with iMS. Copy this option file and use it as a starting point.
The SMS channel contains a number of options which divide into four broad
categories:
These options are summarized in the table below, and described more fully in the sections which follow.
Email to SMS Conversion | ||
---|---|---|
Option | Default | Description |
MAX_MESSAGE_PARTS | 2 | Maximum number of message parts to extract from an email message |
MAX_MESSAGE_SIZE | 960 | Maximum number of bytes to extract from an email message |
MAX_PAGE_SIZE | 160 | Maximum number of bytes to put into a single SMS message |
MAX_PAGES_PER_MESSAGE | 6 | Maximum number of SMS messages to break an email message into |
SMSC_DEFAULT_CHARSET | US-ASCII | The default character set used by the SMSC. |
USE_HEADER_PRIORITY | 1 | Control the use of priority information from the email message's header |
USE_HEADER_REPLY_TO | 0 | Control the use of Reply-to: header lines when generating SMS source addresses. |
USE_HEADER_RESENT | 0 | Control the use of Resent-*: header lines when generating originator information. |
USE_HEADER_SENSITIVITY | 1 | Control the use of privacy information from the email message's header |
USE_UCS2 | 1 | Use the UCS2 character set in SMS messages when applicable |
SMS Fields | ||
Option | Default | Description |
DEFAULT_DESTINATION_NPI | 0x00 | Default NPI for SMS destination addresses |
DEFAULT_DESTINATION_TON | 0x01 | Default TON for SMS destination addresses |
DEFAULT_PRIORITY | 0 (GSM, CDMA), 1 (TDMA) |
Default priority setting for SMS messages |
DEFAULT_PRIVACY | -1 | Default privacy value flag for SMS messages |
DEFAULT SERVICE_TYPE | SMS application service associated with submitted SMS messages | |
DEFAULT_SOURCE_ADDRESS | Default SMS source address | |
DEFAULT_SOURCE_NPI | 0x00 | Default NPI for SMS source addresses |
DEFAULT_SOURCE_TON | 0x01 | Default TON for SMS source addresses |
DEFAULT_VALIDITY_PERIOD | Default validity period for SMS messages | |
DESTINATION_ADDRESS_NUMERIC | 0 | Reduce the destination SMS address to only the characters 0 - 9 |
DESTINATION_ADDRESS_PREFIX | Text string to prefix destination SMS addresses with | |
PROFILE | GSM | SMS profile to use |
SET_SMS_SOURCE_ADDRESS | 1 | Set the SMS source address to the originator address of the email message |
USE_SAR | 0 | Sequence multiple SMS messages using the SMS sar_ fields |
SMPP Protocol | ||
Option | Default | Description |
ESME_ADDRESS_NPI | 0x00 | ESME NPI to specify when binding to the SMPP server |
ESME_ADDRESS_TON | 0x00 | ESME TON to specify when binding to the SMPP server |
ESME_IP_ADDRESS | IP address of the host running iMS | |
ESME_PASSWORD | Password to present when binding to the SMPP server | |
ESME_SYSTEM_ID | System identification to present to the SMSC when binding | |
ESME_SYSTEM_TYPE | System type to present to the SMSC when binding | |
MAX_PAGES_PER_BIND | 1024 | Maximum number of SMS messages to submit during a single session with an SMPP server |
REVERSE_ORDER | 0 | Transmission sequence of multi-part SMS messages |
SMPP_MAX_CONNECTIONS | 20 | Maximum number of simultaneous SMPP server connections |
SMPP_PORT | TCP port the SMPP server listens on | |
SMPP_SERVER | Host name of the SMPP server to connect to | |
TIMEOUT | 30 | Timeout for completion of reads and writes with the SMPP server |
Localization | ||
Option | Default | Description |
CONTENT_PREFIX | Text to introduce the content of the email message | |
FROM_FORMAT | $a | Text to display indicating the originator of the email message |
FROM_NONE | Text to display when there is no originator | |
LANGUAGE | i-default | Language group to select text fields from |
LINE_STOP | space character | Text to place at the end of each line extracted from the email message |
NO_MESSAGE | [no message] | Text to indicate that the email message had no content |
REPLY_PREFIX | Re: | Reserved for future use |
SUBJECT_FORMAT | ($s) | Text to display indicating the subject of the email message |
SUBJECT_NONE | Text to display when there is no subject for the email message | |
Miscellaneous | ||
Option | Default | Description |
DEBUG | 0 | Enable verbose debug output |
The following options control the conversion of email messages to SMS messages. In general, a given email message may be converted into one or more SMS messages. See Section 3.2 for a description of this conversion process.
MAX_MESSAGE_PARTS (integer)
When converting a multi-part email message to an SMS message, only the first
MAX_MESSAGE_PARTS text parts will be converted. The remaining parts are discarded.
By default, MAX_MESSAGE_PARTS is 2. To allow an unlimited number of message
parts, specify a value of -1. When a value of 0 is specified, then no message
content will be placed into the SMS message. This has the effect of using only
header lines from the email message (for example, Subject:) to generated the SMS message.
Note that an email message containing both text and an attachment will typically consist of two parts. Note further that only message parts of type text are converted. All other MIME content types are discarded.
MAX_MESSAGE_SIZE (integer, >= 10)
With this option, an upper limit may be placed on the total number of bytes
placed into the SMS messages generated from an email message. Specifically,
a maximum of MAX_MESSAGE_SIZE bytes will be used for the one or more generated SMS
messages. Any additional bytes are discarded.
By default, an upper limit of 960 bytes is imposed. This corresponds to MAX_MESSAGE_SIZE=960. To allow any number of bytes, specify a value of zero.
The count of bytes used is made after converting the email message from Unicode to either the SMSC's default character set or UCS2. This means, in the case of UCS2, that a MAX_MESSAGE_SIZE of 960 bytes will yield, at most, 480 characters since each UCS2 character is at least two bytes long.
Note that the MAX_MESSAGE_SIZE and MAX_PAGES_PER_MESSAGE options both serve the same purpose: to limit the overall size of the resulting SMS messages. Indeed, MAX_MESSAGE_SIZE=960 and MAX_PAGE_SIZE=160 implies MAX_PAGES_PER_MESSAGE=6. So why are there two different options? So as to allow control of the overall size or number of pages without having to consider the maximal size of a single SMS message, MAX_PAGE_SIZE. While this may not be important in the channel option file, it is important when using the MAXPAGES or MAXLEN addressing attributes described in Section 3.2.
Finally, note that the smaller of the two limits
MAX_PAGE_SIZE (integer, >= 10)
The maximum number of bytes to allow in a single SMS message is controlled with
the MAX_PAGE_SIZE option. By default, a value of 160 bytes is used. This corresponds
to MAX_PAGE_SIZE=160.
MAX_PAGES_PER_MESSAGE (integer,
1 - 255)
The maximum number of SMS messages to generate for a given email message is
controlled with this option. In effect, this option truncates the email message,
only converting to SMS messages that part of the email message which fits into
MAX_PAGES_PER_MESSAGE SMS messages. See the description of the MAX_MESSAGE_SIZE
option for further discussion.
By default, MAX_PAGES_PER_MESSAGE is set to the larger of 1 or MAX_MESSAGE_SIZE divided by MAX_PAGE_SIZE.
SMSC_DEFAULT_CHARSET (string)
With this option, the SMSC's default character set may be specified. Use the
character set names given in the file
When processing an email message, the header lines and text message parts
are first decoded and then converted to Unicode. Next, the data is then converted
to either the SMSC's default character set or UCS2 as described in the table
below. Note that the UCS2 character set is a 16-bit encoding of Unicode and
is often referred to as UTF-16.
USE_UCS2 | Result |
---|---|
1 | The SMSC default character set will be used whenever possible. When the originating email message contains glyphs not in the SMSC default character set, then the UCS2 character set will be used. |
0 | The SMSC default character set will always be used. Glyphs not available in that character set will be represented by memnomics (for example, "AE" for AE-ligature). |
USE_HEADER_PRIORITY (0 or 1)
This option controls handling of RFC822 Priority: header lines. By default,
information from the Priority: header line is used to set the resulting SMS
message's priority flag, overriding the default SMS priority specified with
the DEFAULT_PRIORITY option. This case
corresponds to USE_HEADER_PRIORITY=1. To disable use of the RFC822 Priority:
header line, specify USE_HEADER_PRIORITY=0.
See the description of the DEFAULT_PRIORITY option for further information on the handling the the SMS priority flag.
USE_HEADER_REPLY_TO (0 or 1)
When SET_SMS_SOURCE_ADDRESS=1, this option controls whether or not a Reply-to:
or Resent-reply-to: header line is considered for use as the SMS source address.
By default, Reply-to: and Resent-reply-to: header lines are ignored. This corresponds
to an option value of 0. To enable consideration of these header lines, use
an option value of 1.
Note that RFC 2822 has deprecated the use of Reply-to: and Resent-reply-to: header lines. This is the reason why, by default, USE_HEADER_REPLY_TO=0.
USE_HEADER_RESENT (0 or 1)
When SET_SMS_SOURCE_ADDRESS=1, this option controls whether or not Resent- header
lines are considered for use as the SMS source address. By default, Resent-
header lines are ignored. This corresponds to an option value of 0. To enable
consideration of these header lines, use an option value of 1.
Note that RFC 2822 has deprecated the use of Resent- header lines; hence, why this option has the default value of 0.
USE_HEADER_SENSITIVITY (0
or 1)
The USE_HEADER_SENSITIVITY option controls handling of RFC822 Sensitivity: header
lines. By default, information from the Sensitivity: header line is used to
set the resulting SMS message's privacy flag, overriding the default SMS privacy
specified with the DEFAULT_PRIVACY option.
This case, which is the default, corresponds to USE_HEADER_SENSITIVITY=1. To
disable use of RFC822 Sensitivity: header lines, specify USE_HEADER_SENSITIVITY=0.
See the description of the DEFAULT_PRIVACY option for further information on the handling the the SMS privacy flag.
USE_UCS2 (0 or 1)
When appropriate, the channel will use the UCS2 character set in the SMS messages
it generates. This is the default behavior and corresponds to USE_UCS2=1. To
disable the use of the UCS2 character set, specify USE_UCS2=0. See the description
of the SMSC_DEFAULT_CHARSET option
for further information on character set issues.
The following options allow for specification of SMS fields in generated SMS messages.
DEFAULT_DESTINATION_NPI
(integer, 0 - 255)
By default, destination addresses will be assigned an NPI (Numeric Plan Indicator)
value of zero. With this option, an alternate integer value in the range 0 to
255 may be assigned. Typical NPI values include
Value | Description |
---|---|
0 | Unknown |
1 | ISDN (E.163, E.164) |
3 | Data (X.121) |
4 | Telex (F.69) |
6 | Land Mobile (E.212) |
8 | National |
9 | Private |
10 | ERMES |
14 | IP address (Internet) |
18 | WAP client id |
>= 19 | Undefined |
Values for this option may be specified in one of three ways:
DEFAULT_DESTINATION_TON
(integer, 0 - 255)
By default, destination addresses will be assigned a TON (Type of Number) designator
value of zero. With this option, an alternate integer value in the range 0 to
255 may be assigned. Typical TON values include
Value | Description |
---|---|
0 | Unknown |
1 | International |
2 | National |
3 | Network specific |
4 | Subscriber number |
5 | Alphanumeric |
6 | Abbreviated |
>= 7 | Undefined |
Values for this option may be specified in one of three ways:
DEFAULT_PRIORITY (integer, 0
- 255)
SMS messages have a mandatory priority field. The interpretation of SMS priority
values is
Value | GSM | TDMA | CDMA |
---|---|---|---|
0 | Non-priority | Bulk | Normal |
1 | Priority | Normal | Interactive |
2 | Priority | Urgent | Urgent |
3 | Priority | Very urgent | Emergency |
Note that if USE_HEADER_PRIORITY=1
and an email message has an RFC822 Priority: header line, then the priority
specified in that header line will instead be used to set the priority of the
resulting SMS message. Specifically,
USE_HEADER_PRIORITY | Result |
---|---|
0 | The SMS priority flag is always set in accord with the DEFAULT_PRIORITY option. The RFC822 Priority: header line is always ignored. |
1 (default) | The originating email message's RFC822 Priority: header line is used to set the SMS message's priority flag. If that header line is not present, then the SMS priority flag is set using the DEFAULT_PRIORITY option. |
In translating RFC822 Priority: header line values to SMS priority flags,
the following mapping is used:
RFC822 | SMS priority flag | ||
---|---|---|---|
Priority: value | GSM | TDMA | CDMA |
Third | Non-priority (0) | Bulk (0) | Normal (0) |
Second | Non-priority (0) | Bulk (0) | Normal (0) |
Non-urgent | Non-priority (0) | Bulk (0) | Normal (0) |
Normal | Non-priority (0) | Normal (1) | Normal (0) |
Urgent | Priority (1) | Urgent (2) | Urgent (2) |
DEFAULT_PRIVACY (integer, -1,
0 - 255)
Whether or not to set the privacy flag in an SMS message, and what value to
use is controlled with the DEFAULT_PRIVACY and USE_HEADER_SENSITIVITY
options. By default, a value of -1 is used for DEFAULT_PRIVACY.
DEFAULT_PRIVACY | USE_HEADER_SENSITIVITY | Result |
---|---|---|
-1 | 0 | The SMS privacy flag is never set in SMS messages. |
n >= 0 | 0 | The SMS privacy flag is always set to the value n. RFC822 Sensitivity: header lines are always ignored. |
-1 (default) | 1 (default) | The SMS message's privacy flag is only set when the originating email message has an RFC822 Sensitivity: header line. In that case, the SMS privacy flag is set to correspond to the Sensitivity: header line's value. This is the default. |
n >= 0 | 1 | The SMS message's privacy flag is set to correspond to the originating email message's RFC822 Sensitivity: header line. If the email message does not have a Sensitivity: header line, then the value of the SMS privacy flag is set to n. |
The SMS interpretation of privacy values is as follows:
Value | Description |
---|---|
0 | Unrestricted |
1 | Restricted |
2 | Confidential |
3 | Secret |
>= 4 | Undefined |
RFC822 Sensitivity: value | SMS privacy value |
---|---|
Personal | 1 (Restricted) |
Private | 2 (Confidential) |
Company confidential | 3 (Secret) |
DEFAULT_SERVICE_TYPE (string,
0 - 5 bytes)
Service type to associate with SMS messages generated by the channel. By default,
no service type is specified (that is, a zero length string). Some common service
types are: CMT (cellular messaging), CPT (cellular paging), VMN (voice mail
notification), VMA (voice mail alerting), WAP (wireless application protocol),
and USSD (unstructured supplementary data services).
DEFAULT_SOURCE_ADDRESS (string,
0 - 20 bytes)
Source address to use for SMS messages generated from email messages. Note
that the value specified with this option is typically overridden by the email
message's originator address when SET_SMS_SOURCE_ADDRESS=1.
DEFAULT_SOURCE_NPI (integer,
0 - 255)
By default, source addresses will be assigned an NPI value of zero. With this
option, an alternate integer value in the range 0 to 255 may be assigned. See
the description of the DEFAULT_DESTINATION_NPI
option for a table of typical NPI values.
DEFAULT_SOURCE_TON (integer,
0 - 255)
By default, source addresses will be assigned a TON designator value of zero.
With this option, an alternate integer value in the range 0 to 255 may be assigned.
See the description of the DEFAULT_DESTINATION_TON
option for a table of typical TON values.
DEFAULT_VALIDITY_PERIOD
(string, 0 - 252 bytes)
By default, SMS messages will be given no relative validity period, using the
SMSC's default value. Use this option to specify a different relative validity
period. Values may be specified in units of seconds, minutes, hours, or days:
Format | Description |
---|---|
nnn | Implicit units of seconds; for example, 604800 |
nnns | Units of seconds; for example, 604800s |
nnnm | Units of minutes; for example, 10080m |
nnnh | Units of hours; for example, 168h |
nnnd | Units of days; for example, 7d |
A specification of 0, 0s, 0m, 0h, or 0d may be used to select the SMSC's default validity period. That is, when a specification of 0, 0s, 0m, 0h, or 0d is used, an empty string is specified for the validity period in generated SMS messages.
Note that this option does not accept values in UTC format.
DESTINATION_ADDRESS_NUMERIC
(0 or 1)
Use this option to strip all non-numeric characters from the SMS destination
address extracted from the email envelope To: address. For instance, if the
envelope To: address is
"(800) 555-1212"@sms.siroe.comthen it will be reduced to
8005551212@sms.siroe.comTo enable this stripping, specify a value of 1 for this option. By default, this stripping is disabled which corresponds to an option value of 0. Note that when enabled, the stripping is done before any destination address prefix is added via the DESTINATION_ADDRESS_PREFIX option.
DESTINATION_ADDRESS_PREFIX
(string)
In some instances, it may be necessary to ensure that all SMS destination addresses
are prefixed with a fixed text string; for example, "+". This option may be used to
specify just such a prefix. The prefix will then be added to any SMS destination
address which lacks the specified prefix. To prevent being stripped by the DESTINATION_ADDRESS_NUMERIC
option, this option is applied after the DESTINATION_ADDRESS_NUMERIC option.
PROFILE (string)
Specify the SMS profiling to be used with the SMSC. Possible values are GSM,
TDMA, and CDMA. When not specified, GSM is assumed. This option is only used
to select defaults for other channel options such as DEFAULT_PRIORITY
and DEFAULT_PRIVACY.
SET_SMS_SOURCE_ADDRESS
(0 or 1)
Use of this option forces the SMS source address TON to be set to alphanumeric
(0x05), and the SMS source address to be an originator address extracted from
the email message. As email messages may have a number of originator addresses,
the particular address chosen is the one most likely to be the address to which
any replies should be directed. Consequently, the choice is made from one of
the seven following header lines, listed in order of decreasing preference:
Email message field |
Restrictions
|
TON
|
---|---|---|
1. Resent-reply-to: | Requires USE_HEADER_RESENT=1 and USE_HEADER_REPLY_TO=1 |
0x05
|
2. Resent-from: | Requires USE_HEADER_RESENT=1 | |
3. Reply-to: | Requires USE_HEADER_REPLY_TO=1 | |
4. From: | ||
5. Resent-sender: | Requires USE_HEADER_RESENT=1 | |
6. Sender: | ||
7. Envelope From: | ||
8. DEFAULT_SOURCE_ADDRESS | Used as a last resort (that is, when the envelope From: address is empty) | As per DEFAULT_SOURCE_TON |
The selected address is reduced to just its local and domain parts; that is, any source route, phrase, or comments are stripped from the address. Furthermore, if the length of the reduced address exceeds 20 bytes, it will be truncated to 20 bytes.
When none of the seven listed header lines are suitable, the default source SMS address is instead used as specified with the DEFAULT_SOURCE_ADDRESS option. In that case, the TON is set as per the DEFAULT_SOURCE_TON.
To enable this option, specify SET_SMS_SOURCE_ADDRESS=1. By default, this option is enabled.
USE_SAR (0 or 1)
Sufficiently large email messages may need to be broken into multiple SMS messages.
When this occurs, the individual SMS messages can optionally have sequencing
information added using the SMS sar_ fields. This produces a "segmented" SMS
message which can be re-assembled into a single SMS message by the receiving
terminal. Specify USE_SAR=1 to indicate that this sequencing information is
to be added when applicable. The default is to not add sequencing information
and corresponds to USE_SAR=0.
When USE_SAR=1 is specified, the REVERSE_ORDER option is ignored.
The following options allow for specification of SMPP protocol parameters. The options with names beginning with the string "ESME_" serve to identify the MTA when it acts as an External Short Message Entity (ESME); that is, when the MTA binds to an SMPP server in order to submit SMS messages to the server's associated SMSC.
ESME_ADDRESS_NPI (integer, 0 -
255)
By default, bind operations will specify an ESME NPI value of zero indicating
an unknown NPI. With this option, an alternate integer value in the range 0
to 255 may be assigned. See the description of the DEFAULT_DESTINATION_NPI
option for a table of typical NPI values.
ESME_ADDRESS_TON (integer, 0 -
255)
By default, bind operations will specify an ESME TON value of 0. With this option,
an alternate integer value in the range 0 to 255 may be assigned. See the description
of the DEFAULT_DESTINATION_TON
option for a table of typical TON values.
ESME_IP_ADDRESS (string, 0 - 15
bytes)
When binding to the SMPP server, the bind PDU indicates that the client's (that is,
ESME's) address range is an IP address. This is done by specifying a TON of
0x00 and an NPI of 0x0d. The value of the address range field is then set to
be the IP address of the host running the SMS channel. Specify the IP address
in dotted decimal format; for example, 127.0.0.1.
ESME_PASSWORD (string, 0 - 8 bytes)
When binding to the SMPP server, a password may be required. If so, then specify
that password with this option. By default, a zero-length password string is
presented.
ESME_SYSTEM_ID (string, 0 - 15
bytes)
When binding to the SMPP server, a system id for the MTA may be supplied. By
default, no system id is specified (that is, a zero-length string is used). To
specify a system id, use this option.
ESME_SYSTEM_TYPE (string, 0 -
12 bytes)
When binding to the SMPP server, a system type for the MTA may be supplied.
By default, no system type is specified (that is, a zero-length string is used).
MAX_PAGES_PER_BIND (integer,
>= 0)
Some SMPP servers may limit the maximum number of SMS messages submitted during
a single, bound session. In recognition of this, this option allows specification
of the maximum number of SMS messages to submit during a single session. Once
that limit is reached, the channel will unbind, close the TCP/IP connection,
re-connect, and then rebind.
By default, a value of 1024 is used for MAX_PAGES_PER_BIND. Note that the channel will also detect ESME_RTHROTTLED errors and adjust MAX_PAGES_PER_BIND during a single run of the channel accordingly.
REVERSE_ORDER (0 or 1)
When an email message generates more than one SMS message, those SMS messages
can be submitted to the SMSC in sequential order (REVERSE_ORDER=0), or reverse
sequential order (REVERSE_ORDER=1). Reverse sequential order is useful for situations
where the receiving terminal displays the last received message first. In such
a case, the last received message will be the first part of the email message
rather than the last. By default, REVERSE_ORDER=1 is used.
Note that this option is ignored when USE_SAR=1 is specified.
SMPP_MAX_CONNECTIONS (integer,
1 - 50)
This option controls the maximum number of simultaneous SMPP connections per
process. As each connection has an associated thread, this option also places
a limit on the maximum number of "worker" threads per process. By
default, SMPP_MAX_CONNECTIONS=20.
SMPP_PORT (integer, 1 - 65535)
The TCP port which the SMPP server listens on may be specified with either this
option or the port channel keyword.
This port number must be specified through either of these two mechanisms. If
it is specified with both mechanisms, then the setting made with the SMPP_PORT
option takes precedence. Note that there is no default value for this option.
SMPP_SERVER (string, 1 - 252 bytes)
By default, the IP host name of the SMPP server to connect to is the official
host name associated with the channel; that is, the host name shown on the second
line of the channel's definition in MTA's configuration. This option may be
used to specify a different host name or IP address which will override that
specified in the channel definition. When specifying an IP address, use dotted
decimal notation; for example, 127.0.0.1.
TIMEOUT (integer, >= 2)
By default, a timeout of 30 seconds is used when waiting for writes of data
to the SMPP server to complete or for data to be recieved from the SMPP server.
Use the TIMEOUT option to specify, in units of seconds, a different timeout
value. The specified value should be at least 2 seconds.
In constructing SMS messages, the SMS channel has a number of fixed text strings it puts into those messages. These strings, for example, introduct the email's From: address and Subject: header line. With the channel options described below, versions of these strings may be specified for different languages and a default language for the channel then specified. This section of the option file appears as follows,
LANGUAGE=default-language
[language=i-default]
FROM_PREFIX=From:
SUBJECT_PREFIX=Subj:
CONTENT_PREFIX=Msg:
LINE_STOP=
NO_MESSAGE=[no message]
REPLY_PREFIX=Re:
[language=en]
FROM_PREFIX=From:
SUBJECT_PREFIX=Subj:
CONTENT_PREFIX=Msg:
LINE_STOP=
NO_MESSAGE=[no message]
REPLY_PREFIX=Re:
...
Within each [language=x]block, the localization options relevant to that language may be specified. If a particular option is not specified within the block, then the global value for that option is used. A localization option specified outside of a [language=x] block sets the global value for that option.
For the options listed below, the string values must be specified using either the US-ASCII or UTF-8 character sets. Note that the US-ASCII character set is a special case of the UTF-8 character set.
CONTENT_PREFIX (string, 0 - 252
bytes)
Text string to place in the SMS message before the content of the email message
itself. Default global value is the US-ASCII string "Msg:".
FROM_FORMAT (string, 0 - 252 bytes)
Formatting template to format the originator information to insert into the
SMS message. The default global value is the US-ASCII string "$a"
which substitutes in the originator's email address. See Section
4.3.5 for futher details.
FROM_NONE (string, 0 - 252 bytes)
Text string to place in the SMS message when there is no originator address
to display. The default global value is an empty string.
Note that normally, this option will never be used as sites will typically reject email messages which lack any originator address.
LANGUAGE (string, 0 - 40 bytes)
The default language group to select text strings from. If not specified, then
the language will be derived from the host's default locale specification. If
the host's locale specification is not available or corresponds to "C",
then i-default will be used. (i-default corresponds to "English text intended
for an international audience.)
LINE_STOP (string, 0 - 252 bytes)
Text string to place in the SMS message between lines extracted from the email
message. The default global value is the US-ASCII space character, " ".
NO_MESSAGE (string, 0 - 252 bytes)
Text string to place in the SMS message to indicate that the email message
had no content. The default global value is the US-ASCII string "[no
message]".
REPLY_PREFIX (string, 0 - 252 bytes)
Reserved for future use. The default global value is the US-ASCII string "Re:
".
SUBJECT_FORMAT (string, 0 - 252
bytes)
Formatting template to format the content of the Subject: header line for display
in the SMS message. The global default value for this option is the US-ASCII
string "($s)". See
Section 4.3.5 for futher details.
See the SUBJECT_NONE option for a description of the handling when there is no Subject: header line or the content of that header line is an empty string.
SUBJECT_NONE (string, 0 - 252 bytes)
Text string to display when the originating email message either has no Subject:
header line, or the Subject: header line's value is an empty string. The default
global value for this option is the empty string.
The formatting templates specified with the FROM_FORMAT and SUBJECT_FORMAT channel options are UTF-8 strings which may contain a combination of literal text and substitution sequences. Assuming the sample email address of
Jane Doe <user@siroe>
The recognized substitution sequences are
Sequence | Description |
---|---|
$a
|
Replace with the local and domain part of the originator's email address (for example, "user@siroe") |
$d
|
Replace with the domain part of the originator's email address (for example, "domain") |
$p
|
Replace with the phrase part, if any, of the originator's email address (for example, "Jane Doe") |
$s
|
Replace with the content of the Subject: header line |
$u
|
Replace with the local part of the originator's email address (for example, "user") |
\x
|
Replace with the literal character "x" |
For example, the formatting template
From: $a
produces the text string
From: user@siroe
The construct,
${xy:alternate text}
may be used to substitute in the text associated with the sequence x. If that text is the empty string, the text associated with the sequence y is instead used. And, if that text is the empty string, to then substitute in the alternate text. For example, consider the formatting template
From: ${pa:unknown sender}
For the originator email address
John Doe <jdoe@siroe.com>
which has a phrase part, the template produces
From: John Doe
However, for the address
jdoe@siroe.com
which lacks a phrase, it produces
From: jdoe@siroe.com
And for an empty originator address, it produces
From: unknown sender
You may configure the MTA to have more than one SMS channel. There are two typical reasons to do this
Handling Case 1 is quite straightforward: just add an additional SMS channel to the configuration, being sure to (a) give it a different channel name, and (b) associated different host names with it. For example,
sms_mway master port 55555 threaddepth 20
smpp.siroe.comsms_ace master port 777 threaddepth 20
sms.ace.net
Case 2, in which the same SMPP server is to be used requires use of the SMPP_SERVER channel option. This need arises from the fact that two different channels cannot have the same official host name (that is, the host name listed in the second line of the channel definition). For example, if you need two different channels which communicate with the same SMPP server, then you could use the following channel definitions,
sms_mway_1 master port 55555 threaddepth 20
SMS-DAEMON-1
sms_mway_2 master port 55555 threaddepth 20
SMS-DAEMON-2
and rewrite rules,
sms-1.siroe.com $u%sms-1.siroe.com@SMS-DAEMON-1
sms-2.siroe.com $U%sms-2.siroe.com@SMS-DAEMON-2
Then, each of these two channel would specify SMPP_SERVER=smpp.siroe.com in their channel option files.
When an SMS message cannot be delivered owing to temporary errors (for example, the SMPP server is not reachable), the email message is left in the delivery queue and retried again later. Unless configured otherwise, the Job Controller will not re-attempt delivery for an hour. For SMS messaging, that is likely too long to wait. As such, it is recommended that the backoff channel keyword be used with the SMS channel to specify a more aggressive schedule for delivery attempts. For example,
sms_mway master port 55555 threaddepth 20 \
backoff pt2m pt5m pt10m pt30m notices 1
smpp.siroe.com
With the above settings, a redelivery attempt will be made at two minutes after the first attempt. If that then fails, then five minutes after the second attempt. Then ten minutes later and finally every thirty minutes. The notices 1 channel keyword causes the message to be returned as undeliverable if it cannot be delivered after a day.
The Messaging Server SMS channel may be used with any SMPP V3.4 compatible SMPP server. For purposes of illustrating an example configuration, this section explains how to configure the SMS channel for use with a MobileWay SMPP server. MobileWay (http://www.mobileway.com/) is a leading provider of global data and SMS connectivity. By routing your SMS traffic through Mobileway, you can reach SMS subscribers on most of the major SMS networks throughout the world.
When requesting an SMPP account with MobileWay, you may be asked to answer the following questions:
After supplying MobileWay with the answers to the above questions, they will provide you with an SMPP account and information necessary to communicate with their SMPP servers. This information includes
The Account Address field is the IP address, a.b.c.d, and TCP port number, p, of the MobileWay SMPP server you will be connecting to. Use these values for the SMPP_SERVER and SMPP_PORT channel options. The Account Login and Passwd are, respectively, the values to use for the ESME_SYSTEM_ID and ESME_PASSWORD channel options. Using this information, your channel's option file should includeAccount Address: a.b.c.d:p
Account Login: system-id
Account Passwd: secret
SMPP_SERVER=a.b.c.d
SMPP_PORT=p
ESME_SYSTEM_ID=system-id
ESME_PASSWORD=secret
Now, to interoperate with MobileWay you need to make two additional option settings
ESME_ADDRESS_TON=0x01
DEFAULT_DESTINATION_TON=0x01
The rewrite rule in the imta.cnf file can appear as
sms.your-domain $u@sms.your-domain
And, the channel definition in the imta.cnf file can appear as
sms_mobileway master
sms.your-domain
Once the channel option file, rewrite rule, and channel definition are in place, a test message may be sent. MobileWay requires International addressing of the form
+<country-code><subscriber-number>
For instance, to send a test message to the North American subscriber with the subscriber number (800) 555-1212, you would address your email message to
+18005551212@sms.your-domain
To debug the channel, specify the master_debug channel keyword in the channel's definition. For example,
sms_mway master port 55555 threaddepth 20 \
backoff pt2m pt5m pt10m pt30m notices 1 master_debug
With the master_debug channel keyword, basic diagnostic information about the channel's operation will be output to the channel's log file. For verbose diagnostic information about the SMPP transactions undertaken by the channel, also specify
DEBUG=-1
in the channel's option file.