SMQ2

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.

General Structure

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

Typical Procedures

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.

1. Translate SMS-SUBMIT headers to corresponding SMS-DELIVER headers, if required.
2. Enqueue the message for delivery in the "unresolved" state.
3. Respond to the sender that the message has been enqueued.

Address Resolution

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".

Outbound Message Procedure

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.

Delivery Report Procedure

Optionally, a delivery report facility can poll the database for message in the "delivered" state and generate SMS delivery reports.

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:
  • Address Resolution. The message delivery address needs to be resolved to a SIP endpoint.
  • 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

Number Resolution

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?

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 Interfaces

RFC-3428 Page Mode SIP MESSAGE

This is the native interface for OpenBTS.

IMS-style (RPDU payload)

IM-style (plain/text paylod)

XMPP/Jabber

HTTP Gateways

GSMA OneAPI

 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.

Other applications

•  Ushahidi is rapidly becoming a standard for information collection in disaster responses.  Even the US gov't is starting to use it.
• others?

SMPP

 SMPP is the reining standard for accessing SMSCs from outside of the SS7 network. SMQ2 should certainly support it.

Short Code Handlers

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.

Invocation

GET? POST? In any case, the invocation should include:

• source address
• message content

Response Format

The 200 OK response includes optional response message content to be returned to the original sender.