Sun Java System Messaging Server 6 2005Q4 Administration Guide

SMS Gateway Server Configuration

This section gives directions on how to set up the SMS Gateway Server for both email-to-mobile and mobile-to-email functionality. This section includes the following topics:

Setting Up Bidirectional SMS Routing

The recommended way to set up bidirectional email and SMS routing between the MTA and SMSC is a three step process:

Set the SMS Address Prefix

The source SMS addresses generated by the MTA SMS channel should be set to match the selected SMS address prefix. Do this by setting the following:

Set the Gateway Profile

The SMS Gateway Server’s gateway profile should then be set to make all relayed SMS source addresses unique. This is the default setting but may be explicitly set by specifying the gateway profile option MAKE_SOURCE_ADDRESSES_UNIQUE=1. This will result in relayed SMS source addresses of the form:

prefixnnnnnnnnnn

where nnnnnnnnnn will be a unique, ten digit decimal number.

Configure the SMSC

Finally, the SMSC should be configured to route all SMS destination addresses matching the prefix (either just the prefix, or the prefix plus a ten digit number) to the SMS Gateway Server’s SMPP server. The regular expression for such a routing will be similar to:

prefix([0-9]{10,10}){0,1}

where prefix is the value of DEFAULT_SOURCE_ADDRESS, [0-9] specifies the allowed values for the ten digit number, {10, 10} specifies that there will be a minimum of ten digits and a maximum of ten digits, and {0, 1} specifies that there can be zero or one of the 10-digit numbers.

Enabling and Disabling the SMS Gateway Server

Starting and Stopping the SMS Gateway Server

After the SMS Gateway Server is enabled, it may be started and stopped with the following commands:

# start-msg sms

and

# stop-msg sms

SMS Gateway Server Configuration File

In order to operate, the SMS Gateway Server requires a configuration file. The configuration file is a Unicode text file encoded using UTF-8. The file can be an ASCII text file. The name of the file must be:

installation-directory/config/sms_gateway.cnf

Each option setting in the file has the following format:

option-name=option-value

Options that are part of an option group appear in the following format:

[group-type=group-name]
option-name-1=option-value-1
option-name-2=option-value-2
...
option-name-n=option-value-n

Configuring Email-To-Mobile on the Gateway Server

To implement the email-to-mobile part of two-way SMS, you must configure the following:

A Gateway Profile

To configure an email-to-mobile gateway profile, follow these steps:

ProcedureTo Configure an Email-to-mobile Gateway Profile

Steps
  1. Add a gateway profile to the SMS Gateway Server configuration file.

    To add an option group, use the following format:


    [GATEWAY_PROFILE=profile_name]
    option-name-1=option-value-1
    option-name-2=option-value-2a
    ...
    option-name-n=option-value-n

    The length of the gateway profile name, profile_name in the preceding format, must not exceed 11 bytes. The name must be the same as the name for the GATEWAY_PROFILE channel option in the SMS channel option file. The name is case insensitive. For a list of the valid channel options, see Available Options

  2. Set the gateway profile options (for example, SMSC_DEFAULT_CHARSET) to match characteristics of the remote SMSC.

  3. Set the other gateway profile options to match the SMS channel’s email characteristics.

    A complete description of gateway profile options, see Gateway Profile Options

  4. Set the CHANNEL option.

    Set its value to the name of the MTA SMS channel.

    When a notification is sent to email through the gateway, the resulting email message will be enqueued to the MTA using this channel name.

An SMPP Relay

To configure an SMPP Relay, complete the following steps:

ProcedureTo Configure an SMPP Relay

Steps
  1. Add an SMPP relay instantiation (option group) to the SMS Gateway Server’s configuration file.

    To add an option group, use the following format:


    [SMPP_RELAY=relay_name]
    option-name-1=option-value-1
    option-name-2=option-value-2
    ...
    option-name-n=option-value-n

    Any name may be used for the relay’s name. All that matters is that the name not be used for any other SMPP relay instantiation within the same configuration file.

  2. Set the LISTEN_PORT option.

    The value used for the SMS channel’s SMPP_PORT option must match that used for the relay’s LISTEN_PORT option. For the LISTEN_PORT, select a TCP port number which is not used by any other SMPP relay or server instantiation nor by any other server running on the same computer.

  3. Set the SERVER_HOST option.

    The relay’s SERVER_HOST option should give the host name for the remote SMSC’s SMPP server. An IP address may be used in place of a host name.

  4. Set the SERVER_PORT option.

    The relay’s SERVER_PORT option should give the TCP port for the remote SMSC’s SMPP server.

    For a complete description of all SMPP relay options, see SMPP Relay Options

