Sun Java System Messaging Server 6.3 Administration Guide

C.4 SMS Gateway Server Theory of Operation

The SMS Gateway Server facilitates two-way SMS through mechanisms that allow mobile originated SMS messages to be matched to the correct email address. The following SMS Gateway Server topics are covered in this section:

C.4.1 Function of the SMS Gateway Server

The SMS Gateway Server simultaneously functions as both an SMPP relay and server. It may be configured to have multiple “instantiations” of each function. For instance, it may be configured to have three different SMPP relays, each listening on different TCP ports or network interfaces and relaying to different remote SMPP servers. Similarly, it may be configured to have four different SMPP servers, each listening on different combinations of TCP ports and network interfaces.

The SMS Gateway Server may be configured with zero or more gateway profiles for sending SMS messages to email. Each gateway profile describes which destination SMS addresses match the profile, how to extract the destination email addresses from SMS messages, and various characteristics of the SMS to email conversion process. Each SMS message presented to the SMS Gateway Server through either its SMPP relay or server are compared to each profile. If a match is found, then the message is routed to email.

Finally, the gateway profiles also describe how to handle notification messages returned by remote SMSCs in response to previous email-to-mobile messages.

C.4.2 Behavior of the SMPP Relay and Server

When acting as an SMPP relay, the SMS Gateway Server attempts to be as transparent as possible, relaying all requests from local SMPP clients on to a remote SMPP server and then relaying back the remote server’s responses. There are two exceptions:

Note that typically the SMS Gateway Server will be configured such that the unique SMS source addresses which it generates match one of the gateway profiles.


Note –

The SMS Gateway Server’s SMPP relay is only intended for use with qualified, Sun Java System SMPP clients, that is, the Sun Java System Messaging Server’s SMS channel. It is not intended for use with arbitrary SMPP clients.


When acting as an SMPP server, the SMS Gateway Server directs SMS messages to email for three circumstances:

All other SMS messages are rejected by the SMPP server.

C.4.3 Remote SMPP to Gateway SMPP Communication

Remote SMPP clients communicate to the Gateway SMPP server with Protocol Data Units (PDUs). Remote SMPP clients emit request PDUs to which the Gateway SMPP server responds. The Gateway SMPP server operates synchronously. It completes the response to a request PDU before it processes the next request PDU from the connected remote SMPP client.

Table C–19 that follows lists the request PDUs the Gateway SMPP server handles, and specifies the Gateway SMPP server’s response.

Table C–19 SMPP Server Protocol Data Units

Request PDU  

SMPP Server Response  

BIND_TRANSMITTERBIND_TRANSCEIVERUNBIND

Responded to with the appropriate response PDU. Authentication credentials are ignored. 

OUTBIND

Gateway SMPP server sends back a BIND_RECEIVER PDU. Authentication credentials presented are ignored.

SUBMIT_SMDATA_SM

Attempts to match the destination SMS address with either a unique SMS source address or the SELECT_RE setting of a Gateway profile. If neither is matched, the PDU is rejected with an ESME_RINVDSTADR error.

DELIVER_SM

Attempts to find either the destination SMS address or the receipted message ID in the historical record. If neither is matched, returns the error ESME_RINVMSGID.

BIND_RECEIVER

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

SUBMIT_MULTI

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

REPLACE_SM

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

CANCEL_SM

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

QUERY_SM

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

QUERY_LAST_MSGS

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

QUERY_MSG_DETAILS

Not supported. Returns a GENERIC_NAK PDU with an ESME_RINVCMDID error.

ENQUIRE_LINK

Returns ENQUIRE_LINK_RESP PDU.

ALERT_NOTIFICATION

Accepted but ignored. 

C.4.4 SMS Reply and Notification Handling

The SMS Gateway Server maintains a historical record of each SMS message relayed through its SMPP relays. The need to use historical data arises from the fact that when submitting an email message to SMS it is generally not possible to convert the email address of the message’s originator to an SMS source address. Since any SMS replies and notifications will be directed to this SMS source address, a problem arises. This is resolved by using automatically generated, unique SMS source addresses in relayed messages. The remote SMSCs are then configured to route these SMS source addresses back to the Gateway SMPP server.

The historical data is represented as an in-memory hash table of message IDs and generated, unique SMS source addresses. This data along with the associated email origination data are also stored on disk. The disk based storage is a series of files, each file representing HASH_FILE_ROLLOVER_PERIOD seconds of transactions (the default is 30 minutes). Each file is retained for RECORD_LIFETIME seconds (the default is 3 days). See theSun Java Communications Suite 5 Deployment Planning Guide for a discussion of the in-memory and on-disk resource requirements of the historical data.

Each record has three components:

C.4.4.1 Routing Process for SMS Replies

The Gateway SMPP relays and servers use historical records to handle SMS replies, notifications and mobile originated messages. When an SMS message is presented to the SMPP relay or server, the following routing process is followed:

  1. The SMS destination address is compared against the historical record to see if there is a matching, unique SMS source address that the SMPP relay previously generated. If a match is found, see Step 6. .

  2. If there is no match, but the message is an SMS notification (SMPP DELIVER_SM PDU), then the receipted message ID, if present, is compared against the historical record. If a match is found, go to Step 8. [The SMS Gateway Server actually allows these to be presented to either the SMPP relay or SMPP server.]

  3. If there is no match, then the destination SMS address is compared against the SELECT_RE option expressions for each configured gateway profile. If a match is found, then go to Step 9.

  4. If there is no match and the SMS message was presented to the Gateway SMPP relay, then the message is relayed to the remote SMPP server.

  5. If there is no match and the SMS message was presented to the Gateway SMPP server, then the message is determined to be an invalid message and an error response is returned in the SMPP response PDU. For email to SMS, a Non Delivery Notification (NDN) is eventually generated.

  6. If a matching unique SMS source address was found, then the SMS message is further inspected to see if it is a reply or a notification message. To be a notification message it must be a SUBMIT_SM PDU with a receipted message ID. Otherwise, it is considered to be a reply.

  7. If it is a reply then the SMS message is converted to an email message using the origination email information from the historical record.

  8. If it is a notification, then the SMS message is converted to an email Delivery Status Notification (DSN) as per RFC 1892-1894. Note that the ESMTP NOTIFY flags (RFC 1891) of the original email message will be honored (For example, if the SMS message is a “success” DSN but the original email message requested only “failure” notifications, then the SMS notification will be discarded).

  9. If the destination SMS address matches a SELECT_RE option in a configured gateway profile, then the SMS message is treated as a mobile originated message and converted back to email message as per the PARSE_RE_n rules for that gateway profile. If the conversion fails, then the SMS message is invalid and an error response is returned.