This section provides a brief overview of the interactions between the ColdFusion MX SMS event gateway and the SMPP provider's SMSC. It is designed to help you to understand the basics of SMPP interactions, and defines the terms necessary to for you to understand gateway configuration and message handling. For more details, see the SMPP specification, which is available at www.smsforum.net/.
A typical interaction between an SMSC and a ColdFusion SMS event gateway instance consists of messages, or PDUs sent between the two entities, such as a mobile device and a ColdFusion MX event gateway instance (and therefore, and event gateway application). The following sections describe these interactions and how you handle them in ColdFusion MX.
This section describes the following topics:
The event gateway must bind to the SMSC before they can communicate. The SMS event gateway instance initiates a binding by sending a bind_transceiver PDU to the SMSC, which includes the gateway's ID and password. If the initial bind request fails, the gateway retries the bind at the rate specified by the gateway configuration file retry-interval value until either the bind is successful or the gateway reaches the maximum number of retries, specified by the retries configuration value. If the bind operation fails, ColdFusion logs an error to the eventgateway.log file, and you must restart the gateway instance in the ColdFusion MX Administrator to establish the connection.
Note: Some SMSCs can send a prohibited status in response to a bind request. If the gateway receives such a status response, it sets the retry interval to one minute and the maximum number of retries to 15. The SMS gateway detects SMPP 5.0-compliant and AT&T prohibited status responses.
When the SMSC accepts the bind request, it returns a bind_transceiver_resp PDU. The binding remains in effect until the gateway instance shuts down and sends an unbind PDU to the SMSC. Because the gateway binds as a transceiver, it can initiate messages to the SMSC, and the SMSC can send messages to it.
If the ColdFusion SMS event gateway gets an Unbind PDU from the SMSC, it sends an unbind_resp PDU to the SMSC, does a restart, and attempts to rebind to the SMSC.
When the event gateway receives an EnquireLink or any other request PDU from the SMSC, it sends a default response to the SMSC.
The gateway receives incoming messages from the SMSC in deliver _sm PDUs; it does not handle data_sm PDUs. Deliver_sm PDUs can contain user- or application-generated messages, or disposition responses for messages that the gateway has sent. The gateway extracts the short message field and source and destination addresses from the PDU, puts them in a CFEvent object, and sends the object to ColdFusion event gateway services for delivery to the listener CFC. For information on how the CFML application must handle these incoming messages, see Handling incoming messages.
The gateway supports three types of outgoing messages from ColdFusion applications. The CFML sendGatewayMessage function or a listener CFC method cfreturn tag can specify the following commands:
submit Sends a submit_sm PDU with the message contents to the SMSC. This PDU sends a message to a single destination.
submitMulti Sends a submit_multi PDU with the message contents to the SMSC. This PDU sends a message to multiple destinations.
data Sends a data_sm PDU with the message contents to the SMSC. This is an alternative to the submit command, and is typically used by interactive applications such as those provided via a wireless application protocol (WAP) framework.
The SMS gateway lets you control the contents of all of the fields of these PDUs. For more information, see the documentation for the individual commands in Sending outgoing messages.
When you send a message, if the SMSC responds with a status that indicates that the message was rejected or not sent, ColdFusion MX logs information about the failure in the eventgateway.log file. If the SMSC indicates that the service type is not available (SMPP v5 ESME_RSERTYPUNAVAIL status or AT&T Serviced denied status), and the gateway configuration file transient-retry value is set to yes, the gateway also tries to resend the message.
The gateway and SMSC communicate asynchronously: the gateway does not wait for a response from the SMSC for one message before it sends another message. However, you can configure your gateway instance so that the CFML sendGatewayMessage function behaves asynchronously or synchronously.
For more information on configuring message synchronization and sending messages synchronously, see Controlling SMS message sending and response.