An SMPP Server

To configure an SMPP server, complete the following steps:

ProcedureTo Configure an SMPP Server

Steps
  1. Add an SMPP server instantiation (option group) to the SMS Gateway Server’s configuration file.

    To add an option group, use the following format:


    [SMPP_SERVER=server_name]
    option-name-1=option-value-1
    option-name-2=option-value-2...
    option-name-n=option-value-n

    Any name may be used for the server’s name. All that matters is that the name not be used for any other SMPP server instantiation within the same configuration file.

  2. Set LISTEN_PORT option.

    Select a TCP port number which is not being used by any other server or relay instantiation. Additionally, the port number must not be being used by any other server on the same computer.

    The remote SMSC needs to be configured to route notifications via SMPP to the SMS Gateway Server system using this TCP port.

    For a complete description of all SMPP server options, see SMPP Server Options

Configuring Mobile-to-Email Operation

To configure mobile-to-email functionality, two configuration steps must be performed:

Note that multiple gateway profiles may use the same SMPP server instantiation. Indeed, the same SMPP server instantiation may be used for both email-to-mobile and mobile-to-email applications.

Configure a Mobile-to-Email Gateway Profile

For mobile origination, a gateway profile provides two key pieces of information: how to identify SMS messages intended for that profile and how to convert those messages to email messages. Note that this profile can be the same one used for email-to-mobile with the addition of the SELECT_RE option.

To configure the gateway profile, follow these steps:

ProcedureTo Configure the Gateway Profile

Steps
  1. Add a gateway profile (option group) to the SMS Gateway Server’s configuration file.

    To add an option group, use the following format:


    [GATEWAY_PROFILE=profile_name]
    option-name-1=option-value-1
    option-name-2=option-value-2
    ...
    option-name-n=option-value-n

    Any name of 11 characters or less may be used for the profile’s name. All that matters is that it is not already used for another gateway profile within the same configuration file.

  2. Set the SELECT_RE option must be specified for each gateway profile.

    The value of this option is an ASCII regular expression with which to compare SMS destination addresses. If an SMS destination address matches the regular expression, then the SMS message is sent through the gateway to email using the characteristics described by the matching profile.

    It is important to note that it is possible to configure multiple gateway profiles which have overlapping sets of SMS addresses (for example, a profile which matches the address 000 and another which matches any other three-digit address). However, so doing should be avoided as an SMS message will be passed off to only one gateway profile: the first one which matches. And, moreover, the order in which they are compared is undefined.

  3. Set the CHANNEL option.

    Its value should be the name of the MTA’s SMS channel.

    For a complete description of all mobile origination options, see Gateway Profile Options

Configure a Mobile-to-Email SMPP Server

Adding an SMPP server is the same as for the email-to-mobile SMPP server (see An SMPP Server).

The remote SMSC needs to be configured to route SMS traffic to the gateway SMPP server. To do this, the SMS destination address used by the SMSC to route mobile-to-email traffic should be the value set for the gateway profile option SELECT_RE.

For example, if the SMS address 000 is to be used for mobile-to-email traffic, then the SMSC needs to be configured to route traffic for the SMS destination address 000 to the gateway SMPP server. The gateway profile should use the option setting SELECT_RE=000.

Configuration Options

The SMS Gateway Server configuration file options are detailed in this section. The tables that follow list all the available configuration options with a brief description of each. There is a table each for global options, SMPP relay options, SMPP server options, and SMS Gateway Server profile options.

In the subsections that follow, complete descriptions are given for all the available configuration options. The subsections are:

Global Options

The SMS Gateway Server presently has three categories of global options:

All global options must be specified at the top of the configuration file, before any option groups are specified. Table D–20 lists all global configuration options.

Table D–20 Global Options

Options  

Default  

Description  

DEBUG

6

Selects the types of diagnostic output generated 

HISTORY_FILE_DIRECTORY

 

Absolute directory path for files of historical data 

HISTORY_FILE_MODE

0770

Permissions for files of historical data 

HISTORY_FILE_ROLLOVER_PERIOD

30 mins

Maximum length of time to write to the same file of historical data 

LISTEN_CONNECTION_MAX

 

