SMQ2SMQ2 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. General StructureThe 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:
Typical ProceduresInbound Message ProcedureSMQ2 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.
Address ResolutionThe 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". Outbound Message ProcedureEach 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. Delivery Report ProcedureOptionally, a delivery report facility can poll the database for message in the "delivered" state and generate SMS delivery reports. Core Database and APIThe core message queue is an SQL database of messages waiting for delivery, with all format translation and address resolution complete. Schema of the DatabaseEach 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.
API for Database AccessNumber ResolutionSMQ2 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?DUNDI?Generic API?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. Protocol InterfacesRFC-3428 Page Mode SIP MESSAGEThis is the native interface for OpenBTS. IMS-style (RPDU payload)IM-style (plain/text paylod)XMPP/JabberHTTP GatewaysGSMA OneAPIOneAPI is GSMA's attempt to standardize HTTP access to certain core network services. Bulk messaging gatewaysMost bulk-messaging services (like Clickatel, offer HTTP interfaces. Some are moving to the OneAPI standard and some are custom. Other applications
SMPPSMPP is the reining standard for accessing SMSCs from outside of the SS7 network. SMQ2 should certainly support it. Short Code HandlersThe 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. InvocationGET? POST? In any case, the invocation should include:
Response Format
The 200 OK response includes optional response message content to be returned to the original sender. 注:SMQ2(原文出处,翻译整理仅供参考!) |