This section contains logging settings.
This section contains a secure client and server certificate and private key settings.
SSL/HTTPS Server Certificate: If protocol traffic (such as MM7, MM4, or SMPP) will be transmitted over secure network ports, the PEM-encoded SSL certificate must be provided.
SSL/HTTPS Server Private Key: This is the PEM-encoded SSL private key associated with the SSL certificate. The private key must not be password protected.
SSL/HTTP Client Certificate & Private Key: If Lark Router must identify itself to external services using an SSL certificate when initiating protocol requests (e.g. MM7 or MM4), the PEM-encoded client SSL certificate and associated private key must be provided. The private key must not be password protected.
This section contains system-wide HTTP protocol settings.
HTTP Client Request Timeout (seconds): HTTP requests to external services that take too long are abandoned, this setting customizes how long Lark router waits for HTTP responses (e.g. to MM7 requests).
HTTP Server Timeout (seconds): HTTP connections to the Lark router that take too long to send a request are abandoned, this setting customizes how long Lark router waits for full HTTP request (e.g. MM7 requests to Lark).
HTTP Proxy Host: If a HTTP PRoxy is needed for HTTP requests (e.g. MM7), enter it here.
This section contains storage database settings.
REDIS Cache Server
REDIS Server Host & Port: Location of the REDIS Server if not using the default
RabbitMQ Server
HOST: Location of the RabbitMQ Database if not the default.
Port: Port number to access the database and whether it is using SSL/TLS
Credentials: Username and Password for RabbitMQ Database.
This section contains queue management configuration information such as storage locations, process frequency, retry intervals, delivery attempts, message validity, etc.
This section contains call detail records and billing configurations.
This section contains content cache control settings. The content cache is used for the temporary storage of MMS content, such as images and videos fetched from external URLs when MMS content is created from SMIL files submitted to Lark.
Protocols and Ports
This section contains supplier-facing network port configurations.
HTTP MO/DLR Port: Suppliers use this port to send MO and DLR messages into Lark where the supplier protocol is HTTP-based. This includes MM7/SOAP, HTTP-based SMS APIs (such as Twilio).
MM4 MO/DLR Port: MM4 MMS suppliers use this port to send MO and DLR messages into Lark.
MM1 Ports: Secure/insecure MM1 MO and MT ports.
Restrict MM4 Request to Network Interface: If the server has multiple IP addresses/network interfaces, Lark can be configured to receive MM4 requests on a specific IP address/network interface. By default, Lark receives MM4 requests on all server addresses.
Restrict MM1 Request to Network Interface: If the server has multiple IP addresses/network interfaces, Lark can be configured to receive MM1 requests on a specific IP address/network interface. By default, Lark receives MM1 requests on all server addresses.
This section contains client-facing network ports settings.
HTTP MT Port: Clients use this port to send MT messages into Lark where the client protocol is HTTP-based. This includes MM7/SOAP, HTTP-based SMS APIs (such as Twilio).
MM4 MT Port: MM4 MMS clients use this port to send MO and DLR messages into Lark.
SMPP Ports: SMS clients use these ports to send SMS MT to (and receive MO/DLR from) Lark using the SMPP protocol.
This section contains the Lark Router Gateway administration interface configurations.
Admin Port: Lark gateway HTTP admin port
Admin Password: Password for accessing Admin API
Whitelist IP: IP addresses that are allowed to access the Admin port
This section contains configurations for SMS to MMS conversion. SMPP custom TLVs can be used in the MT SMS to specify MM7 VAS ID parameters.
VAS ID Lark Specific Optional Parameter Code: The SMPP TLV Tag containing the MM7 VAS ID value in the MT SMS. This is used for SMS to MMS conversion only.
This section contains MM1 MMS configurations.
MM1 Host/IP: Required MM1 Notification Host or IP Address. This is used to create the MM1 notification URL. Note that if the license restricts the MM1 hostname, these settings cannot be changed.
Optimize Notification SMS Size: When set, the MM1 notification SMS does not contain optional data fields (e.g. MMS Subject, date, etc.) so that it is as small as possible.
Send DLR Once MT MMS Message is downloaded by the recipient: When set, the “Retrieved” DLR is queued back to the client as soon as the subscriber downloads the MMS. By default, this DLR is normally only sent once the subscriber device sends back a positive MMS Ack notification (M-Acknowledge.ind packet).
Track Notification SMS DLR: By default, MM1 notification SMS DLR are not tracked/reported. Set this to request SMS DLR for each MM1 notification sent, and reported as MMS DLR (i.e. failed notification DLR is equated to failed MMS DLR, delivered notification DLR is equated to an intermediate MMS DLR).
When Notification is Sent, delete queue entry after: Number of days to keep the MMS entry in the queue, after the MM1 notification has been sent. This setting helps ensure the MM1 queues do not hold more entries than is essential.
When MT MMS is Retrieved, delete queue entry after: Number of days to keep the MMS entry in the queue, after the MMS has been retrieved. This setting helps ensure the MM1 queues do not hold more entries than is essential.
When Notification is Sent, delete stored MMS binary after: Number of days to keep the MMS binary file, after the MM1 notification has been sent. This setting helps ensure the MM1 data storage does not hold more entries than is essential.
When MT Message is retrieved, delete stored MMS binary after: Number of days to keep the binary file, after the MMS has been retrieved. This setting helps ensure the MM1 data storage does not hold more entries than is essential.
Send Custom Error MMS when MM1 Fetch Comes after the message has Expired: When the subscriber device attempts to download the MT MMS after it has expired (i.e. queue entry has been removed), the gateway usually sends back an error MMS (i.e. the M-retrieve-conf packet X-Mms-Retrieve-Status field is set to Error-transient-message-not-found). When this flag is set, a custom MMS response is returned to the subscriber. The settings below are only available if this flag is set.
Custom Error MMS When MM1 Fetch Comes After Message Has Expired: The MMS binary to return to the subscriber in the above case (i.e. subscriber attempts to fetch an expired MMS). This should be specified as a SMIL file, image, or video. The gateway will convert into an MMS using the content templates provided (see below). You can also provide a binary MMS directly.
Reply With Custom MMS Only After Devices Retries This Many Times: Only send the custom MMS above when the device retries to fetch the expired MMS repeatedly. This setting is useful for buggy MMS clients which may keep retrying to fetch the MMS even when the gateway has indicated that the message doesn’t exist.
Reset Each Device’s Failed Retries Counter After: Number of days to clear (reset to zero) the retry counter above, for each MMS client/device.
This section contains SMIL templates for converting different types of content to MMS. These are used for converting images, video, and text to MMS during SMS to MMS conversion (i.e. MT MMS from an SMS client bind) and for MM1 error MMS creation.
Image Only Template (SMIL): SMIL template to use for creating MMS messages from image only content. Defaults have already been installed so only update if needed.
Image +Text Template (SMIL): SMIL template file to use for creating MMS messages from image and text content (i.e. when SMS contains text + an image URL). Defaults have already been installed so only update if needed.
Video Only Template (SMIL): SMIL template file to use for creating MMS messages from video content. Defaults have already been installed so only update if needed.Video + Text Template (SMIL): SMIL Template file to use for creating MMS messages from video + text content (i.e. when SMS contains text + a video URL). Defaults have already been installed so only update if needed.