Maximum number of concurrent inbound connections across all SMPP relay and server instantiations 

RECORD_LIFETIME

3 days

Lifetime of a record in the historical data archive 

THREAD_COUNT_INITIAL

10 threads

Initial number of worker threads 

THREAD_COUNT_MAXIMUM

50 threads

Maximum number of worker threads 

THREAD_STACK_SIZE

64 Kb

Stack size for each worker thread 

Thread Tuning Options

Each inbound TCP connection represents an SMPP session. The processing for a session is handled by a worker thread from a pool of threads. When the session processing needs to wait for completion of an I/O request, the worker thread parks the session and is given other work to perform. When the I/O request completes, the session is resumed by an available worker thread from the pool.

The following options allow for tuning of this pool of worker thread processes: THREAD_COUNT_INITIAL, THREAD_COUNT_MAXIMUM, THREAD_STACK_SIZE.

THREAD_COUNT_INITIAL

(integer, > 0) Number of threads to initially create for the pool of worker threads. This count does not include the dedicated threads used to manage the in-memory historical data (2 threads) nor the dedicated threads used to listen for incoming TCP connections (one thread per TCP port/interface address pair the SMS Gateway Server listens on). The default value is for THREAD_COUNT_INITIAL is 10 threads.

THREAD_COUNT_MAXIMUM

(integer, >= THREAD_COUNT_INITIAL) Maximum number of threads to allow for the pool of worker threads. The default value is 50 threads.

THREAD_STACK_SIZE

(integer, > 0) Stack size in bytes for each worker thread in the pool of worker threads. The default value is 65,536 bytes (64 Kb).

Historical Data Tuning

When an SMS message is relayed, the message ID generated by the receiving, remote SMPP server is saved in an in-memory hash table. Along with this message ID, information about the original email message is also saved. Should that message ID subsequently be referenced by an SMS notification, this information may be retrieved. The retrieved information can then be used to send the SMS notification to the appropriate email recipient.

The in-memory hash table is backed to disk by a dedicated thread. The resulting disk files are referred to as “history files”. These history files serve two purposes: to save, in nonvolatile form, the data necessary to restore the in-memory hash table after a restart of the SMS Gateway Server, and to conserve virtual memory by storing potentially lengthy data on disk. Each history file is only written to for HASH_FILE_ROLLOVER_PERIOD seconds after which time it is closed and a new history file created. When a history file exceeds an age of RECORD_LIFETIME seconds, it is deleted from disk.

The following options allow for tuning historical files: HISTORY_FILE_DIRECTORY, HISTORY_FILE_MODE, HISTORY_FILE_ROLLOVER_PERIOD, RECORD_LIFETIME.

HISTORY_FILE_DIRECTORY

(string, absolute directory path) Absolute path to the directory to which to write the history files. The directory path will be created if it does not exist. The default value for this option is:

msg_svr_base/data/sms_gateway_cache/

The directory used should be on a reasonably fast disk system and have more than sufficient free space for the anticipated storage; see SMS Gateway Server Storage Requirements to change this option to a more appropriate value.

HISTORY_FILE_MODE

(integer, octal value) File permissions to associated with the history files. By default, a value of 0770 (octal) is used.

HISTORY_FILE_ROLLOVER_PERIOD

(integer, seconds) The current history file is closed and a new one created every HASH_FILE_ROLLOVER_PERIOD seconds. By default, a value of 1800 seconds (30 minutes) is used.

RECORD_LIFETIME

(integer, seconds > 0) Lifetime in seconds of a historical record. Records older than this lifetime will be purged from memory; history files older than this lifetime will be deleted from disk. By default, a value of 259,200 seconds (3 days) is used. Records stored in memory are purged in sweeps by a thread dedicated to managing the in-memory data. These sweeps occur every HASH_FILE_ROLLOVER_PERIOD seconds. Files on disk are purged when it becomes necessary to open a new history file.

Miscellaneous

There are two miscellaneous options: DEBUG and LISTEN_CONNECTION_MAX.

DEBUG

(integer, bitmask) Enable debug output. The default value is 6 which selects warning and error messages.

Table D–21 defines the bit values of the DEBUG bitmask.

Table D–21 DEBUG Bitmask

Bit  

Value  

Description  

0-31 

-1

Extremely verbose output 

1

Informational messages 

2

Warning messages 

4

Error messages 

8

Subroutine call tracing 

16

Hash table diagnostics 

32

