SMQ2 is a proposed replacement for our current smqueue text messaging store-and-forward server. This project is in its early planning stages and will probably actually start in early 2012.
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:
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.
The address resolution system polls the database for any message in the "unresolved" state, resolves the destination E.164/ISDN addresses to a deliverable URI and changes the message state to "resolved".
Each outbound interface polls the database for any message in the "resolved" state 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.
Optionally, a delivery report facility can poll the database for message in the "delivered" state and generate SMS delivery reports.
The core message queue is an SQL database of messages waiting for delivery, with all format translation and address resolution complete.
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.
SMQ2 needs an resolution mechanism for delivery addresses, similar to the "dialplan" in Asterisk, although we already know that Asterisk is not suitable for this task. The input to this mechanism is a telephonic URI. The output is a URI matched to some supported protocol interface.
FreeSwitch chat plan?
Should/can we define an API to allow plug-in of any external resolution mechanism? Since the inputs and outputs are URI strings, this should not be difficult.
This is the native interface for OpenBTS.
OneAPI is GSMA's attempt to standardize HTTP access to certain core network services.
Most bulk-messaging services (like Clickatel, offer HTTP interfaces. Some are moving to the OneAPI standard and some are custom.
SMPP is the reining standard for accessing SMSCs from outside of the SS7 network. SMQ2 should certainly support it.
The proposed interface for short code handlers is HTTP or HTTPS. This approach allows the handlers to be implemented as CGI programs in a web server.
GET? POST? In any case, the invocation should include:
The 200 OK response includes optional response message content to be returned to the original sender.