Table of Contents
Lark Router supports both the Short Messaging Service (SMS) and the Multimedia Messaging Service (MMS). SMS messages are purely text-based, traditionally up to 160 characters long (although current services support longer messages using the GSM specified message concatenation mechanism), while MMS messages are intended to provide a rich set of content to subscribers (including pictures, audio, games, etc). Both SMS and MMS are non-real-time delivery services, much like email. Both services utilize a store-and-forward model between providers.
Providers #
A provider in Lark Router is represented by their bind. A bind encapsulates:
- The connectivity information for the provider. The information depends on the type of provider (client or supplier) and the protocols used to exchange messages with the provider (more on this below).
- Messaging parameters (such as default message validity, priority, throughput limitations, etc.).
- Message processing rules (such as number normalization rules, delivery reports delivery rules, etc.)
- Provider status: Whether the bind is active (i.e. running), message delivery statistics, message queue statistics, etc.
Bind parameters must be agreed between the provider and the organization. A bind must be created and activated for each provider in the gateway instance in order to receive and send messages to the provider.
Message Processing #
Protocols
Lark Router supports a number of standard as well as proprietary SMS and MMS message exchange protocols:
- MMS Protocols supported are:
- MM7: The ETSI/3GPP standard SOAP/XML MMS interface between the MMSC and a ‘value-added service provider (VASP)’. The MM7 interface is used to send MMS from 3rd party providers (e.g., a bank sending a statement or an advertiser sending publicity). It is based on SOAP with attachments, using HTTP as the transport protocol. HTTP request is MIME-encoded POST. The request encapsulates the SOAP envelope and the encoded content attachments. The SOAP envelope is an XML where tags are the MM7 meta data. To clients (who are VASP in MM7 terms) Lark acts as the MMSC, while to a supplier, Lark acts as the VASP (and the supplier side acts as the MMSC).
- MM4: The ETSI/3GPP standard interface used to exchange messages between two different MMSCs. These MMSCs are generally located in two distinct Mobile Networks. The protocol is based on SMTP. Lark Router acts as an MMSC from the point of view of both clients and suppliers.
- MM1: The ETSI/3GPP standard interface between a Mobile Station (MS) and an MMSC. MM1 binds are always for suppliers. The MM1 interface is based on the WAP protocol. MM1 is used in the following actions:
- The subscriber sends an MMS to the MMSC
- The MMSC notifies the recipient’s device that he/she has an MMS waiting for retrieval
- The recipient’s device retrieves the MMS from the MMSC
- The MMSC notifies the sender’s device that the recipient has retrieved the message (if the sender requested a delivery report).
- Proprietary HTTP Protocol: The fast, Lark-specific protocol for exchanging MMS with providers. This protocol supports:
- Automated creation of MMS from external content (i.e. URLs) of different types (image, video, SMIL).
- Message parameters set via CGI parameters in the HTTP request
- Use of content caching to improve message speed where the same message is sent to many subscribers.
- Sending delivery reports via URL call.
- SMS-2-MMS: The Lark Router protocol that supports the conversion of MT SMS content into MT MMS. The SMS may contain the URL path to a multimedia content file, which the gateway will retrieve, combine with the SMS text to create an MMS message.
- SMS Protocols supported are:
- Short Messaging Peer to Peer Protocol (SMPP): An open, industry-standard protocol designed to provide transfer of short message data between External Short Message Entities (ESME), Routing Entities (RE) and Message Centres (MC). It is a means by which applications can send SMS messages to mobile devices and receive SMS from mobile devices. From the point of view of a client, the Lark Router gateway acts as the MC. That is, the client connects to the gateway’s SMPP port as it would to an ordinary MC’s SMPP network port, and sends and receives SMS and DLR. From the point of view of a supplier, the gateway is an ESME. That is, the gateway connects to the supplier’s SMPP network port and sends and receives SMS DLR. The gateway supports version 5 of the protocol.
- Twilio HTTP-based Protocol: The proprietary Twilio API for sending and receiving SMS. From the point of view of a client, the gateway acts as the Twilio endpoint. From the point of view of the supplier, the gateway acts as a Twilio API client.
- NexMo HTTP-based Protocol: The proprietary NexMo API for sending and receiving SMS. From the point of view of a client, the gateway acts as the NexMo endpoint. From the point of view of the supplier, the gateway acts as a NexMo API client.
- InfoBIP HTTP-based Protocol: The proprietary InfoBIP API for sending and receiving SMS. From the point of view of a client, the gateway acts as the InfoBIP endpoint. From the point of view of the supplier, the gateway acts as an InfoBIP API client.
- Sinch HTTP-based Protocol: The proprietary Sinch API for sending and receiving SMS. From the point of view of a client, the gateway acts as the Sinch endpoint. From the point of view of the supplier, the gateway acts as a Sinch API client.
- Lark Router HTTP-based Protocol: The Lark Router protocol. SMS can be sent/received by the provider using HTTP CGI parameters.
The gateway exposes network ports for each class of protocols and type of provider:
- HTTP, SMPP, and MM4 ports for client-originating messages. The client authenticates itself to the gateway using credentials configured on the specific bind.
- HTTP, MM1, and MM4 ports for supplier-originating message transactions. The supplier authenticates itself to the gateway using credentials configured on the specific bind.
Routing
When the gateway receives a provider-originated message, such as a client-initiated MT message, the message is processed according to the following general flow:
- Provided the provider is properly authenticated (e.g. using username and password for MM7), the message is received and stored to the gateway’s queue database.
- The message is routed to the destination provider bind, based on the recipient number and/or sender bind. For instance, a client-initiated MT should normally be routed to a supplier bind. The gateway supports flexible rules for specifying how routes are determined.
- The gateway periodically processes the outgoing bind queues, for each message it converts the message into the protocol format required by the destination provider and attempts to send the message to the provider.
- In case of delivery failure (e.g. due to throttling on the provider side), the gateway re-queues the message for future delivery attempts. If the bind-specific number of delivery attempts is exceeded, the message is discarded and a delivery report (if requested) is queued back to the sending provider.
- When a message is sent to a supplier and a delivery report is requested by the client, the gateway keeps track of supplier-side transactions, so that when a DLR is received it is routed back to the correct client.
- The gateway writes transaction logs (call detail logs), as well as maintaining ‘live’ stats during message exchange.
Components #
Lark Router Gateway consists of two main components, the gateway, and the administration console. The gateway is responsible for all message processing (bind connectivity, message reception, routing, and delivery, etc.). The administration console provides the main configuration and monitoring interface for the system.