I/O diagnostics, receive 

64

I/O diagnostics, transmit 

128

SMS to email conversion diagnostics (mobile originate and SMS notification) 

256

PDU diagnostics, header data 

512

PDU diagnostics, body data 

10 

1024

PDU diagnostics, type-length-value data 

11 

2048 

Option processing; sends all option settings to the log file. 

LISTEN_CONNECTION_MAX

(integer, >= 0) The maximum number of concurrent, inbound TCP connections to allow across all SMPP relay and server instantiations. A value of 0 (zero) indicates that there is no global limit on the number of connections. There may, however, be per relay or server limits imposed by a given relay or server instantiation.

SMPP Relay Options

The SMS Gateway Server can have multiple instantiations of its SMPP relay, each with different characteristics chief of which will be the TCP port and interface listened on. Put differently, for each network interface and TCP port pair the SMPP relay listens on, distinct characteristics may be ascribed. These characteristics are specified using the options described in this section.

Each instantiation should be placed within an option group of the form:


[SMPP_RELAY=relay-name]
option-name-1=option-value-1
option-name-2=option-value-2
...
option-name-n=option-value-n

The string relay-name merely serves to differentiate this instantiation from other instantiations.

Table D–22 lists the SMPP relay configuration options.

Table D–22 SMPP Relay Options

Options  

Default  

Description  

LISTEN_BACKLOG

255

Connection backlog for inbound SMPP client connections 

LISTEN_CONNECTION_MAX

 

Maximum number of concurrent inbound connections 

LISTEN_INTERFACE_ADDRESS

 

Network interface for inbound SMPP client connections 

LISTEN_PORT

 

TCP port for inbound SMPP client connections 

LISTEN_RECEIVE_TIMEOUT

600 s

Read timeout for inbound connections from SMPP clients 

LISTEN_TRANSMIT_TIMEOUT

120 s

Write timeout for inbound connections from SMPP clients 

MAKE_SOURCE_ADDRESSES_UNIQUE

1

Make relayed SMS source addresses unique and able to be replied to 

SERVER_HOST

 

Host name or IP address of the SMPP server to relay to 

SERVER_PORT

 

TCP port of the SMPP server to relay to 

SERVER_RECEIVE_TIMEOUT

600 s

Read timeout for outbound SMPP server connections 

SERVER_TRANSMIT_TIMEOUT

120 s

Write timeout for outbound SMPP server connections 

LISTEN_BACKLOG

(integer, in [0,255]) Connection backlog allowed by the TCP stack for inbound SMPP client connections. The default value is 255.

LISTEN_CONNECTION_MAX

(integer, >= 0) The maximum number of concurrent, inbound TCP connections to allow for this SMPP relay instantiation. Note that this value will be ignored if it exceeds the global LISTEN_CONNECTION_MAX setting.

LISTEN_INTERFACE_ADDRESS

(string, "INADDR_ANY" or dotted decimal IP address) The IP address of the network interface to listen to for inbound SMPP client connections. May be either the string “INADDR_ANY” (all available interfaces) or an IP address in dotted decimal form. (For example, 193.168.100.1) The default value is “INADDR_ANY”. Clustered HA configurations will need to set this value to correspond to the HA logical IP address.

LISTEN_PORT

(integer, TCP port number) TCP port to bind to for accepting inbound SMPP client connections. Specification of this option is mandatory; there is no default value for this option. Note also that there is no Internet Assigned Numbers Authority (IANA) assignment for this service.

LISTEN_RECEIVE_TIMEOUT

(integer, seconds > 0) Timeout to allow when waiting to read data from an SMPP client. The default value is 600 seconds (10 minutes).

LISTEN_TRANSMIT_TIMEOUT

(integer, seconds > 0) Timeout to allow when sending data to an SMPP client. The default value is 120 seconds (2 minutes).

MAKE_SOURCE_ADDRESSES_UNIQUE

(0 or 1) By default, the SMPP relay will append to each SMS source address a unique, ten digit string. The resulting SMS source address is then saved along with the other historical data. The result is a unique SMS address which may then be replied to by SMS users. The SMPP server will detect this address when used as an SMS destination address and will then send the SMS message to the correct email originator.

To disable this generating of unique SMS source addresses (for one-way SMS), specify a value of 0 (zero) for this option.

SERVER_HOST

(string, TCP hostname or dotted decimal IP address) SMPP server to relay SMPP client traffic to. Either a hostname or IP address may be specified. Specification of this option is mandatory; there is no default value for this option.

