SMQ2 is a proposed replacement for our current smqueue text messaging store-and-forward server. This project still in its planning stages.
This is an early-draft strawman proposal, open to discussion.
The core of SMQ2 will be a queue of messages waiting for delivery stored in an SQL-based relational database. SMQ2 should be compatible with a wide range of such databases, especially MySQL, sqlite3 and Oracle. Associated with the database will be a set of APIs easily implemented in any object oriented language. Each implementation should be GPL'd.
Around this core will be external applications of four types:
- short code functions -- These are applications that digest inbound message content and (possibly) generate responses back to the message sender. They may also interact with any kind of external database of application.
- number resolution facilities -- These are applications that analyze the destination addresses of inbound messages and determine what outbound interfaces should be used to deliver them
- protocol interfaces -- The applications accept inbound messages and deliver outbound messages with specific protocols. High-priority protocols include:
- RFC-2438 SIP page mode messaging, in plain/text and IMS formats
- XMPP/Jabber for IM applications
- SMPP for connections to conventional SMSCs
SMS Submission in SIP
The transfer of SMS from the handset to the network is called "submission". When OpenBTS receives SMS for submission, it submits the RPDU to the network in an RFC-3428 MESSAGE method and waits (up to some timeout) for a response. A 200-series response is reported to the handset as successful submission. Any other response type is reported as failure, with cause codes translated appropriately. Responses given after the timeout are currently ignored, although this policy may need to be reviewed against the SMS specifications.
SMS Delivery in SIP
The transfer of SMS from the network to the handset is called "delivery". To initiate delivery SMS to a handset, send an RFC-3428 message to OpenBTS. OpenBTS will respond with 200-OK when the message is delivered to the handset or the attempt will fail silently.
Inbound Message Procedure
SMQ2 is an SMSC replacement, primarily intended to support mobile phones. So inbound messages, from mobile phones, are addressed to E.164/ISDN addresses, represented as telephonic URLs.
- Translate SMS-SUBMIT headers to corresponding SMS-DELIVER headers, if required.
- Enqueue the message for delivery in the "deliverable" state.
- Respond to the sender that the message has been enqueued.
Outbound Message Procedure
Each outbound interface polls the database for any deliverable message with a URI of the type supported by this interface. When it finds such a message, it delivers it, changes the message state to "delivered" and timestamps the message with the delivery time.
Delivery Report Procedure
Optionally, a delivery report facility can poll the database for message in the "delivered" state and generate SMS delivery reports in the "deliverable" state.
Core Database and API
The core message queue is an SQL database of messages waiting for delivery, with all format translation and address resolution complete.
Schema of the Database
Each record in the database represents a message. "Outbound" messages are fully processed and ready for delivery to SIP/SIMPLE endpoints. "Inbound" messages are not yet fully processed and the remaining processing steps are determined by the message state.
- Message Content. This is the "Content" part of the SIP MESSAGE method, normally a 3GPP RPDU but sometimes text/plain.
- For outbound SMS message, this is a DATA RPDU carrying a DELIVER TPDU. This would be a ready-to-deliver L4 payload for SMS.
- For inbound SMS messages awaiting processing, this is a DATA RPDU carrying a SUBMIT TPDU.
- For inbound messages from other interfaces, this might be ASCII text.
- Content Type. The encoding type of the Message Content field.
- Message State. The complete set of message states is not yet determined. Examples, though, might include:
- Alphabet Translation. The message alphabet content must be translated before the message can be delivered.
- PDU Translation. The SUBMIT RPDU needs to be translated to a DELIVER RPDU.
- Deliverable. The message is fully processed and ready for delivery.
- Delivered. The message has been delivered.
API for Database Access
SMQ2 needs an resolution mechanism for delivery addresses. If we use FreeSwitch or yate instead of Asterisk, that SIP application can provide the initial message routing and number resolution facility.
RFC-3428 Page Mode SIP MESSAGE
This is the native interface for OpenBTS.
IMS-style (RPDU payload)
OpenBTS 2.7 and later supports the hex-encoded layer 4 (RL) PDU (RPDU) using the application/vnd.3gpp.sms MIME type. This is the SMS format used in IMS core networks. SMQ2 should also support that.
IM-style (plain/text paylod)
OpenBTS 2.5 and later supports a plain ASCII message payload. This seems to be the preference for internet messaging systems.
OneAPI is GSMA's attempt to standardize HTTP access to certain core network services.
Bulk messaging gateways
Most bulk-messaging services (like Clickatel, offer HTTP interfaces. Some are moving to the OneAPI standard and some are custom.
- Ushahidi is rapidly becoming a standard for information collection in disaster responses. Even the US gov't is starting to use it.
SMPP is the reigning standard for accessing SMSCs from outside of the SS7 network. SMQ2 should certainly support it.
Short Code Handlers
If we use FreeSwitch or yate for initial routing, we can implement short code handlers as external applications called from FreeSwitch or yate, instead of inside SMQ2.