SERVER_PORT

(integer, TCP port number) TCP port for the remote SMPP server to which to relay. Specification of this option is mandatory; there is no default value for this option. There is no IANA assignment for this service; do not confuse with the IANA assignment for SNPP.

SERVER_RECEIVE_TIMEOUT

(integer, seconds > 0) Timeout to allow when waiting to read data from the SMPP server. The default value is 600 seconds (10 minutes).

SERVER_TRANSMIT_TIMEOUT

(integer, seconds > 0) Timeout to allow when sending data to the SMPP server. The default value is 120 seconds (2 minutes).

SMPP Server Options

The SMS Gateway Server can have multiple instantiations of its SMPP server, each with different characteristics chief of which will be the TCP port and interface listened on. Put differently, for each network interface and TCP port pair the SMPP server listens on, distinct characteristics may be ascribed. These characteristics are specified using the options described in this section.

Each instantiation should be placed within an option group of the form:


[SMPP_SERVER=server-name]
option-value-1=option-value-1
option-value-2=option-value-2
...
option-name-n=option-value-n

The string server-name merely serves to differentiate the instantiation from other instantiations.

Table D–23 lists the SMPP server configuration options.

Table D–23 SMPP Server Options

Options  

Default  

Description  

LISTEN_BACKLOG

255

Connection backlog for inbound SMPP server connections 

LISTEN_CONNECTION_MAX

 

Maximum number of concurrent inbound connections 

LISTEN_INTERFACE_ADDRESS

 

Network interface for inbound SMPP server connections 

LISTEN_PORT

 

TCP port for inbound SMPP server connections 

LISTEN_RECEIVE_TIMEOUT

600 s

Read timeout for inbound SMPP server connections 

LISTEN_TRANSMIT_TIMEOUT

120 s

Write timeout for inbound SMPP server connections 

LISTEN_BACKLOG

(integer in [0,255]) Connection backlog allowed by the TCP stack for inbound SMPP client connections. The default value is 255.

LISTEN_CONNECTION_MAX

(integer >= 0) The maximum number of concurrent, inbound TCP connections to allow for this SMPP server instantiation. Note that this value will be ignored if it exceeds the global LISTEN_CONNECTION_MAX setting.

LISTEN_INTERFACE_ADDRESS

(string, "INADDR_ANY" or dotted decimal IP address) The IP address of the network interface to listen to for inbound SMPP client connections on. May be either the string “INADDR_ANY” (all available interfaces) or an IP address in dotted decimal form. (For example, 193.168.100.1.) The default value is “INADDR_ANY”.

LISTEN_PORT

(integer, TCP port number) TCP port to bind to for accepting inbound SMPP client connections. Specification of this option is mandatory; there is no default value for this option. Note that there is no IANA assignment for this service.

LISTEN_RECEIVE_TIMEOUT

(integer, seconds > 0) Timeout to allow when waiting to read data from an SMPP client. The default value is 600 seconds (10 minutes).

LISTEN_TRANSMIT_TIMEOUT

(integer, seconds > 0) Timeout to allow when sending data to an SMPP client. The default value is 120 seconds (2 minutes).

Gateway Profile Options

There may be zero or more gateway profiles. In the SMS Gateway Sever’s configuration file, each gateway profile is declared within an option group in the following format:


[GATEWAY_PROFILE=profile-name]
option-name-1=option-value-1
option-name-2=option-value-2
...
option-name-n=option-value-n

The string profile-name merely serves to differentiate the profile from other origination profiles.

Table D–24 lists the SMS Gateway Server profile options.

Table D–24 SMS Gateway Server Profile Options

Options 

Default 

Description 

CHANNEL

sms

Channel to enqueue message as 

EMAIL_BODY_CHARSET

US-ASCII

Character set for email message bodies 

EMAIL_HEADER_CHARSET

US-ASCII

Character set for email message headers 

FROM_DOMAIN

 

Domain name for routing email back to SMS 

PARSE_RE_0, PARSE_RE_1, ..., PARSE_RE_9

 

Regular expressions for parsing SMS message text 

PROFILE

GSM

SMS profile to operate under: GSM, TDMA, or CDMA 

SELECT_RE

 

Regular expression for selecting the plugin 

SMSC_DEFAULT_CHARSET

US-ASCII

SMSC’s default character set 

USE_SMS_PRIORITY

0

Gateway SMS priority flags to email 

USE_SMS_PRIVACY

0

Gateway SMS privacy indicators to email 

CHANNEL

(string, 1-40 characters) Name of the MTA channel used to enqueue email messages. If not specified, then “sms” is assumed. The specified channel must be defined in the MTA’s configuration.

EMAIL_BODY_CHARSET

(string, character set name) The character set to translate SMS text to prior to insertion into an email message’s body. If necessary, the translated text will be MIME encoded. The default value is US-ASCII. If the SMS message contains glyphs not available in the charset, they will be converted to mnemonic characters, which may or may not be meaningful to the recipient.

A list of the character sets known to the MTA may be found in the following file:

installation-directory/config/charsets.txt

EMAIL_HEADER_CHARSET

(string, character set name) The character set to translate SMS text to prior to insertion into an RFC 822 Subject: header line. If necessary, the translated string will be MIME encoded. The default value is US-ASCII. If the SMS message contains glyphs not available in the charset, they will be converted to mnemonic characters, which may or may not be meaningful to the recipient

FROM_DOMAIN

(string, IP host name, 1-64 characters) Domain name to append to SMS source addresses when constructing envelope From: addresses for email messages. The name specified should be the correct name for routing email back to SMS. (For example, the host name associated with the MTA SMS channel.) If not specified, then the official host name of the channel specified with the CHANNEL option will be used.

PARSE_RE_0, PARSE_RE_1, ..., PARSE_RE_9

(string, UTF-8 regular expression) For mobile origination of email, the gateway profile needs to extract a destination email address from the text of the SMS message. This is done by means of one or more POSIX-compliant regular expressions (REs). The text of the SMS message will be evaluated by each regular expression until either a match producing a destination email address is found or the list of regular expressions exhausted.


Note –

Use of PARSE_RE_* and ROUTE_TO options are mutually exclusive. Use of both in the same gateway profile is a configuration error.


Each regular expression must be POSIX compliant and encoded in the UTF-8 character set. The regular expressions must output as string 0 the destination address. They may optionally output text to use in a Subject: header line as string 1, and text to use in the message body as string 2. Any text not “consumed” by the regular expression will also be used in the message body, following any text output as string 2.

The regular expressions will be tried in the order PARSE_RE_0, PARSE_RE_1, ..., up to PARSE_RE_9. If no regular expressions are specified, then the following default regular expression is used:

[ \t]*([^\( ]*)[ \t]*(?:\(([^\)]*\))?[ \t]*(.*)

This default regular expression breaks into the following components:

[ \t]*

Ignore leading white space characters (SPACE and TAB).

([^\( ]*)

Destination email address. This is the first reported string.

[ \t]*

Ignore white space characters.

(?:\(([^\)]*)$1\))?

Optional subject text enclosed in parentheses. This is the second reported string. The leading ?: causes the outer parentheses to not report a string. They are being used merely for grouping their contents together into a single RE for the trailing ?. The trailing ? causes this RE component to match only zero or one time and is equivalent to the expression {0,1}.

[ \t]*

Ignore white space characters.

(.*)

Remaining text to message body. This is the third reported string.

For example, with the above regular expression, the sample SMS message:

dan@sesta.com(Testing)This is a test

yields the email message:


To: dan@sesta.com
Subject: Testing

This is a test

As a second example, the SMS message:

sue@sesta.com This is another test

would yield:

To: sue@sesta.com

This is another test

Note that the SMS message, prior to evaluation with these regular expressions, will be translated to the UTF-16 encoding of Unicode. The translated text is then evaluated with the regular expressions which were previously converted from UTF-8 to UTF-16. The results of the evaluation are then translated to US-ASCII for the destination email address, EMAIL_HEADER_CHARSET for the Subject: text, if any, and EMAIL_BODY_CHARSET for the message body, if any.

PROFILE

(string, “GSM”, “TDMA”, or “CDMA”) SMS profile to assume. Presently this information is only used to map SMS priority flags to RFC 822 Priority: header lines. Consequently, this option has no effect when USE_SMS_PRIORITY=0 which is the default setting for that option.

SELECT_RE

(string, US-ASCII regular expression) A US-ASCII POSIX-compliant regular expression to compare against each SMS message’s SMS destination address. If an SMS message’s destination address matches this RE, then the SMS message will be sent through the gateway to email in accord with this gateway profile.

Note that since an SMS message’s destination address is specified in the US-ASCII character set, this regular expression must also be expressed in US-ASCII.

SMSC_DEFAULT_CHARSET

(string, character set name) The name of the default character set used by the remote SMSC. The two common choices for this option are US-ASCII and UTF-16-BE (USC2). If not specified, US-ASCII is assumed.

USE_SMS_PRIORITY

(integer, 0 or 1) By default (with USE_SMS_PRIORITY=0), priority flags in SMS messages are ignored and not sent with the email messages. To have the priority flags passed with the email, specify USE_SMS_PRIORITY=1. When passed with the email, the mapping from SMS to email is as shown in Table D–25:

Table D–25 Priority Flag Mapping from SMS to Email

SMS Profile  

SMS Priority Flag  

Email Priority: Header Line  

GSM 

0 (Non-priority)

1, 2, 3 (Priority)

No header line (implies Normal)

Urgent

TDMA 

0 (Bulk)

1 (Normal)

2 (Urgent)

3 (Very Urgent)

Nonurgent

No header line (implies Normal)

Urgent

Urgent

CDMA 

0 (Normal)

1 (Interactive)

2 (Urgent)

3 (Emergency)

No header line (implies Normal)

Urgent

Urgent

Urgent

Note that the email Priority: header line values are Nonurgent, Normal, and Urgent.

USE_SMS_PRIVACY

(integer, 0 or 1) By default (with USE_SMS_PRIVACY=0), SMS privacy indications are ignored and not sent with the email messages. To have this information passed with the email, specify USE_SMS_PRIVACY=1. When passed along with email, the mapping from SMS to email is as shown in Table D–26:

Table D–26 Privacy Flags Mapping from SMS to Email

SMS Privacy Flag  

Email Sensitivity: Header Line  

0 (Not restricted)

No header line 

1 (Restricted)

Personal

2 (Confidential)

Private

3 (Secret)

Company-confidential

Note that the values of the email Sensitivity: header line are Personal, Private, and Company-confidential.

Configuration Example for Two-Way SMS

Assumptions on Behavior

For the sake of this example, let us assume that the following behavior is desired:

In order to bring about this behavior, the following assumptions and assignments are made

Further Assumptions and Assignments

SMS Channel Configuration

To effect the above behavior, the following SMS channel configuration may be used in the imta.cnf file (add these lines to the bottom of the file):

(blank line)
sms
sms.domain.com

SMS Channel Option File

The channel’s option file, sms_option, would then contain the following settings:

SMPP_SERVER=gateway.domain.com
SMPP_PORT=503
USE_HEADER_FROM=0
DEFAULT_SOURCE_ADDRESS=000
GATEWAY_PROFILE=sms1
SMSC_DEFAULT_CHARSET=UCS2

SMS Gateway Server Configuration

Finally, the Gateway Server configuration file, sms_gateway.cnf, should look like the following:


HISTORY_FILE_DIRECTORY=/sms_gateway_cache/
[SMPP_RELAY=relay1]
LISTEN_PORT=503SERVER_HOST=smpp.domain.com
SERVER_PORT=377

[SMPP_SERVER=server1]
LISTEN_PORT=504

[GATEWAY_PROFILE=sms1]
SELECT_RE=000([0-9]{10,10}){0,1}
SMSC_DEFAULT_CHARSET=UCS2

Testing This Configuration

If you do not have an SMSC to test on, you may want to perform some loopback tests. With some additional settings in the sms_option file, some simple loop back tests may be performed for the above configuration.

Additional sms_option File Settings

The additional settings for the sms_option file are:

! So that we don’t add text to the body of the SMS message
FROM_FORMAT=
SUBJECT_FORMAT=
CONTENT_PREFIX=

Without these settings, an email containing:

user@domain.com (Sample subject) Sample text

would get converted into the SMS message:

From:user@domain.com Subject:Sample Subject Msg:Sample text

That, in turn, would not be in the format expected by the mobile-to-email code, which wants to see:

user@domain.com (Sample subject) Sample text

Hence the need (for loopback testing) to specify empty strings for the FROM_FORMAT, SUBJECT_FORMAT, and CONTENT_PREFIX options.

Performing the Loopback Test

Send test email messages addressed to 000@sms.domain.com, such as:

user@domain.com (Test message) This is a test message which should loop back

The result is that this email message should be routed back to the email recipient user@domain.com.Be sure to have added sms.domain.com to your DNS or host tables for the test.