Preface

Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.

In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.

Mono-spaced Bold

Used to highlight system input, including shell commands, file names and paths. Also used to highlight key caps and key-combinations. For example:

To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.

The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold and all distinguishable thanks to context.

Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-combination. For example:

Press Enter to execute the command.

Press to switch to the first virtual terminal. Press to return to your X-Windows session.

The first sentence highlights the particular key cap to press. The second highlights two sets of three key caps, each set pressed simultaneously.

If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in Mono-spaced Bold. For example:

File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.

Proportional Bold

This denotes words or phrases encountered on a system, including application names; dialogue box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:

Choose System > Preferences > Mouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).

To insert a special character into a gedit file, choose Applications > Accessories > Character Map from the main menu bar. Next, choose Search > Find from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose Edit > Paste from the gedit menu bar.

The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and all distinguishable by context.

Note the menu:>[] shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid the difficult-to-follow 'Select from the Preferences ▸ ] sub-menu in the menu:System[ menu of the main menu bar' approach.

Mono-spaced Bold Italic or Proportional Bold Italic

Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:

To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.

The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.

To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.

Note the words in bold italics above —username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.

Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:

When the Apache HTTP Server accepts requests, it dispatches child processes or threads to handle them. This group of child processes or threads is known as a server-pool. Under Apache HTTP Server 2.0, the responsibility for creating and maintaining these server-pools has been abstracted to a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server.

Pull-quote Conventions

Two, commonly multi-line, data types are set off visually from the surrounding text.

Output sent to a terminal is set in Mono-spaced Roman and presented thus:

books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs

Source-code listings are also set in Mono-spaced Roman but are presented and highlighted as follows:

package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[])
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }

}

Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

A note is a tip or shortcut or alternative approach to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring Important boxes won’t cause data loss but may cause irritation and frustration.

Warning

A Warning should not be ignored. Ignoring warnings will most likely cause data loss.

Provide feedback to the authors!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in the the {this-issue.tracker.ur}, against the product Restcomm SMSC` `, or contact the authors.

When submitting a bug report, be sure to mention the manual’s identifier: Restcomm SMSC

If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

1. Introduction

Restcomm SMSC is an Open Source Java based SMSC Gateway built on a modern extensible middleware platform and provides easy integration with any third party communication protocol and platform. Restcomm SMSC enables mobile operators to provide core SMSC features like subscriber to subscriber SMS messaging, broadcasting campaigns and group messaging[1] between subscribers. In addition it also enables value added services through integration with OTT social networks and microblogs such as Facebook and Twitter.

Restcomm SMSC is an easy-to-install and easy-to-deploy platform that can be set up and configured very quickly. Since it is built on a modern and extensible JSLEE platform it automatically provides out-of-the-box integration with various communication protocols such as SIP, Diameter, HTTP, XCAP, XMPP, MGCP and others in addition to the base SMPP protocol for connectivity to ESMEs.

Restcomm SMSC stores messages using Cassandra database. The database is used for storing unsent messages, messages successfully sent and messages that failed to be sent.

Restcomm SMSC is cloud-ready. It can be deployed on dedicated hardware, private cloud infrastructure or public laaS such as AWS. Restcomm SMSC supports TDM hardware offered by major vendors in the market, namely Intel family boards (Dialogic) and Zaptel/Dahdi (Digium, Sangoma).

Restcomm SMSC is based on the robust and proven Restcomm JAIN SLEE 1.1 Server and Restcomm jSS7 Stack. Restcomm JAIN SLEE Server is a highly scalable event-driven application server with a robust component model and fault tolerant execution environment. It provides a set of connectors to a variety of networks elements: SS7 MAP, TCAP, INAP, ISUP, SMPP, XMPP, SIP, MGCP, HTTP, XDM, XCAP, Diameter and many others. It is fully compliant with JSR 240 (JSLEE 1.1). Restcomm jSS7 is a software based implementation of the SS7 protocol. It provides implementation for Level 2 and above in the SS7 protocol Stack. Restcomm jSS7 Stack User Guide is bundled within and you can refer to the guide for more details on the Stack.

The Open Source Software gives you the flexibility to understand the readily available source code and the freedom to customise the product to meet your Enterprise needs.

This guide provides details on configuring and using the platform and information regarding the supported protocols and compliant standards. For installation instructions, please refer to the Installation Guide published along with this.

2. Overview

2.1. SMSC Gateway

SMSC (Short Message Service Center) is a telecommunications network facility responsible for handling the SMS operations of a wireless network. When a subscriber sends an SMS message from a mobile phone, the message first reaches the SMS Center which then forwards the message to the desired destination. The SMS Center is responsible for routing the SMS messages and regulating the process. If the recipient is not reachable (the phone is switched off or out of coverage area etc.) the SMS Center will store the message to a database and forward it to the recipient when available. Messages that are delivered successfully and messages that failed to be delivered are stored in an archive database for logging purposes.

2.2. Restcomm SMSC

Restcomm 's implementation of SMSC Gateway is the first and only open source SMSC Gateway with a host of rich features and advantages.

Java-based

Restcomm SMSC is the only Java based SMSC Gateway. It is robust and reliable and can be installed on any Operating System that supports Java (JDK 7 and SCTP).

Open Source

The Software is open-source, giving you the freedom to understand the code and customise it to your enterprise needs. It is supported by a vibrant Open source community.

SS7 Hardware Cards

Restcomm SMSC supports E1/T1 links via SS7 cards (Dialogic SS7 cards) or Zaptel/Dahdi compatible TDM devices (Digium, Sangoma).

SIGTRAN (M3UA)

It also supports connectivity to MSC/HLR via SIGTRAN links (M3UA using SCTP).

Charging enabled (Diameter)

Pre paid based charging is enabled (optional) via Diameter Ro and Base protocol. Restcomm SMSC easily integrates with Restcomm Convergent Charging Server over Diameter

Cloud-ready

Restcomm SMSC is cloud-ready and can also be deployed on a private cloud infrastructure.

Easy Configuration and Management

Restcomm SMSC comes with an efficient Command Line Interface (CLI) tool allowing you to easily configure the gateway at run-time and manage it using simple commands rather than do everything manually. Restcomm SMSC also includes an efficient Web Interface administration tool for easy management and monitoring through a Web console.

Major Features

Restcomm SMSC enables mobile operators to provide core SMSC features like subscriber to subscriber SMS messaging, broadcasting campaigns and group messaging between subscribers.

  • Restcomm SMSC can handle mobile originated SMS and deliver them to the intended recipient (mobile, ESME or SIP), it also accepts message uploading from a HTTP connector. It also provides a flexible routing mechanism to route messages to/from ESME over SMPP protocol. Restcomm SMSC supports normal style (Server side) SMPP connection. It can also act as ESME initiating connection to third party SMSC (Client side). Submit_Sm, Data_Sm, Submit_Multi and Deliver_Sm messages are supported.

  • Restcomm SMSC supports SIP connection through JSLEE SIP RA.

  • Restcomm SMSC supports HTTP connection through GET and POST requests (only message uploading).

  • For incoming from SMPP ESME messages, Restcomm SMSC supports StoreAndForward, Datagramm and Transactional modes and a special ForwardAndStore mode for reducing the database load.

    When a message comes from SMPP, the SMSC checks the EsmClass field in the SMPP message. For Datagramm and Transactional modes, the SMSC will try to immediately deliver the message to a destination. If it is in Transactional mode, the SMSC will also return a delivery result (success/failure) to the ESME. Such messages are not stored in the Cassandra database. In case of delivery failure the message will be dropped and no more delivery attempts will be made.

    If the EsmClass field indicates StoreAndForward (or default) mode, more than one attempt will be made to deliver the message (if the first attempt fails). Such messages will be stored in the Cassandra database. The SMSC can be configured in two modes for processing of StoreAndForward messages as shown below:

    StoreAndForward (normal) mode

    In the StoreAndForward mode, an incoming "StoreAndForward" message will always be stored in a database and scheduled for delivery after few seconds. This mode is fully compliant with SMPP specification.

    ForwardAndStore (fast) mode

    In the ForwardAndStore mode, an incoming "StoreAndForward" message will be attempted for delivery immediately, without storing in the database and therefore without any delay. If this first delivery attempt fails, the message will be stored in a database for futher scheduling.

  • Messages that come from SS7 or SIP are processed the same way as "StoreAndForward" messages that come from SMPP ESME. It is possible to configure a default way of message processing ("Datagramm" or "StoreAndForward") for messages that come from HTTP connector.

  • Restcomm SMSC supports Non Transparent Home Routing as explained in 3GPP Specification version 23.840 5.2.3.

  • SMSC has support for SSL for SMPP connection (both client and server side).

  • Restcomm SMSC can be configured for congestion control to reject messages when the number of messages in processing exceeds a configurable limit (MaxActivityCount).

    When the SMSC is configured in ForwardAndStore (fast) mode, SMPP originated messages will be first rejected. Then when the number of messages in processing further increases, SIP originated messages will be rejected and finally SS7 originated messages will be rejected.

    When SMSC is configured in StoreAndForward (normal) mode, only datagramm and transactional SMPP originated messages will be rejected. However StoreAndForward messages and all SS7/SIP originated messages will be stored in the Cassandra database and the scheduling for delivery of these messages will be stopped until the number of messages in processing does not exceed the configured limit.

  • Restcomm SMSC has a congestion control at ESME side. Each ESME can be configured for rate limit per a second, a minute, a hour or a day.

  • Restcomm SMSC supports ReportSMDeliveryStatus and AlertServiceCentre requests after mobile delivery failure.

  • Restcomm SMSC supports GSM7, GSM8 and UCS2 message encoding.

  • Restcomm SMSC itself splits ESME, SIP or HTTP originated long length messages before delivering to mobile phones, if a message does not contain User Data headers (UDH).

  • Multi-tenancy support: Restcomm SMSC supports a model of message network as a splitted to several logical subnetworks and SMSC messages will be logically processed only in one of this logical subnetwork. SMPP ESMEs, SCCP SAPs (Service Access Points) and SIP connector will belong to one of such subnetworks (A subnetwork is identified by a digital value - networkId). Any message that has come to SMSC GW from some port (ESME, SS7, SIP, HTTP) will belong to networkId (subnetwork) from networkId of the port the message has come to SMSC. Then the message will be routed into the port (ESME, SS7, SIP) which belongs to the same networkId (subnetwork).

  • Additionally, when enabled with proper administrator privileges, Restcomm SMSC allows convenient group messaging between subscribers (e.g. family, friends, colleagues) .

  • Restcomm SMSC is built on the Restcomm jSS7 stack which provides advanced SCCP routing rules to map short codes to MSISDN, allowing users to send an SMS to a short-code instead of a complete MSISDN.

  • It also enables value added services through integration with OTT social networks and microblogs such as Facebook and Twitter.

  • A single Restcomm SMSC node can process up to 1000 SMS/sec. Multiple SMSC nodes can be arranged in a cluster across one or more geographically distributed data centers to scale up throughput and provide various levels of redundancy, high availability and fault tolerance.

Restcomm SMSC can be adapted to the needs of telecom service providers of different sizes in any country.

2.3. Session Initiation Protocol (SIP) Support

IP Short Message Gateway (IP-SM-GW), which is in line with relevant 3GPP 23.824 specifications, acts as a bridge managing the origination and termination of SMS messages between circuit-switched and IP-based networks (over SIP). With this solution, mobile operators can make use of existing messaging platforms such as short message service centers (SMSCs) to deliver IP-based messaging. The IP-SM-GW is also essential for rolling out rich communication services (RCS), which enable operators to deliver sticky messaging services like presence-enabled address book, SIP-based chat services and mobile instant messaging.

Restcomm SMSC has support for SIP messagaing and can send short messages from SIP to SS7 or ESME and vice-a-versa. Restcomm SMSC can easily be integarted with RestComm RestComm via SIP to enable developers to rapidly build voice, video, WebRTC, USSD, SMS, fax and rich messaging applications. For more details about RestComm you may refer to, TeleStax website.

3. Architecture

Restcomm SMSC is based on robust and proven Restcomm JAIN SLEE 1.1 Server and Restcomm jSS7 Stack and provides easy integration with any third party communication protocol and platform.

Restcomm JAIN SLEE Server is a highly scalable event-driven application server with a robust component model and fault tolerant execution environment. It provides a set of connectors to a variety of networks elements: SS7 MAP, TCAP, INAP, ISUP, SMPP, XMPP, SIP, MGCP, HTTP, XDM, XCAP, Diameter and many others. It is fully compliant with JSR 240 (JSLEE 1.1).

Restcomm jSS7 is a software based implementation of the SS7 protocol. It provides implementation for Level 2 and above in the SS7 protocol Stack. Restcomm jSS7 Stack User Guide is bundled within and you can refer to the guide for more details on the Stack.

The diagram below depicts a high level design of Restcomm SMSC .

smsc application design overview

Restcomm SMSC provides 8 basic services of an SMSC as shown in the figure above. Each of these 8 services are implemented in the Gateway as a module that can be activated or deactivated based on the needs of an operator. All these services interact with the Cassandra database for storing data (messages not yet sent and an archive for sent/failed to send messages) and retreiving data for messages that are pending to be sent.

Restcomm SMSC can accept SMPP (incoming BIND) from ESMEs or can also initiate SMPP (outgoing BIND) to third party SMSC and hence itself acting as an ESME. Restcomm SMSC provides intelligent routing rules that can route SMS between various SMPP connections or between SMPP, GSM and SIP Network.

Service Modules
Mo (Mobile originated) module

Receives mobile originated SMS via MO procedure for further delivering.

Hr (Home routing) module

Receives mobile originated SMS via HR (Home routing) procedure for further delivering.

Tx SMPP module

Receives incoming SMS from ESME/third party via SMPP protocol for further delivering.

Tx SIP module

Receives incoming SMS from SIP Client and routes them for further delivering.

Tx HTTP module

Receives incoming SMS from HTTP connector and routes them for further delivering.

Mt (Mobile terminated)

Delivers SMS to mobile via MT procedure.

Rx SMPP module

Delivers SMS to external ESME/third party SMSC.

Rx SIP module

Delivers SMS to SIP Client received.

Administration
CLI

Restcomm SMSC comes with a Command Line Interface (CLI) that provides easy to use commands to manage and monitor the SS7 Stack and the SMSC Gateway.

Web Interface

Restcomm SMSC also includes an easy to use Web Interface administration tool that allows you to manage and monitor the Gateway via a convenient Web console.

Campaign Tool

In addition, future releases will also offer a Web based campaign tool to define and manage campaigns. |

3.1. Database Table Structure

Restcomm SMSC stores messages using Cassandra database. The database is used for storing:

  • unsent messages, messages successfully sent and messages that failed to be sent

  • referenses to sent messages depending on local and remote SMSC messageId

  • some service info needed for SMSC GW functionality

The Restcomm SMSC creates all database tables itself. A user have to create only an empty keyspace for them. Default keyspace name is "RestCommSMSC".

The Restcomm SMSC creates tables for every new day with the date suffixed to the names of the tables as DST_SLOT_TABLE_yyyy_mm_dd, SLOT_MESSAGES_TABLE_yyyy_mm_dd, MESSAGES_yyyy_mm_dd, MES_ID_YYYY_MM_DD and DLV_MES_ID_YYYY_MM_DD where yyyy_mm_dd is the date in that format.

Apart from the above tables created everyday, the database also comprises of three other tables namely CURRENT_SLOT_TABLE, SMPP_SMS_ROUTING_RULE_2 and SIP_SMS_ROUTING_RULE_2 created when the SMSC is started for the first time. The firts one is used for storing system-wide data and the latter two for storing the routing rules.

3.1.1. CURRENT_SLOT_TABLE

Table 1. CURRENT_SLOT_TABLE
Column Name Data Type Description

ID

INT

Acts as a primary key and is unique for each entry. The value acts as an identifier of content: 0 indicates the current due slot that the SMSC processes now and 1 indicates the last assigned messageId.

NEXT_SLOT

BIGINT

The next slot value.

3.1.2. SMPP_SMS_ROUTING_RULE_2

Table 2. SMPP_SMS_ROUTING_RULE_2
Column Name Data Type Description

ADDRESS

Text

Acts with NETWORK_ID as a primary key and is unique for each entry. Stores the address for which the messages are being routed.

NETWORK_ID

INT

Acts with ADDRESS as a primary key and is used as networkId to which a rule belongs

CLUSTER_NAME

Text

The name of the SMPP Cluster.

3.1.3. SIP_SMS_ROUTING_RULE_2

Table 3. SIP_SMS_ROUTING_RULE_2
Column Name Data Type Description

ADDRESS

Text

Acts with NETWORK_ID as a primary key and is unique for each entry. Stores the address for which the messages are being routed.

NETWORK_ID

INT

Acts with ADDRESS as a primary key and is used as networkId to which a rule belongs

CLUSTER_NAME

Text

The name of the SIP Cluster. This is not used as of now and all SMS message are routed through a single SIP stack.

3.1.4. DST_SLOT_TABLE_yyyy_mm_dd

This table contains a list of DUE_SLOT values for TARGET_ID to store the data for this day.

Table 4. DST_SLOT_TABLE_yyyy_mm_dd
Column Name Data Type Description

TARGET_ID

ASCII

Acts as a primary key and is made up of ADDR_DST_DIGITS + '_' + ADDR_DST_TON + '_' + ADDR_DST_NPI + '_' + NETWORK_ID.

DUE_SLOT

BIGINT

All new incoming messages will be added into this DUE_SLOT if it is not yet processed. If DUE_SLOT has been processed already or is absent, a new DUE_SLOT will be assigned.

3.1.5. SLOT_MESSAGES_TABLE_yyyy_mm_dd

This table stores the messages that are scheduled for delivery. The messages are not deleted after delivery.

The fields "DUE_SLOT", "TARGET_ID", "ID" together act as the primary key.

Table 5. SLOT_MESSAGES_TABLE_yyyy_mm_dd
Column Name Data Type Description

ID

UUID

Record Identifier.

TARGET_ID

ASCII

Made up of ADDR_DST_DIGITS + '_' + ADDR_DST_TON + '_' + ADDR_DST_NPI + '_' + NETWORK_ID.

NETWORK_ID

INT

NetworkId area via which a message will attemt to deliver.

ORIG_NETWORK_ID

INT

NetworkId area via which a message has come to SMSC GW.

DUE_SLOT

BIGINT

For which the messages will be loaded for delivering.

IN_SYSTEM

INT

0 - idle state, 1 - delivery in progress, 2 - delivery finished (by success or failure)

SMSC_UUID

UUID

Id of the SMSC session (from start to stop), this is needed to know which session has launched the delivery of a message.

ADDR_DST_DIGITS

ASCII

Destination address digits.

ADDR_DST_TON

INT

SMPP style TON (type of number) of destination address.

ADDR_DST_NPI

INT

SMPP style Numbering Plan Indicator of destination address.

ADDR_SRC_DIGITS

ASCII

Originating address digits.

ADDR_SRC_TON

INT

SMPP style TON (type of number) of source address.

ADDR_SRC_NPI

INT

SMPP style Numbering Plan Indicator of source address.

DUE_DELAY

INT

Duration (in seconds) after which a new delivery attempt will be done. If the SMS has just arrived in the system, this value is 0.

SM_STATUS

INT

Error Code value for the last attempt (0==no attempts yet). For more details on Error Codes please refer to Error Codes

ALERTING_SUPPORTED

BOOLEAN

The value is 'true' if SMSC was successfully registered at HLR after delivery failure. However this field is currently not being used because this demands extra database access.

MESSAGE_ID

BIGINT

A unique message ID assigned by SMSC. Max value is 10 000 000 000 (because of limitation of delivery receipts IDs), so this value may repeats in some big time. This messageId is used in SMPP protocol at the leg when a client is sending (submitting) a message to SMSC GW.

MO_MESSAGE_REF

INT

SMS TPDU Message Reference field.

ORIG_ESME_ID

TEXT

SMSC internal name of origination ESME (empty for MO, HR and HTTP messages).

ORIG_SYSTEM_ID

TEXT

SMPP systemId of origination ESME for SMPP originated messages, HTTP account name for HTTP originated messages, empty for MO, HR and SIP originated messages.

DEST_CLUSTER_NAME

TEXT

Name of cluster for destination ESME terminated massages (empty for MT messages).

DEST_ESME_ID

TEXT

SMSC internal name of destination ESME (empty for MT messages).

DEST_SYSTEM_ID

TEXT

SMPP name of destination ESME (empty for MT messages).

SUBMIT_DATE

TIMESTAMP

Time when a message was received by SMSC.

DELIVER_DATE

TIMESTAMP

Time when a message was sent from SMSC (null if message failed to deliver).

SERVICE_TYPE

TEXT

SMPP parameter (service_type) for ESME originated messages.

ESM_CLASS

INT

Indicates Message Mode (Messaging Mode==Datagram, Forward or Store and Forward mode) and Message Type (MessageType==some flags including UDH indicator).

PROTOCOL_ID

INT

Protocol Identifier SMPP parameter (TP-Protocol-Identifier files for GSM).

PRIORITY

INT

SMPP parameter (priority_flag).

REGISTERED_DELIVERY

INT

SMPP parameter (registered_delivery).

REPLACE

INT

SMPP parameter (replace_if_present_flag).

DATA_CODING

INT

data_coding scheme.

DEFAULT_MSG_ID

INT

SMPP parameter (sm_default_msg_id).

MESSAGE

BLOB

Not used now.

MESSAGE_TEXT

TEXT

Message text - text part.

MESSAGE_BIN

BLOB

Message text - UDH data part.

OPTIONAL_PARAMETERS

TEXT

TLVs.

SCHEDULE_DELIVERY_TIME

TIMESTAMP

SMPP parameter (schedule_delivery_time) - time when SMSC should start a delivery (may be null if immediate message delivery).

VALIDITY_PERIOD

TIMESTAMP

The validity period of this message. If ESME has not defined (or for MO messages) this field is filled by default SMSC settings.

IMSI

ASCII

IMSI of a mobile station (in SS7 network). This value is obtained after a successful SRI request. SRI request is executed in two cases: a) when delivering messages into SS7 network (MT procedure), b) when submitting (receiving) of a message from SS7 network b Home Routing procedure (if a request to a local HLR was made).

CORR_ID

ASCII

This field is used for keeping of correlationId value for home routing procedure (SS7 originating messages). CorrelationId value plays a role of a fake “IMSI” when remote SMSC GW sends a short message to SMSC GW. Empty for messages that come to SMSC GW not via a Home Routing procedure. This table will keep this value when StoreAndForward mode for time between storing of message and scheduling it for delivering.

NNN_DIGITS

ASCII

NetworkNodeNumber = MSC/VLR address that serves a mobile station (in SS7 network). This value is obtained after a successful SRI request. SRI request is executed in two cases: a) when delivering messages into SS7 network (MT procedure), b) when submitting (receiving) of a message from SS7 network b Home Routing procedure (if a request to a local HLR was made).

NNN_AN

INT

AddressNature for NetworkNodeNumber

NNN_NP

INT

NumberingPlan for NetworkNodeNumber

SM_TYPE

INT

0-ESME terminated, 1-MT terminated, 2-SIP terminated

DELIVERY_COUNT

INT

Delivery attempt count. (this will be==1 if a message was delivered in one go)

ORIGINATOR_SCCP_ADDRESS

ASCII

SCCP CallingPartyAddress address for SS7 originated messages (it usually contains originating MSC or SMSC address).

DELIVERY_ATTEMPT

INT

A field for future usage.

STATUS_REPORT_REQUEST

ASCII

A field for future usage.

USER_DATA

ASCII

A field for future usage.

EXTRA_DATA

ASCII

A compound field that contains XML serialized info for several auxiliary fields.

EXTRA_DATA_2

ASCII

A field for future usage.

EXTRA_DATA_3

ASCII

A field for future usage.

EXTRA_DATA_4

ASCII

A field for future usage.

3.1.6. MESSAGES_yyyy_mm_dd

This table archives the messages that have been delivered successfully or whose delivery failed.

The fields "ADDR_DST_DIGITS", "ID" together act as the primary key.

Table 6. MESSAGES_yyyy_mm_dd
Column Name Data Type Description

ID

UUID

Record Identifier.

TARGET_ID

ASCII

Made up of ADDR_DST_DIGITS + '_' + ADDR_DST_TON + '_' + ADDR_DST_NPI + '_' + NETWORK_ID.

NETWORK_ID

INT

NetworkId area via which a message has delivered (or failed in delivery).

ORIG_NETWORK_ID

INT

NetworkId area via which a message has come to SMSC GW.

DUE_SLOT

BIGINT

For which the messages will be loaded for delivering.

IN_SYSTEM

INT

Not used in this table.

SMSC_UUID

UUID

Id of the SMSC session (from start to stop), this is needed to know which session has launched the delivery of a message.

ADDR_DST_DIGITS

ASCII

Destination address digits.

ADDR_DST_TON

INT

SMPP style TON (type of number) of destination address.

ADDR_DST_NPI

INT

SMPP style Numbering Plan Indicator of destination address.

ADDR_SRC_DIGITS

ASCII

Originating address digits.

ADDR_SRC_TON

INT

SMPP style TON (type of number) of source address.

ADDR_SRC_NPI

INT

SMPP style Numbering Plan Indicator of source address.

DUE_DELAY

INT

Duration (in seconds) after which a new delivery attempt will be done - value before the last delivery attempt.

SM_STATUS

INT

Error Code value for the last attempt (0==no attempts yet). For more details on Error Codes please refer to Error Codes

ALERTING_SUPPORTED

BOOLEAN

The value is 'true' if SMSC was successfully registered at HLR after delivery failure. However this field is currently not being used because this demands extra database access.

MESSAGE_ID

BIGINT

A unique message ID assigned by SMSC. Max value is 10 000 000 000 (because of limitation of delivery receipts IDs), so this value may repeats in some big time. This messageId is used in SMPP protocol at the leg when a client is sending (submitting) a message to SMSC GW.

MO_MESSAGE_REF

INT

SMS TPDU Message Reference field.

ORIG_ESME_ID

TEXT

SMSC internal name of origination ESME (empty for MO, HR, SIP and HTTP messages).

ORIG_SYSTEM_ID

TEXT

SMPP systemId of origination ESME for SMPP originated messages, HTTP account name for HTTP originated messages, empty for MO, HR and SIP originated messages.

DEST_CLUSTER_NAME

TEXT

Name of cluster for destination ESME terminated massages (empty for MT messages).

DEST_ESME_ID

TEXT

SMSC internal name of destination ESME (empty for MT messages).

DEST_SYSTEM_ID

TEXT

SMPP name of destination ESME (empty for MT messages).

SUBMIT_DATE

TIMESTAMP

Time when a message was received by SMSC.

DELIVER_DATE

TIMESTAMP

Time when a message was sent from SMSC (null if message failed to deliver).

SERVICE_TYPE

TEXT

SMPP parameter (service_type) for ESME originated messages.

ESM_CLASS

INT

Indicates Message Mode (Messaging Mode==Datagram, Forward or Store and Forward mode) and Message Type (MessageType==some flags including UDH indicator).

PROTOCOL_ID

INT

Protocol Identifier SMPP parameter (TP-Protocol-Identifier files for GSM).

PRIORITY

INT

SMPP parameter (priority_flag).

REGISTERED_DELIVERY

INT

SMPP parameter (registered_delivery).

REPLACE

INT

SMPP parameter (replace_if_present_flag).

DATA_CODING

INT

data_coding scheme.

DEFAULT_MSG_ID

INT

SMPP parameter (sm_default_msg_id).

MESSAGE

BLOB

Not used now.

MESSAGE_TEXT

TEXT

Message text - text part.

MESSAGE_BIN

BLOB

Message text - UDH data part.

OPTIONAL_PARAMETERS

TEXT

TLVs.

SCHEDULE_DELIVERY_TIME

TIMESTAMP

SMPP parameter (schedule_delivery_time) - time when SMSC should start a delivery (may be null if immediate message delivery).

VALIDITY_PERIOD

TIMESTAMP

The validity period of this message. If ESME has not defined (or for MO messages) this field is filled by default SMSC settings.

IMSI

ASCII

IMSI of a mobile station (in SS7 network). This value is obtained after a successful SRI request. SRI request is executed in two cases: a) when delivering messages into SS7 network (MT procedure), b) when submitting (receiving) of a message from SS7 network b Home Routing procedure (if a request to a local HLR was made).

CORR_ID

ASCII

This field is used for keeping of correlationId value for home routing procedure (SS7 originating messages). CorrelationId value plays a role of a fake “IMSI” when remote SMSC GW sends a short message to SMSC GW. Empty for messages that come to SMSC GW not via a Home Routing procedure. This table will keep this value for logging purpose.

NNN_DIGITS

ASCII

NetworkNodeNumber = MSC/VLR address that serves a mobile station (in SS7 network). This value is obtained after a successful SRI request. SRI request is executed in two cases: a) when delivering messages into SS7 network (MT procedure), b) when submitting (receiving) of a message from SS7 network b Home Routing procedure (if a request to a local HLR was made).

NNN_AN

INT

AddressNature for NetworkNodeNumber

NNN_NP

INT

NumberingPlan for NetworkNodeNumber

SM_TYPE

INT

0-ESME terminated, 1-MT terminated, 2-SIP terminated

DELIVERY_COUNT

INT

Delivery attempt count. (this will be==1 if a message was delivered in one go)

ORIGINATOR_SCCP_ADDRESS

ASCII

SCCP CallingPartyAddress address for SS7 originated messages (it usually contains originating MSC or SMSC address).

DELIVERY_ATTEMPT

INT

A field for future usage.

STATUS_REPORT_REQUEST

ASCII

A field for future usage.

USER_DATA

ASCII

A field for future usage.

EXTRA_DATA

ASCII

A compound field that contains XML serialized info for several auxiliary fields.

EXTRA_DATA_2

ASCII

A field for future usage.

EXTRA_DATA_3

ASCII

A field for future usage.

EXTRA_DATA_4

ASCII

A field for future usage.

3.1.7. MES_ID_YYYY_MM_DD

This table contains referenses of local messageIds to a primary keys of MESSAGES_YYYY_MM_DD tables for a possibility of finding of sent / delivery failed messages by thier messageId value.

The field "MESSAGE_ID" acts as the primary key.

Table 7. MES_ID_YYYY_MM_DD
Column Name Data Type Description

MESSAGE_ID

BIGINT

A unique message ID assigned by SMSC. Max value is 10 000 000 000 (because of limitation of delivery receipts IDs), so this value may repeats in some big time.

ADDR_DST_DIGITS

ASCII

Destination address digits.

ID

UUID

Record Identifier.

3.1.8. DLV_MES_ID_YYYY_MM_DD

This table contains referenses of remote messageIds (that are assigned by a remote SMSC GW to which a message was sent via SMPP protocol) to a local messageIds for sent to SMPP detination messages to corralate them.

The fields "REMOTE_MESSAGE_ID", "DEST_ID" together act as the primary key.

Table 8. DLV_MES_ID_YYYY_MM_DD
Column Name Data Type Description

REMOTE_MESSAGE_ID

ASCII

A unique message ID assigned by a remote SMSC.

DEST_ID

ASCII

Cluster name of ESME via which a message has gone.

MESSAGE_ID

BIGINT

A unique message ID assigned by local SMSC.

3.1.9. Reporting

As of now there is no reporting in Restcomm SMSC . However you can leverage any external third party tool to dig Cassandra tables as defined above and create reports. The next release of Restcomm SMSC will feature a reporting section and also the flexibility to search for a specific SMS based on various search criteria.

4. Running

4.1. Running the Gateway

Procedure: Run Restcomm SMSC
  1. Pre-requisite:

    • You must have Restcomm SMSC installed as explained in the Installation Guide.

    • If you are using the SS7 board on server, you must ensure that the java.library.path variable is set to point to the directory containing the native component. Alternatively you can copy it to the JBoss native library path manually.

    • You must have Cassandra database running and configured as explained in the Installation Guide.

    • You must have the Cassandra Keyspace created as explained in the Installation Guide.

  2. All you have to do to start the Gateway is start the JBoss Application Server. To start the JBoss Server you must execute the run.sh (Unix) or run.bat (Microsoft Windows) startup script in the restcomm-smscgateway-<version>/jboss-5.1.0.GA/bin folder (on Unix or Windows). Note that this will start the server in the default profile. The "default" profile is a clean profile where you will have to start from scratch and configure the entire SS7 Stack and SMSC Gateway.

  3. Result: If the service started properly you should see the following last few output lines in the Unix terminal or Command Prompt depending on your environment:

    2013-07-22 17:41:48,817 INFO [org.mobicents.slee.container.management.ResourceManagement] (pool-27-thread-1) Created Resource Adaptor Entity SmppServerRA for ResourceAdaptorID[name=SMPPServerResourceAdaptor,vendor=org.mobicents,version=1.0] Config Properties: []
    2013-07-22 17:41:49,067 INFO [org.mobicents.slee.container.management.ResourceManagement] (pool-27-thread-1) Activated RA Entity SmppServerRA 2013-07-22 17:41:49,317 INFO [org.mobicents.slee.container.management.ResourceManagement] (pool-27-thread-1) Bound link between RA Entity SmppServerRA and Name SmppServerRA
    2013-07-22 17:41:49,615 INFO [javax.slee.RAEntityNotification[entity=SchedulerResourceAdaptor].SchedulerResourceAdaptor] (pool-27-thread-1) Verify configuration in RA Entity SchedulerResourceAdaptor
    2013-07-22 17:41:49,616 INFO [org.mobicents.slee.container.management.ResourceManagement] (pool-27-thread-1) Created Resource Adaptor Entity SchedulerResourceAdaptor for ResourceAdaptorID[name=SchedulerResourceAdaptor,vendor=org.mobicents,version=1.0] Config Properties: []
    2013-07-22 17:41:49,866 INFO [org.mobicents.slee.container.management.ResourceManagement] (pool-27-thread-1) Activated RA Entity SchedulerResourceAdaptor
    .
    .
    .
    2013-07-22 17:41:51,122 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installing DeployableUnitID[url=file:/C:/JavaT/jboss/server/default/deploy/smsc-services-du-6.1.2-{this-folder}-SNAPSHOT.jar/]
    2013-07-22 17:41:52,307 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installed LibraryID[name=org.mobicents.smsc,vendor=smsc-library,version=1.0]
    2013-07-22 17:41:52,349 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installed SbbID[name=AlertSbb,vendor=org.mobicents,version=1.0]
    2013-07-22 17:41:52,408 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installed SbbID[name=RxSmppServerSbb,vendor=org.mobicents,version=1.0]
    2013-07-22 17:41:52,618 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installed SbbID[name=SriSbb,vendor=org.mobicents,version=1.0]
    .
    .
    .
    2013-07-22 17:41:53,290 INFO [org.mobicents.slee.container.management.jmx.DeploymentMBeanImpl] (pool-27-thread-1) Installed DeployableUnitID[url=file:/C:/JavaT/jboss/server/default/deploy/smsc-services-du-6.1.2-{this-folder}-SNAPSHOT.jar/]
    2013-07-22 17:41:53,543 INFO [org.mobicents.slee.container.management.ServiceManagementImpl] (pool-27-thread-1) Activated ServiceID[name=MoService,vendor=org.mobicents,version=1.0]
    .
    .
    .
     2013-07-22 17:41:54,974 INFO [me.prettyprint.cassandra.connection.CassandraHostRetryService] (Thread-27) Downed Host Retry service started with queue size -1 and retry delay 10s
    2013-07-22 17:41:55,004 INFO [me.prettyprint.cassandra.service.JmxMonitor] (Thread-27) Registering JMX me.prettyprint.cassandra.service_RestCommSMSC:ServiceType=hector,MonitorType=hector
    2013-07-22 17:41:55,014 INFO [javax.slee.RAEntityNotification[entity=SchedulerResourceAdaptor].SchedulerResourceAdaptor] (Thread-27) Scheduler IS up, starting fetch tasks
    2013-07-22 17:41:55,019 INFO [org.mobicents.smsc.smpp.SmscManagement] (main) SMSC configuration file path C:\JavaT\jboss\server\default\data\SmscManagement_smsc.xml
    2013-07-22 17:41:55,022 INFO [org.mobicents.smsc.smpp.SmppServerManagement] (main) Loading SMPP Server Properties from C:\JavaT\jboss\server\default\data\SmscManagement_smppserver.xml
    2013-07-22 17:41:55,297 INFO [org.mobicents.smsc.smpp.SmppServerManagement] (main) Starting SMPP server...
    2013-07-22 17:41:55,322 INFO [com.cloudhopper.smpp.impl.DefaultSmppServer] (main) SmscManagement started on SMPP port [2776]
    2013-07-22 17:41:55,322 INFO [org.mobicents.smsc.smpp.SmppServerManagement] (main) SMPP server started
    2013-07-22 17:41:55,378 INFO [org.mobicents.smsc.smpp.SmppClientOpsThread] (Thread-30) SmppClientOpsThread started.
    2013-07-22 17:41:55,379 INFO [org.mobicents.smsc.smpp.SmscManagement] (main) Started SmscManagement
    2013-07-22 17:41:55,379 INFO [javax.slee.RAEntityNotification[entity=SmppServerRA].SmppServerResourceAdaptor] (main) Activated RA Entity SmppServerRA
    2013-07-22 17:42:00,652 INFO [org.apache.coyote.http11.Http11Protocol] (main) Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
    2013-07-22 17:42:00,674 INFO [org.apache.coyote.ajp.AjpProtocol] (main) Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
    2013-07-22 17:42:00,689 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] (main) JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:45s:372ms
  4. If you are starting Restcomm SMSC for the first time, SS7 and SMSC working parameters (and possibly database access) are not configured. You need to use the Shell Client or the GUI to connect to the Gateway and configure the SS7 Stack and SMSC. Once configured, the state and configuration is persisted which stands server re-start. The next chapter will discuss in detail about configuration.

Procedure: Bind the SMSC Gateway to a specific IP

Using run.sh without any arguments binds the SMSC Gateway to localhost 127.0.0.1. To bind the Gateway to a different IP, pass the IP address as value to the -b command line option. For example to bind the SMSC to 10.199.7.23 you will use the command from the bin folder as below:

[vsmsc bin]$ ./run.sh -b 10.199.7.23
Procedure: Stop the Gateway
  1. To stop the Restcomm SMSC , you must shut down the JBoss Application Server. To shut down the server(s) you must execute the shutdown.sh -s (Unix) or shutdown.bat -s (Microsoft Windows) script in the restcomm-smscgateway-<version>/jboss-5.1.0.GA/bin directory (on Unix or Windows).

  2. If the server stopped properly, you will see the following three lines as the last output in the Unix terminal or Command Prompt:

    [Server] Shutdown complete
    Halting VM

4.2. Running the Gateway - Simulator Profile

The Restcomm SMSC offers you an option to run the Gateway with a "simulator" profile for testing purpose. The "simulator" profile is a pre-configured profile to work with the jss7-simulator, the smpp-simulator, some SIP phone and loading of messages via a HTTP connector. Starting the Gateway with the "simulator" profile is similar to the steps explained for the "default" profile except that you must pass the string value "simulator" to the -c command line option when invoking the run script.

[bin]$ ./run.sh -c simulator

By default, the SMSC Simulator profile is configured for use in Linux systems. For using it under Microsoft Windows you need to open the file restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/simulator/data/SCTPManagement_sctp.xml and replace (in two places) ipChannelType="0" to ipChannelType="1" for using a TCP connection instead of SCTP (SCTP is not supported under Windows).

4.2.1. Configuring the Gateway in Simulator Profile

The SMSC Gateway in a Simulator Profile is configured as it would have been if configured with the following CLI commands:

sctp server create serv1 127.0.0.1 8012 sockettype TCP
sctp server start serv1
sctp association create ass1 SERVER serv1 127.0.0.1 8011 sockettype TCP

m3ua as create as1 IPSP mode SE ipspType server rc 101 traffic-mode loadsharing network-appearance 102
m3ua asp create asp1 ass1
m3ua as add as1 asp1
m3ua asp start asp1
m3ua route add as1 1 2 3

sccp sap create 1 1 2 2
sccp dest create 1 1 1 1 0 255 255
sccp address create 1 82 1 8 0 1 4 000
sccp address create 2 82 2 8 0 1 4 000
sccp rule create 1 K 82 0 0 0 1 4 * solitary 1 origination-type localOriginated
sccp rule create 2 K 82 0 0 0 1 4 * solitary 2 origination-type remoteOriginated
sccp rsp create 1 1 0 0
sccp rss create 1 1 8 0

smsc set scgt 22220
smsc set scssn 8
smsc set hlrssn 8
smsc set mscssn 8
smsc set maxmapv 3

smsc set httpdefaultnetworkid 10
smsc httpuser add user password password networkId 10

smpp esme create test test 127.0.0.1 -1 TRANSCEIVER SERVER password test esme-ton -1 esme-npi -1 esme-range 6666 source-range ^[0-9a-zA-Z]* routing-range ^[0-9a-zA-Z]* networkid 20
smpp esme create test2 test2 127.0.0.1 -1 TRANSCEIVER SERVER password test esme-ton -1 esme-npi -1 esme-range 6667 source-range ^[0-9a-zA-Z]* routing-range ^[0-9a-zA-Z]* networkid 21
smpp esme start test
smpp esme start test2

smsc sip modify SIP cluster-name SIP host 127.0.0.1 port 5065 routing-ton 1 routingnpi 1 routing-range ^[0-9a-zA-Z]* counters-enabled false charging-enabled false networkid 30

smsc mproc add mproc 1 destdigmask 6666 newnetworkid 20
smsc mproc add mproc 2 destdigmask 6667 newnetworkid 21
smsc mproc add mproc 3 destdigmask 5555 newnetworkid 30
smsc mproc add mproc 4 destdigmask ^(?!6666|6667|5555).* newnetworkid 0

We use following message Id values:

Table 9. The list of Id values
Network Id value Connector

0

SS7

10

HTTP

20, 21

SMPP

30

SIP

4.2.2. Running the jSS7 Simulator

If you are not familiar with the Restcomm jss7 Simulator, you can find instructions about using the jss7-simulator in the Restcomm jSS7 User Guide. You will also find example test cases explained in detail in the jSS7 User Guide.

Procedure: Running Restcomm jSS7 Simulator
  1. Change the working directory to the bin folder in the Simulator’s installation directory.

    [vinu@vinu-neha ~]$ cd {this-folder}-smsc-<version>/tools/{this-folder}-ss7-simulator/bin
  2. Ensure that the run.sh start script is executable.

    bin$ chmod +x run.sh
  3. Execute the run.sh. Bourne shell script with the command ./run.sh gui or in the case of Windows ./run.bat gui.

    bin$ ./run.sh gui

    This will launch the Simulator GUI Application.

  4. When the GUI shows up, select "main" (default) as host name [or type "win" as host name under Windows] and press the 'Start' button. The Simulator is already pre-configured to connect to the SMSC Gateway (running in simulator profile). Press 'Run test' and again click on 'Start' in the next screen. The Simulator will connect to SMSC (via m3ua protocol).

  5. The Low level part is configured to SCTP (not TCP) protocol and hence you can test the SMSC in a Linux environment. To test under Windows OS, you must change the SS7 simulator settings to TCP. The SS7 Simulator will play both HLR and MSC roles and respond to SendRoutingInfo and ForwardSM requests from SMSC gateways.

  6. You can configure the SMS_TEST_CLIENT testing task to play with different modes including return error responses to SMSC and bulk mode without adding information for any event to an application form. You can also play with different data coding schemes and MAP protocol versions.

4.2.3. Running the SMPP Simulator

Procedure: Running SMPP Simulator
  1. Change the working directory to the bin folder for the SMPP Simulator.

    [vinu@vinu-neha ~]$ cd {this-folder}-smsc-<version>/tools/{this-folder}-smpp-simulator/bin
  2. Ensure that the run.sh start script is executable.

    bin$ chmod +x run.sh
  3. Execute the run.sh. Bourne shell script with the command ./run.sh or in the case of Windows ./run.bat.

    bin$ ./run.sh

    This will launch the SMPP Simulator GUI Application.

  4. The SMPP Simulator default settings fit to connect to the SMSC Gateway (running in simulator profile). You can in this case just press 'Run test' and then press on 'Start Session' to connect to the SMSC Gateway.

  5. Using the button 'Configuring data for message submitting', you can configure different sending modes, data coding schemas, origination and destination addresses. See chapter SMPP Simulator Tool to understand more of SMPP simulator usage.

  6. When the SMSC Gateway is running in a "simulator" profile it works with SMPP as ESME with the address "6666" (TON=1, NPI=1). So all messages with the destination address "6666" (TON=1, NPI=1) will be routed to SMPP Simulator. All other messages will be routed to SS7 Simulator (except messages for "5555" address that will be routed to SIP).

    With the SMPP Simulator you can also simulate a bulk message delivery to SMSC . This may be random bulk messages and bulk messages obtained from a pcap file.

4.2.4. Running the HLR Simulator

You can use the Command line HLR Simulator for load testing the SMSC . restcomm-hlr-simulator is pre-configured to integrate with SMSC run in simulator profile. The HLR Simulator receives the MAP SRI request from SMSC and returns response with random VLR and IMSI. SMSC will then forward MT_Forward_SM request to HLR. For every 7th MT_Forward_SM request, the HLR Simulator will return an AbsentSubscriber error.

For every 400 messages processed by the HLR Simulator, it shows the below message (time in milli seconds)

				Received 400 MAP Dialog requests in 1000
Procedure: Running HLR Simulator
  1. Change the working directory to the bin folder for the HLR Simulator.

    [vinu@vinu-neha ~]$ cd {this-folder}-smsc-<version>/tools/{this-folder}-hlr-simulator/bin
  2. Ensure that the run.sh start script is executable.

    bin$ chmod +x run.sh
  3. Execute the run.sh

    bin$ ./run.sh

    This will launch the HLR Simulator ready for processing SRI and MT_Forward_SM requests

  4. The HLR Simulator is already pre-configured to connect to the SMSC Gateway (running in simulator profile).

Additional configuring of the HLR Simulator is possible only by manually updating the configuration files in the restcomm-hlr-simulator/data folder. For example, in order to run the HLR Simulator in Microsoft Windows you need to update the file SCTPManagement_sctp.xml and set the parameter ipChannelType to "1".

4.2.5. Running the SMPP Load tool

The smpp-load tool is a Command line simulator to generate SMPP load. You must have ant installed to be able to run this tool. The smpp-load tool can be started as a SMPP Server accepting in-coming connection (BIND) from Restcomm SMSC or can be started as a SMPP Client to send BIND to Restcomm SMSC . You can modify the configuration parameters in the build.xml to define how many SMPP connections should be initiated, what kind of load should be generated, etc.

Procedure: Running SMPP Load Tool
  1. Change the working directory to the bin folder for the SMPP Load Tool.

    [vinu@vinu-neha ~]$ cd {this-folder}-smsc-<version>/tools/{this-folder}-smpp-simulator/bin
  2. Execute the ant client command to start the SMPP load tool as a client or execute the ant server command to start the SMPP load tool as a SMPP Server.

    ant client

    This will launch the SMPP load tool as a SMPP Client.

    ant server

    This will launch the SMPP load tool as a SMPP Server.

  3. The SMPP load client is already pre-configured to connect to the Restcomm SMSC (running in simulator profile).

4.2.6. Running Jitsi or Linphone SIP phones

In order to test SMSC features for interconnection with SIP servers, you can use Jisti or Linphone SIP phones that can play the role of a SIP server.

Procedure: Configure Jitsi
  1. Download Jisti from the website and run it.

  2. Create a registrarless account (do not provide password, registrar and proxy address), enable PRESENSE (SIMPLE) at the forth tab for this account (Advanced). Identifier of this account must be "5555" because SMSC is configured to route all messages for subscriber "5555" to SIP.

  3. In the menu, go to Tools → Options → Security → Chat, and enable all three options at the end.

  4. Then go to Tools → Options → Advanced → SIP and define SIP port as "5065" (SMSC is configured for sending outgoing SIP messages to this port).

  5. In the menu, go to File → Add contact and add a new contact with definition to which subscriber you will send messages to. SMSC is configured such that all messages for "6666" will be routed to ESME (SMPP simulator) and others (except "5555" that is for SIP) to GSM network (to SS7 Simulator). Therefore you can add two new contacts as below:

    • for SS7 Simulator: "sip:1111@127.0.0.1:5060"

    • for SMPP Simulator: "sip:6666@127.0.0.1:5060"

      The SMSC listens to 5060 port for incoming SIP messages. For addressing to/from the SS7 Simulator, the address "1111" will be used.

Procedure: Configure Linphone
  1. Download Linphone from the website and run it.

  2. Go to Parameters → Network settings → Network protocols and ports → SIP UDP port and set the port to 5066.

  3. Add a contact with SIP address: "sip:6666@127.0.0.1:5060" for message exchange with SMPP simulator.

  4. Add a contact with SIP address: "sip:1111@127.0.0.1:5060" for message exchange with SS7 simulator.

Now you can run the following tests:

  1. For testing sending messages from a SIP phone you can use the feature "Send message" to a concrete contact, type a message text and send. After about 1 minute you will receive the message on the SS7 Simulator or the SIP Simulator.

  2. For testing sending messages to the SIP phone you just need to send a message from the SS7 Simulator or SMPP Simulator to the address "5555". You must put the originating address as "1111" for SS7 Simulator and "6666" for SMPP Simulator.

4.2.7. Usage of a HTTP connector for message uploading

SMSC GW with a "simulator" profile is configured for accepting messages via HTTP connector with a preconfigured user name "user" and a password "password". Examples for sending of messages by a WEB browser are:

127.0.0.1:8080/restcomm/sendSms?userid=user&password=password&msg=Thisisamessage_00001&sender=4444&to=6666
127.0.0.1:8080/restcomm/sendSms?userid=user&password=password&msg=Thisisamessage_00002&sender=4444&to=1111

These examples send messages "Thisisamessage_00001" and "Thisisamessage_00002" to destination addresses "6666" (for delivering into SMPP Simulator) and "1111" (for delivering into SS7 Simulator).

4.3. Running the Shell

You must start the Shell client and connect to the managed instance prior to executing commands to configure the Gateway. Shell can be started by issuing the following command from restcomm-smscgateway-<version>/jboss-5.1.0.GA/bin directory:

[$] ./ss7-cli.sh

Once console starts, it will print following information and await further commands:

version=6.2.8.493,name={this-platform} CLI,prefix={this-folder},vendor=TeleStax
{this-folder}>

Before issuing further commands you must connect to a managed instance. For more details on connecting to an instance and for a list of all supported commands and details on configuring the SS7 stack refer to the Restcomm SS7 Stack User Guide.

4.4. Running the Graphical User Interface

Open a Web Browser and navigate to http://IP:8080/restcomm-management/ (where IP is the IP Address to which the SMSC is bound to). This will launch the Restcomm GUI Management Console which is horizontally segregated into multiple tabs, one tab for each product in the Restcomm Suite. You will notice that only the tabs of products whose binaries are installed already will be shown enabled and active in the GUI. If you have successfully installed the Restcomm SMSC you will find the tabs for JAIN-SLEE, JMX, SS7 and SMSC GW active and enabled. For more details on using the GUI for SS7 or JAIN-SLEE please refer to their respective user guides. This document only provides instructions for using the GUI to configure the SMSC Gateway.

Some versions do not have an integrated console. In this case you can use separate GUI consoles for configuring:

Switch to the SMSC GW tab and you will find that the window will look similar to the figure below. The GUI is divided into three sections:

  • A left panel listing the management and monitoring units (Server Settings, SMPP Server, ESMEs, SIPs, MAP Version Cache, DB Routing Rules). You can click on any of these to select and navigate to the specific management unit.

  • A main panel displaying the currently selected management unit. The main view is categorized into multiple tabs to manage different aspects of the selected layer.

  • A bottom panel displaying the log data. You can clear the log anytime by clicking on the trash icon at the top right corner of this panel. You can also minimize or maximize this panel to suit your needs.

GUI SMSC GW main
Figure 1. GUI - Restcomm SMSC

4.4.1. Connect to a new Instance

You can connect to a new instance by entering the IP:Port values and the login credentials in the top left corner of the GUI. However please note that this feature is not available in this release but will be fully functional in the next release.

4.4.2. Authentication

Restcomm SMSC GUI Management Security is based on the JBoss Security Framework. To read more on JBoss Security Framework refer JBoss Installation Guide here

Deafult user-id and password for GUI Management Console is admin and admin. You can change the user-id and password in files jmx-console-roles.properties and jmx-console-users.properties located at restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/conf/props/

5. Configuring

You must fine-tune Memory and Database settings for better performance before using Restcomm SMSC in production. Once you complete setting up the Gateway you must configure the SS7 Stack the SMSC Gateway following the instructions specified in this guide.

5.1. Memory Settings and fine tuning

5.1.1. Memory Settings

You should fine tune the JVM memory settings based on your needs but we recommend you allocate a minimum of 3 GB for initial and maximum heap size. 4 GB is recommended. These settings are specified in the file restcomm-smscgateway-version>/jboss-5.1.0.GA/bin/run.conf.

-Xms3072m

Initial heap size, set in megabytes

-Xmx3072m

Maximum heap size, set in megabytes

5.1.2. Message flow types

We have two possible message flow type.

  1. When a message is firstly stored into a cassandra database - StoreAndForward mode (StoreAndForward messages when Store And Forward Mode is set to "normal")

  2. When a first delivery retry is done without storing a message into a cassandra database - datagramm, Transactional, ForwardAndStore (StoreAndForward messages when Store And Forward Mode is set to "fast").

If you have some high traffic load you can try scenario "1". In this case when a message highload peaks cassandra will store messages before delivering and all incoming messages will be accepted (but this may lead some delay before the first delivery attempt). In scenario "2" if there are many messages in processing then some incoming messages will rejected by SMSC GW with "STATUS_THROTTLED" cause (for SMPP case). And SMPP application must be ready to resend such rejected messages later. If SMPP applications can not do so, then it is better to use "1" scenario.

5.1.3. SMSC configuration parameters which influence the traffic throughput

Firstly we need to check Fetch Period (in ms), Max Rows and Max Activity Count chapters. "Max Activity Count" parameter specifies how many messages will be processed at the same time. If you have high productivity server then you can try to increase it. But be carefull - if you increase it too high then it leads the productivity reducing because of SMSC GW will not be able to process all together.

For monitoring you can use View SMSC Statistics chapter. DueSlotProcessingLag output said if SMSC GW is overloaded (you will see that this parameter be encrased permanemtly in this case).

In the configuration of SCTP layer leave the parameter "SingleThread" as "true". The count of threads that will process incoming SS7 messages is specified by a parameter "deliveryMessageThreadCount". We need to do it if we have some bottleneck in SS7 part.

  • open file jboss/server/default/deploy/telscale-smsc-server/META-INF/jboss-beans.xml in the text editor

  • find "bean name="Mtp3UserPart"" mbean definition

  • update parameter "deliveryMessageThreadCount" to some value like "processor count * 2"

SMPP side also has important parameters "DefaultWindowSize" and "WindowSize" for SMPP Server and ESMEs, you can increase it if you see that you have bottleneck at SMPP side but SMSC GW generally is not overloaded. See SMPP Server Settings.

We need to add info of cassandra database parameters update for high loaded systems (in the file cassandra.yaml):

  • tombstone_warn_threshold: 1000 → 5000 (in case of warning like "Read 386 live and 1496 tombstoned cells in system.schema_columns (see tombstone_warn_threshold).")

  • read_request_timeout_in_ms 5000 → 25000 (or twice more to prevent timeouts in case when we have very many paending message to one destination)

  • range_request_timeout_in_ms 10000 → 50000 (same)

  • request_timeout_in_ms 10000 → 50000 (same)

5.2. Starting of the SMSC GW process

We can use "screen" linux command to run jboss processes at background.

As a command how to check if SMSC GW instanse is run we can use: ps -ef | grep jboss

If we run several instanses of the same server (by mistake) the second instanse will have records in the logs like "BindException: Address already in use". We need to terminate all such servers and run only one instanse again.

5.3. Configuring log4j Logging Service

Restcomm SMSC uses Apache log4j for logging. If you are not familiar with the log4j package, you can read more about it at the Jakarta website.

Logging is controlled from a central configuration file located at [path]restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/conf/jboss-log4j.xml_, one for each JBoss AS configuration profile. This file defines a set of appenders specifying the log files, what categories of messages should go there, the message format and the level of filtering. For more details, please refer to Section 9.6.3, "Logging Service" in the JBoss AS Getting Started Guide available here.

You must make sure log4j is fine tuned for optimal performance in production. We recommend that you set logging threshold to WARN and let the CDR appender be DEBUG.

5.4. SMSC GW routing fundamentals

SMSC GW needs clear info to where it must route messages that have come to SMSC GW from SMPP / SS7 / SIP / HTTP connectors or created inside SMSC GW receipts. Routing procedures gives the answer to this questions, that a user must configure before SMSC GW can properly work.

SMSC GW has two routing procedures:

  • The procedure based on dividing of separated routing area into several areas ("subnetworks") and routing of messages between subnetworks.

  • The procedure of routing messages to destinations inside subnetworks.

5.4.1. The procedure based on dividing of separated routing area into several areas ("subnetworks").

Each area has its unique digital "networkId" value. Each SMPP connection (ESME), SS7 SCCP service access point (SAP), SIP connector and a database routing rule (if you use them instead of default ESME routing rules) belongs to one of network (to each of the a networkId value is assigned). For messages that come via HTTP connector a networkId is assigned depending on a value in HTTP payload or with a default configured value. Default networkId value is "0". If a user does not specify a networkId value when ESME, SAP, SIP or a database routing rule creation, networkId=0 will be assigned.

When a message has come to SMSC GW a networkId value from ESME, SAP, SIP or HTTP is assigned for the message. The message can be routed only inside the area with the same networkId to what the message belongs. So this means that by default a message can not leave a "networkId" area via which it has come to SMSC GW.

If a user needs that a message will be delivered to another "networkId" area, he can configure "message processing" rules ("mproc" rules). There we can configure that a message from a specified networkId1 and which fits some other conditions (like destination address fit to some mask) must be routed to networkId2 (newNetworkId action of a mproc rule). And the message will be delivered via ESME, SAP or SIP that belongs to networkId2. newNetworkId action in a mproc rule is applied at the step when a message has just come to SMSC GW for processing. There are also other options. A messages can be rerouted to another networkId (or dropped) just before a delivery attempt, after a successfull SRI request to HLR, after temporary or permanent failure.

Multi-tenancy support is also based on this routing procedure. For each networkId we can configure a separate SS7 GlobalTitle and for an external peer each networkId can play a role as a separate independed SMSC.

NetworkId for a generated inside SMSC receipts and SMS-STATUS-REPORTs is assigned by two algoritms:

  • if the option "Delivery receipts will be routed to the origination networkId" is set to true - networkId from ESME/SIP/SAP via what an original message has come SMSC GW will be assigned

  • if the option "Delivery receipts will be routed to the origination networkId" is set to false - networkId from ESME/SIP/SAP via what an original message has left to SMSC GW will be assigned

Please take into account that mproc rules in Arrival trigger (actions like newnetworkid) do not affect receipts and SMS-STATUS-REPORTs. This may be used for do not pay attention for receipt routing and concentrate for routing of original messages.

NetworkId are specified at different places:

For configuring of mproc rules - see chapters Message processing rules (mproc rules) and Message processing rules (mproc rules).

For configuring of option "Delivery receipts will be routed to the origination networkId" - see the chapter Routing of delivery receipts.

For configuring of SMSC Global Titles - see chapters SMSC Gateway Global Title.

5.4.2. The procedure of routing messages to destinations inside subnetworks.

Inside each subnetwork there may be several ESME, SAP or SIP configured. If we use default routing rules, then for routing SMSC GW makes following steps:

  • it checks all ESMEs / ESME clustes that belong to the networkId. It checks if TON, NPI and AddressRange of an ESME / cluster Routing Address fit to a message destination TON, NPI and address digits the the message will be routed to this ESME. Several ESMEs inside a single networkId area can be grouped in a cluster. There is one exception of this rule. A message will not be routed in any case to the ESME from which it has come.

  • if no ESME found for routing SMSC GW then checks SIP connector if it’s settings (TON, NPI and routing AddressRange) fits to a message destination TON, NPI and address digits. If yes the message will be routed to SIP

  • if SIP also does not fit, a message will be routed to SS7 network. Then routing rules at SCCP level will be taken into account for further routing.

ESMEs (inside a networkId area) can be grouped in a cluster (by setting of a parameter "cluster-name" to the same for all ESMEs). "routing-range" must be the same for all ESMEs in a cluster. When routing procedure SMSC GW firstly select a cluster (based on "routing-range" value). Then SMSC GW selects an ESME inside a cluster in a round robin fashion (only those ESMEs are taken into account that are connected). This allow make load sharing across ESMEs inside a cluster (and use an ESME cluster for loadsharing between destinations).

For configuring of ESME and SIP routing parameters see External Short Messaging Entities (ESMEs) and SIP Settings.

Instead of default routing rules database routing rules can be used. This is a set of stored in the cassandra database rules that describes where SMSC GW will route a message (to some ESME / SIP) depending on a message destination address. Messages that fit to no rules will be routed to SS7 network. For configuring of database routing rules see the chapter Message processing rules (mproc rules)| |

5.4.3. Using of different routing procedures.

You can use only the procedure based on subnetworks (networkId) areas, only the procedure of routing messages inside subnetworks or both.

If you want to use only the procedure based on subnetworks (networkId) areas you need:

  • configure SMSC GW so that only one SAP / ESME / SIP belongs to each networkId.

  • for every ESME / SIP specify for "Routing Type of number (TON)"=-1, "Routing Number plan indicator (NPI)"=-1, "Routing Range"="^[0-9a-zA-Z]*" (that fits to any message destination address).

  • configure a set of mproc rules that will manage of routing of messages from one subnetwork (networkId) to another.

If you want to use only the procedure based on subnetworks (networkId) areas you need:

  • configured for all SAP / SCCP routing rules / ESME / SIP the same networkId (default networkId=0 is usually used)

  • for every ESME / SIP specify proper values for "Routing Type of number (TON)", "Routing Number plan indicator (NPI)" and "Routing Range" or configure database routing rules

  • you do not need to configure mproc rules for routing

If you want to use both, you need to configure both parts. Messages will be routed between subnetworks (networkIds) by mproc rules and inside a subnetwork (networkId) by configuring of ESME / SIP "Routing Type of number (TON)", "Routing Number plan indicator (NPI)" and "Routing Range" (or database routing rules).

5.4.4. Routing model examples.

5.4.4.1. Routing all messages from one ESME to SS7

If you have one ESME and JSS7 connector, and the only traffic is ESME → JSS7

  • use networkId=0 for all

  • configure "Routing Range" value of the ESME to a value that fits to no mobile subscriber (for example "0")

5.4.4.2. All JSS7 originated messages must be routed to ESME and all ESME originated messages must be routed to JSS7

If you use the model "all JSS7 originated messages must be routed to ESME and all ESME originated messages must be routed to JSS7", you can:

  • set networkId=0 for JSS7 and networkId=1 for ESME

  • set ESME routing address so it accepts all messages

  • set mproc rules:

    smsc mproc add mproc 1 networkidmask=1 newnetworkid=0

    smsc mproc add mproc 2 networkidmask=0 newnetworkid=1

5.4.4.3. Several ESMEs send message to one SS7 connection and delivery receipts come back to an originator ESME

If you have several ESMEs that send message to one SS7 connection and you need that delivery receipts come back to an originator ESME (and no more traffic), you can:

  • put SS7 SAP / SCCP rules to networkId=0

  • put each ESME to each own networkId (1,2,3)

  • create a set of mproc rules that move ESME originated messages into SS7 network. CLI commabd can be like:

    smsc mproc add mproc 1 networkidmask=1 newnetworkid=0

    smsc mproc add mproc 2 networkidmask=2 newnetworkid=0

    smsc mproc add mproc 3 networkidmask=3 newnetworkid=0

  • set the option "Delivery receipts will be routed to the origination networkId" is set to true

5.4.4.4. Routing desision based on SRI request results

Sometimes we need to decide where to route messages depending on SendRoutingRequest (SRI) to HLR results. To achieve it we may use two approaches

  • dropaftersri - performing of "SRI request only" functionality, get SRI response data and then resend a message again to a proper destination (or avoid of sending if for exammple a subscriber is in roaming).

  • newnetworkidaftersri - rerouting of a message after SRI response (to another networkID area)

dropaftersri procedure

One of a solution is to use a separate ESME(s) that will send messages only for SRI requests only. We can configure an mproc rule like this:

smsc mproc add 1 origesmenamemask XXX dropaftersri true

In this case all messages that fit to the mproc rules conditions (in this example == all messages that have come from ESME with name "XXX") will be dropped after a SRI request without futher message sending ("dropaftersri true" says for it). A condition can be any of possible (not exactly "origesmenamemask XXX"), this condition is good if you want to send all messages for SRI request only via a dedicated for this purpose ESME.

We can then get SRI response results by one of the following ways (pay attention that it may be also a MAP error response from HLR):

  • CDR will contain extra fields for IMSI / VLR (if the response is successfull)

  • you can request a delivery receipt that will be routed back to your ESME and this receipt will contain also extra fields (IMSI / VLR).

If SRI returns MAP error message (or some other error response) then MProcRule.onPostImsiRequest() and "dropaftersri" action will not be invoked and the behavior is the same for other messages that delivery failed. It may be also several attempts to send SRI requests in case of temporary errors (for StoreAndForward mode only of cause).

Delivery response for such dropped after SRI requests messages will contain in the message text (at the end) extra fields with varaible length: imsi, nnn_digits, nnn_an (address nature), nnn_np (numbering plan) with filled values from a SRI response. The example of this string is: imsi:00000000000000 nnn_digits:0000000000 nnn_an: nnn_np:11. SMPP error code for such cases is: 226.

CDR records will contain "failed_imsi" operation result cause and also conatins IMSI and NNN values.

newnetworkidaftersri procedure

We can add mproc rules like

smsc mproc add 1 imsidigitsmask <regular expression> newnetworkidaftersri 22

This rule will reroute a message to networkId==22 area for further delivering if IMSI from a SRI response matches the mask. You can use also other conditions here for proper filtering (networkidmask, destdigmask, nnndigitsmask, etc). If in the new networkId area a message will be delivered again to SS7 network then a new SRI will be performed.

5.4.5. Temporary and permanent failure reasons.

  • Permanent error reasons:

    • Internal System failures

    • Bad destination address

    • MT: ProviderDialogAbort, UserDialogAbort

    • MT: RejectComponent / Dialog

    • MT: Failure of MAP protocol ACN / version negotiation

    • MT: SMDeliveryFailure MAP error message with causes except of "memoryCapacityExceeded" and "equipmentProtocolError"

    • MT: MAP error messages of SubscriberBusyForMtSms, AbsentSubscriber, AbsentSubscriberSM, SMDeliveryFailure, SystemFailure

    • SMPP: SMPP response error with error codes except of STATUS_THROTTLED (0x58), STATUS_X_T_APPN (0x64), STATUS_SYSERR (0x08), STATUS_INVBNDSTS (0x00000004), STATUS_MSGQFUL (0x14)

  • Temporary error reasons:

    • DeliveryTimeout

    • MT: MAP dialog timeout

    • MT: SMDeliveryFailure MAP error message with causes "memoryCapacityExceeded" and "equipmentProtocolError"

    • MT: MAP error messages SubscriberBusyForMtSms, AbsentSubscriber, AbsentSubscriberSM, SMDeliveryFailure, SystemFailure

    • SMPP: SMPP response error with error codes STATUS_THROTTLED (0x58), STATUS_X_T_APPN (0x64), STATUS_SYSERR (0x08), STATUS_INVBNDSTS (0x00000004), STATUS_MSGQFUL (0x14)

    • SMPP: PduRequestTimeout and other sending error

5.5. Message processing rules (mproc rules)

Message processing rules (mproc rules) is a tool for processing messages and changing properties of message, for example source/destination TON, NPI, NetworkId etc. MProc rules are only applied if they match pre configured criterian.

MProc can be applied at several different message processing steps (triggers). Following are the triggers at which mproc rules can be applied to messages:

  • HrSri trigger : triggers inside HomeRouting procedure when a successfull SRI response from a local HLR has received. At this trigger HomeRouting procedure can be bypassed (this means that an original IMSI / NetworkNodeNumber will be returned to a remote SMSC GW and no MT messages will be delivered to a local SMSC GW).

  • Arrival trigger : triggers when a message arrives in SMSC GW and has been already processed (accepted) by Diameter server (if Diameter server is configured). Following actions are possible:

    • a message can be dropped (a success response will be returned to a message originator)

    • a message can be rejected (a reject response will be returned to a message originator)

    • most of a message parameters can be updated (for example destination address or even a message content).

    • changing of networkId will lead of message routing to another networkId area (see chapter SMSC GW routing fundamentals). It this trigger routing is preformed based on message delivery address or other message attributes.

    • a new message(es) can be posted for delivering. To post new messages at this step no Diameter server request and no mproc rules will be applied. In case of a message is a delivery receipt it is possible to parse and get receipt content and obtain an original message (that can be resent if needed).

  • PreDelivery trigger : triggers when a message is going to be delivered as a first or next delivery attempt. This trigger for a message can be in some time after an Arrival trigger and in this trigger we can perform more accurate checking of actual delivery situation of SMSC GW. Following actions are possible:

    • a message can be dropped without a delivery attempt

    • a message can be rerouted to another networkId area for delivering

    • a new message(es) can be posted for delivering

  • Imsi trigger : triggers inside MT procedure after when a successful SRI response has been received from remore HLR for an SS7 destination message.

    • a message can be dropped without a delivery attempt (with reporing by delivery receipts and CDRs)

    • a message can be rerouted to another networkId area for delivering

  • DeliveryTempFailure trigger : triggers after a message delivery attempts with a temporary failure result. Following actions are possible:

    • a message can be dropped without further delivery attempts

    • a message can be rerouted to another networkId area for new delivering attempt right now

    • a new message(es) can be posted for delivering

  • Delivery trigger : triggers after a message delivery was succeeded or permanently failed. Following actions are possible:

    • a message can be rerouted to another networkId area for new delivering attempt right now (this is possible only in delivery failure case)

    • a new message(es) can be posted for delivering (for example a custom delivery receipt)

SMSC comes with predifined set of mproc rules (default implementation) (see chapter Default message processing rules implementation). However users can make their own customized implementation of mproc rules by using java programming and implementing provided interfaces (see chapter Customized message processing rules). All mproc rules implementation has its Class Name. The Class Name of a default implementation is "mproc". This is the name by which users can create new mproc rule instances.

Users can create one or more mproc rules, modify, show and remove some of them by CLI or GUI interface. See details in chapter Message processing rules (mproc rules). Each mproc rule has it’s unique serial id. Mproc rule are sorted by this id value. SMSC appliec mproc rules to a message in ascending order, that is mproc rule with the least id is applied before mproc rule with next id etc.

While checking if mproc rule conditions match to a message, updates (that were made after previous rules applying) are taken into account. For example if a message destination address has been changed by rule 1, then rule 2 will check if this updated destination address matches to rules 2 or not.

5.5.1. Default message processing rules implementation

SMSC GW contains a default implementation of mproc rules that cover some requirenments. Information how to manage rules can be found in chapter Message processing rules (mproc rules). This chapter covers a description of conditions and actions that are present in default mproc rules implementation.

Parameters for mproc rule are divided into two cathegories:

a) Conditions. If a message fits to all conditions then the rule will be applied to the message.

Table 10. The list of possible conditions
Parameter name Value Description Default value

networkidmask

<networkId value>

mproc rule will be applied only if a message is processing now in a networkId area that is equal to networkidmask (messages’s networkId value is networkidmask).

"-1" : acts as wild card and hence messages in any network area will match.

originnetworkidmask

<networkId value>

mproc rule will be applied only if a message has come to SMSC GW via networkId area with this rule’s originnetworkidmask.

"-1" : acts as wild card and hence messages from any network area will match.

receiptnetworkidmask

<networkId value>

Rule will be applied only if a) a message is a delivery receipt, b) the delivery receipt is recognized by SMSC GW, c) an original message for the delivery receipt is found d), networkId of the original message == receiptnetworkidmask.

"-1" : acts as wild card and hence messages from any network area will match.

desttonmask

<destination type of number>

mproc rule will be applied only if message destination Type of Number is equal to this value "desttonmask"

"-1" : acts as wild card and hence messages with any TON will match.

destnpimask

<destination numbering plan indicator>

mproc rule will be applied only if message destination Numbering Plan Indicator is equal to this value "destnpimask".

"-1" : acts as wild card and hence messages with any NPI will match.

destdigmask

<java regular expression - destination number digits mask>

mproc rule will be applied only if message destination address digits matches with "destdigmask" java regular expression.

"-1" : acts as wild card and hence messages with any destination number will match.

sourcetonmask

<source type of number>

mproc rule will be applied only if message source Type of Number is equal to this value "sourcetonmask"

"-1" : acts as wild card and hence messages with any TON will match.

sourcenpimask

<source numbering plan indicator>

mproc rule will be applied only if message source Numbering Plan Indicator is equal to this value "sourcenpimask".

"-1" : acts as wild card and hence messages with any NPI will match.

sourcedigmask

<java regular expression - source number digits mask>

mproc rule will be applied only if message source address digits matches with "sourcedigmask" java regular expression.

"-1" : acts as wild card and hence messages with any source number will match.

imsidigitsmask

<java regular expression - IMSI mask>

mproc rule will be applied only if IMSI value was obtained after SRI request (during MT or HR procedure) and it matches with this rule’s imsidigitsmask. imsidigitsmask is java regular expression.

"-1" : acts as wild card and hence messages with any IMSI value or with no IMSI value obtained will match.

nnndigitsmask

<java regular expression - NetworkNodeNumber of VLR to where a subscriber is registered mask>

mproc rule will be applied only if NNN (NetworkNodeNumber of VLR to where a subscriber is registered) value was obtained after SRI request (during MT or HR procedure) and it matches with this rule’s nnndigitsmask. nnndigitsmask is java regular expression.

"-1" : acts as wild card and hence messages with any IMSI value or with no IMSI value obtained will match.

originatingmask

<SS7_MO | SS7_HR | SMPP | SIP | HTTP>

mproc rule will be applied only if message arrived in SMSC GW via a defined "originatingmask" connector.

"-1" : acts as wild card and hence messages originated from any channel will match.

origesmenamemask

<java regualar expression - origination ESME name mask>

mproc rule will be applied only if message has come to SMSC GW from SMPP connector from ESME with a name that fits "origesmenamemask".

"-1" : acts as wild card and hence any message will match (never mind if it came from SS7 or SIP).

originatorsccpaddressmask

<java regular expression - originator CallingPartyAddress digits mask>

mproc rule will be applied only if CallingPartyAddress digits match’s with "originatorsccpaddress mask" java regular expression.

"-1" : acts as wild card and hence messages with any CallingPartyAddress digits or without it will match.

processingtype

<SMPP | SS7_SRI | SS7_MT | SIP>

mproc rule will be applied only if a Delivery step match’s with this rule’s processingtype value.

"-1" : acts as wild card and hence messages with any delivery step will match.

errorcode

<digital value of SMSC GW’s internal error code>

mproc rule will be applied only if an internal SMSC GW’s delivery error code value matches with this rule’s errorcode. Value 0 means a successful delivery, non 0 value means some delivery error. You can specify several values via comma (example: "6,7,8"). Error code values list can be found in chapter Error Codes.

"-1" : acts as wild card and hence messages with any delivery result will match.

tlv_<value type>_<tag key>

<tag value>

mproc rule will be applied only if message contains a TLV parameter which matches the tag key, value type, and tag value.

"-1", "string", "-1" : acts as wild card and hence messages with any optional parameter will match.

percent

<percent value>

Defines probability with which mproc rule will be applied to a message. For example, if percent is specified as 60, there will be 60% chance that this rule will be applied. Consequently, in 40% of cases, mproc rule will be skipped.

"-1". This means that mproc rule will be applied to 100% of messages.

b) Actions, which will be applied to messages.

Table 11. The list of possible actions
Parameter name Trigger / Value Description Default value

newnetworkid

Arrival trigger / <new networkId value>

networkId of the message will be changed to "newnetworkid" value. This means that the message will be delivered via connectors that belong to the new networId.

"-1". This means that networkId of the message will not be changed.

newdestton

Arrival trigger / <new destination type of number>

a message destination Type of Number will be changed to "newdestton" value.

"-1". This means that destination Type of Number of the message will not be changed.

newdestnpi

Arrival trigger / <new destination numbering plan indicator>

a message destination Numbering Plan Indicator will be changed to "newdestnpi" value.

"-1". This means that destination Numbering Plan Indicator of the message will not be changed.

adddestdigprefix

Arrival trigger / <prefix>

adddestdigprefix will be added into a begin of a message destination address digits. For example if adddestdigprefix is "22" and destination address digits are "3333333", then the new value of destination address digits will be "223333333".

"-1". This means that destination address digits of the message will not be changed.

addsourcedigprefix

Arrival trigger / <prefix>

addsourcedigprefix will be added into a begin of a message source address digits. For example if addsourcedigprefix is "333" and destination address digits are "44444444", then the new value of source address digits will be "33344444444".

"-1". This means that source address digits of the message will not be changed.

newsourceton

Arrival trigger / <new source type of number>

a message source Type of Number will be changed to "newsourceton" value.

"-1". This means that source Type of Number of the message will not be changed.

newsourcenpi

Arrival trigger / <new source numbering plan indicator>

a message source Numbering Plan Indicator will be changed to "newsourcenpi" value.

"-1". This means that source Numbering Plan Indicator of the message will not be changed.

newsourceaddr

Arrival trigger / <new source address value>

a message source address will be changed to "newsourceaddr" value.

"-1". This means that source address of the message will not be changed.

makecopy

Arrival trigger / <false | true>

If the makecopy action is present then SMSC GW makes a copy of a message and then post the copy for further message processing in addition to the original message. All other actions in the rule will be applied only to the copy. For example user wants to make copies of messages and send them to another destinations (by sending of copies into another networkId), then for this you can create a rule and set for the rule "makecopy true" and "newnetworkid <new networkId value>" parameters. This makes a copy of a message and set for the copy a new networkId value.

false

hrbypass

HrSri trigger / <false | true>

This action may be applied inside Home Routing procedure after SMSC GW receives a response from a local HLR. Then SMSC GW will bypass HR procedure by sending back to an original SMSC GW origin original IMSI and NNN. SMSC GW will not get MT message then.

false

dropaftersri

ImsiRequest trigger / <false | true>

This is an action at the step when a successful SRI response has been received from HLR for an SS7 destination message. If a SRI success response has received then the message will be dropped without delivery attempt. A delivery response in this case will contain extra fields (IMSI and NetworkNodeNumber values).

false

newnetworkidaftersri

HrSri trigger / <networkId value>

This is an action at the step when a successful SRI response has been received from HLR for an SS7 destination message. If a SRI success response has received then the message will rerouted for delivery to another networkId.

"-1". This means that networkId of the message will not be changed.

newnetworkidafterpermfail

Delivery trigger / <networkId value>

This action at the step when a message delivery has failed permanently. Message will be rerouted for delivery to another networkId.

"-1". This means that networkId of the message will not be changed.

dropaftertempfail

DeliveryTempFailure trigger / <false | true>

This action at the step when a message delivery has failed temporarily. Message will be dropped without further delivery attempts.

false

newnetworkidaftertempfail

DeliveryTempFailure trigger / <networkId value>

This action at the step when a message delivery has failed temporarily. Message will be rerouted for delivery to another networkId.

"-1". This means that networkId of the message will not be changed.

droponarrival

Arrival trigger / <false | true>

This action is performed at the step when message has arrived to the server. Message will be dropped without delivery attempt and success response will be returned to a sender.

false

rejectonarrival

Arrival trigger / <NONE | DEFAULT | UNEXPECTED\_DATA\_VALUE | SYSTEM\_FAILURE | THROTTLING | FACILITY\_NOT\_SUPPORTED>

This action is performed at the step when message has arrived to the server. If value is NONE, no action will be performed. Otherwise message will be rejected without delivery attempt and reject response will be returned to a sender. Reject response will contain error codes for SMPP, SS7 and HTTP. Following are error codes listed in order SS7-SMPP-HTTP: DEFAULT: 34 (systemFailure) - 0 (Success) - 1; UNEXPECTED\_DATA\_VALUE: 36 (unexpectedDataValue) - 0x15 (Invalid service type) - 2; SYSTEM\_FAILURE: 34 (systemFailure) - 0x8 (System error) - 3; THROTTLING: 51 (resoureLimitation) - 0x58 (Throttling error) - 4; FACILITY_NOT_SUPPORTED: 21 (facilityNotSupported) - 0x65 (Permanent application error) - 5.

NONE

remove_tlv

Arrival trigger / <tlv tag value>

Optional parameter with the tag value in the message will be removed.

"-1". This means that no optional parameter will be removed.

5.5.2. Customized message processing rules

Default mproc rules allows to change the properties of a message in pre defined way, however if a user wants to achieve more, SMSC allows users to implement their own custom logic. Below steps describes how to implement custom mproc rules.

Procedure: Steps for custom mproc rules implementing
  1. User should implement the business logic as java code. There is a couple of interfaces exposed by SMSC, MProcRuleFactory and MProcRule that must be implemented and add the custom business logic. User needs to cover two parts of rules usage - a rule configuring part and a rule applying part.

    Please pay attention that in your code you may not perform long delays in order not to dramatically decrease of SMSC GW productivity.

    Once custom rule is implemented, user will have to create jar file and deploy it into SMSC Gateway.

    • User needs to decide a rule class name that will be used to uniquely identify the custom rules. This can be any word without spaces. For default mproc rules implementation the rule class name is "mproc". For example consider rule class name as "testrule".

    • User needs to impelent two interfaces: MProcRuleFactory and MProcRule. For example consider MProcRuleFactoryTestImpl and MProcRuleTestImpl.

    • User needs to decide which actions will custom rules perform and for which messages. For example create a custom rule that will be applied to any message at onPostArrival state who’s destination address digits are starting with a configurable parameter "par1". For all the messages which match’s this rules condition, prefix "par2" (the configurable parameter) is to be applied to message destination address.

  2. Creating custom classes:

    package org.mobicents.smsc.mproc.testimpl;
    
    import org.mobicents.smsc.mproc.MProcRuleFactory;
    
    public class MProcRuleFactoryTestImpl implements MProcRuleFactory {
    }
    package org.mobicents.smsc.mproc.testimpl;
    
    import org.mobicents.smsc.mproc.MProcRule;
    
    public class MProcRuleTestImpl implements MProcRule {
    }
  3. Implementing MProcRuleFactory interface. The interface is:

    package org.mobicents.smsc.mproc;
    
    public interface MProcRuleFactory {
        String getRuleClassName();
        MProcRule createMProcRuleInstance();
    }

    Method getRuleClassName() must return the rule class name. Method createMProcRuleInstance() must return a custom implementation of MProcRule (in this example instance of MProcRuleTestImpl class). Here is an example of implementation:

    package org.mobicents.smsc.mproc.testimpl;
    
    import org.mobicents.smsc.mproc.MProcRule;
    import org.mobicents.smsc.mproc.MProcRuleFactory;
    
    public class MProcRuleFactoryTestImpl implements MProcRuleFactory {
        public static final String CLASS_NAME = "testrule";
    
        @Override
        public String getRuleClassName() {
            return CLASS_NAME;
        }
    
        @Override
        public MProcRule createMProcRuleInstance() {
            return new MProcRuleTestImpl();
        }
    
    }
  4. Next is actual business logic that should go in implement of MProcRule interface. Let’s start with learning of the interface. The content of the interface is the following:

    package org.mobicents.smsc.mproc;
    
    public interface MProcRule extends MProcRuleMBean {
    
        void setId(int val);
    
        // rule matchers - they specifies if this rule processes a trigger
    
        /**
         * @return true if the mproc rule fits to a message for the phase SMSC GW receives SRI
         * response from a local HLR in HR procedure
         */
        boolean matchesPostHrSri(MProcMessage message);
    
        /**
         * @return true if the mproc rule fits to a message when a message has just come to SMSC
         */
        boolean matchesPostArrival(MProcMessage message);
    
        /**
         * @return true if the mproc rule fits to a message before a message delivery will start
         */
        boolean matchesPostPreDelivery(MProcMessage message);
    
        /**
         * @return true if the mproc rule fits to a message when IMSI / NNN has been received
         * from HLR (succeeded SRI response)
         */
        boolean matchesPostImsiRequest(MProcMessage message);
    
        /**
         * @return true if the mproc rule fits to a message when a message delivery was
         * ended (success or permanent delivery failure)
         */
        boolean matchesPostDelivery(MProcMessage message);
    
        /**
         * @return true if the mproc rule fits to a message when a message has temporary
         * delivery failure
         */
        boolean matchesPostDeliveryTempFailure(MProcMessage message);
    
        // rule processors - we will put code for processing there
    
        /**
         * the event occurs when SMSC GW receives SRI response from a local HLR in HR procedure
         */
        void onPostHrSri(PostHrSriProcessor factory, MProcMessage message) throws Exception;
    
        /**
         * the event occurs when a message has just come to SMSC
         */
        void onPostArrival(PostArrivalProcessor factory, MProcMessage message) throws Exception;
    
        /**
         * the event occurs before a message delivery will start
         */
        void onPostPreDelivery(PostPreDeliveryProcessor factory, MProcMessage message) throws Exception;
    
        /**
         * the event occurs when IMSI / NNN has been received from HLR (succeeded SRI response)
         */
        void onPostImsiRequest(PostImsiProcessor factory, MProcMessage message) throws Exception;
    
        /**
         * the event occurs when a message delivery was ended (success or permanent delivery
         * failure)
         */
        void onPostDelivery(PostDeliveryProcessor factory, MProcMessage message) throws Exception;
    
        /**
         * the event occurs when a message has temporary delivery failure
         */
        void onPostDeliveryTempFailure(PostDeliveryTempFailureProcessor factory, MProcMessage message) throws Exception;
    
        // applying of rule parameters from CLI / GUI interfaces
    
        /**
         * this method must implement setting of rule parameters as for provided CLI string
         * at the step of rule creation
         */
        void setInitialRuleParameters(String parametersString) throws Exception;
    
        /**
         * this method must implement setting of rule parameters as for provided CLI string
         * at the step of rules modifying
         */
        void updateRuleParameters(String parametersString) throws Exception;
    
    }

    and the parent interface content is:

    package org.mobicents.smsc.mproc;
    
    public interface MProcRuleMBean {
    
        /**
         * @return the id of the mproc rule
         */
        int getId();
    
        /**
         * @return Rule class of the mproc rule ("default" or other when a customer
         * implementation)
         */
        String getRuleClassName();
    
        /**
         * @return true if the mproc rule is used for the phase when a message has just come
         * to SMSC
         */
        boolean isForPostArrivalState();
    
        /**
         * @return true if the mproc rule is used for the phase SMSC GW receives SRI response
         * from a local HLR in HR procedure
         */
        boolean isForPostHrSriState();
    
        /**
         * @return true if the mproc rule is used for the phase before a message delivery
         * will start
         */
        boolean isForPostPreDeliveryState();
    
        /**
         * @return true if the mproc rule is used for the phase when IMSI / NNN has been
         * received from HLR (succeeded SRI response)
         */
        boolean isForPostImsiRequestState();
    
        /**
         * @return true if the mproc rule is used for the phase when a message delivery was ended
         * (success or permanent delivery failure)
         */
        boolean isForPostDeliveryState();
    
        /**
         * @return true if the mproc rule is used for the phase when a message has temporary
         * delivery failure
         */
        boolean isForPostDeliveryTempFailureState();
    
        /**
         * @return rule parameters as CLI return string
         */
        String getRuleParameters();
    
    }
    Table 12. MProcRule and MProcRuleMBean interfaces methods description
    Methods Description

    getId(), setId()

    mproc rule id getter and setter. id value is unique for each mproc rule inside SMSC GW.

    getRuleClassName()

    Returns the rule class name ("testrule" in this example)

    getRuleParameters(), setInitialRuleParameters(), updateRuleParameters()

    Getter and setters of configured parameters for a rule instance. Parameters are formed as a plain text string, that can be provided by CLI interface. In this example we need to configure two parameters par1 and par2. Let’s specify the parameters strinf as "par1" and "par2" (two values after a space, for example "11 34").

    isForPostHrSriState(), isForPostArrivalState(), isForPostPreDeliveryState(), isForPostImsiRequestState(), isForPostDeliveryState(), isForPostDeliveryTempFailureState()

    Returns true if this rule affects to a message processing trigger (for HrSri, Arrival, PreDelivery, Imsi, Delivery and DeliveryTempFailure triggers) and false if not. You have to check configured parameters of a rule and return a proper value

    matchesPostHrSri(MProcMessage message), matchesPostArrival(MProcMessage message), matchesPostPreDelivery(MProcMessage message), matchesPostImsiRequest(MProcMessage message), matchesPostDelivery(MProcMessage message), matchesPostDeliveryTempFailure(MProcMessage message)

    These methods must return true if rule should be applied or false if not (for HrSri, Arrival, PreDelivery, Imsi, Delivery and DeliveryTempFailure triggers).

    onPostHrSri(), onPostArrival(), onPostPreDelivery(), onPostImsiRequest(), onPostDelivery(), onPostDeliveryTempFailure()

    These methods are needed for implementing of rule applying actions.

    Id parameter and custom rule parameters ("par1" and "par2" in this example) must be stored into xml config file (it is located in restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/data/SmscManagement_mproc.xml). For this user needs to implement several extra methods that will be described later.

  5. Reusing of base MProcRuleBaseImpl class. It is recommended for your custom MProcRuleTestImpl to extend MProcRuleBaseImpl provided by SMSC. MProcRuleBaseImpl class contains some useful methods that cover code for persisting of its parameters into xml config file (read() and write() methods), default stubs for matches() and onPost*() methods and a service method for splitting of a parameters plain text string into subparameters (splitParametersString()).

    Here is the new template of MProcRuleTestImpl class implementation that reuses the base class MProcRuleBaseImpl:

    package org.mobicents.smsc.mproc.testimpl;
    
    import org.mobicents.smsc.mproc.MProcRuleBaseImpl;
    
    public class MProcRuleTestImpl extends MProcRuleBaseImpl {
    }
  6. Implementing of getRuleClassName() method of MProcRule. Below is an example:

        @Override
        public String getRuleClassName() {
            return MProcRuleFactoryTestImpl.CLASS_NAME;
        }
  7. Implementing of methods that cover getters / setters for message custom parameters and storing them into xml config file.

    In the example setInitialRuleParameters() and updateRuleParameters() methods are implemented in the same way. You can implement them in different ways so that updateRuleParameters() method can accept not the whole set of parameters but only that ones that a user wants to change.

    M_PROC_RULE_TEST_XML is responsible for XML serializing / deserializing. See more info for them in javolution library specification.

    Here is an example (only the part that is described in this step):

    package org.mobicents.smsc.mproc.testimpl;
    
    import javolution.xml.XMLFormat;
    import javolution.xml.stream.XMLStreamException;
    import org.mobicents.smsc.mproc.MProcRuleBaseImpl;
    
    public class MProcRuleTestImpl extends MProcRuleBaseImpl {
    
        private static final String PAR1 = "par1";
        private static final String PAR2 = "par2";
        private String par1, par2;
    
        @Override
        public void setInitialRuleParameters(String parametersString) throws Exception {
            String[] args = splitParametersString(parametersString);
            if (args.length != 2) {
                throw new Exception("parametersString must contains 2 parameters");
            }
            par1 = args[0];
            par2 = args[1];
        }
    
        @Override
        public void updateRuleParameters(String parametersString) throws Exception {
            String[] args = splitParametersString(parametersString);
            if (args.length != 2) {
                throw new Exception("parametersString must contains 2 parameters");
            }
            par1 = args[0];
            par2 = args[1];
        }
    
        @Override
        public String getRuleParameters() {
            return par1 + " " + par2;
        }
    
        /**
         * XML Serialization/Deserialization
         */
        protected static final XMLFormat<MProcRuleTestImpl> M_PROC_RULE_TEST_XML = new
                XMLFormat<MProcRuleTestImpl>(MProcRuleTestImpl.class) {
    
            @Override
            public void read(javolution.xml.XMLFormat.InputElement xml, MProcRuleTestImpl
                mProcRule) throws XMLStreamException {
                M_PROC_RULE_BASE_XML.read(xml, mProcRule);
    
                mProcRule.par1 = xml.getAttribute(PAR1, "");
                mProcRule.par2 = xml.getAttribute(PAR2, "");
            }
    
            @Override
            public void write(MProcRuleTestImpl mProcRule, javolution.xml.XMLFormat.OutputElement
                xml) throws XMLStreamException {
                M_PROC_RULE_BASE_XML.write(mProcRule, xml);
    
                xml.setAttribute(PAR1, mProcRule.par1);
                xml.setAttribute(PAR2, mProcRule.par2);
            }
        };
    }
  8. Overiding one of isForPost*() methods (for allowing of processing of a needed message processing step). In our example it is isForPostArrivalState():

        @Override
        public boolean isForPostArrivalState() {
            return true;
        }
  9. Implementing of a needed matches***() methods. In our example we process messages which destination address digits are started with a configurable parameter "par1".

        @Override
        public boolean matchesPostArrival(MProcMessage message) {
            if (message.getDestAddr().startsWith(par1))
                return true;
            else
                return false;
        }

    For matches***() methods we will use interface MProcMessage interface which provides info for processing message fields. Here is a code of these interfaces.

    package org.mobicents.smsc.mproc;
    
    import java.util.Date;
    
    public interface MProcMessage {
    
        long getMessageId();
    
        // source address part
        int getSourceAddrTon();
    
        int getSourceAddrNpi();
    
        String getSourceAddr();
    
        // dest address part
        int getDestAddrTon();
    
        int getDestAddrNpi();
    
        String getDestAddr();
    
        // message content part
        String getShortMessageText();
    
        byte[] getShortMessageBin();
    
        // other options
        int getNetworkId();
    
        int getOrigNetworkId();
    
        String getOrigEsmeName();
    
        OrigType getOriginationType();
    
        Date getScheduleDeliveryTime();
    
        Date getValidityPeriod();
    
        int getDataCoding();
    
        int getNationalLanguageSingleShift();
    
        int getNationalLanguageLockingShift();
    
        int getEsmClass();
    
        int getPriority();
    
        int getRegisteredDelivery();
    
        String getOriginatorSccpAddress();
    
        String getImsiDigits();
    
        String getNnnDigits();
    
        /**
         * @return Procedure that has given an error / success
         */
        ProcessingType getProcessingType();
    
        /**
         * @return 0 in case of delivery success or error code from ErrorCode in case
         * of delivery failure
         */
        int getErrorCode();
    
        // delivery receipt staff
    
        /**
         * @return true if a message is a SMPP delivery receipt received from remote SMSC GW
         */
        boolean isDeliveryReceipt();
    
        /**
         * @return if a message is a SMPP delivery receipt received from remote SMSC GW then
         * this method will parse the delivery receipt and return the parsed content
         */
        DeliveryReceiptData getDeliveryReceiptData();
    
        /**
         * @return if a message is a SMPP delivery receipt received from remote SMSC GW then
         * this method will return a local message
         * id for the original message (for which we have the receipt)
         */
        Long getReceiptLocalMessageId();
    
        /**
         * Returns a copy of previousely sent to a peer message by there messageId.
         * This messageId is usually obtained from a
         * delivery receipt from the peer.
         *
         * @param messageId
         * @return
         */
        MProcMessage getOriginMessageForDeliveryReceipt(long messageId);
    
    }
  10. Implementing of methods that make some actions: In example above this is onPostArrival() and the action is adding "par2" prefix into destination address digits. These methods will be invoked for all messages that match rule’s conditions.

        @Override
        public void onPostArrival(PostArrivalProcessor factory, MProcMessage message) throws Exception {
            String destAddr = this.par2 + message.getDestAddr();
            factory.updateMessageDestAddr(message, destAddr);
        }

    In onPostHrSri(), onPostArrival(), onPostPreDelivery(), onPostImsiRequest() and onPostDelivery(), onPostDeliveryTempFailure() methods user can use provided interfaces PostHrSriProcessor, PostArrivalProcessor, PostPreDeliveryProcessor, PostImsiProcessor and PostDeliveryProcessor, onPostDeliveryTempFailure that provide methods for message processing / adding / dropping / rejecting.

    • PostHrSriProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import org.apache.log4j.Logger;
      
      public interface PostHrSriProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          // actions
          /**
           * HR procedure will be bypassed (original IMSI and NNN will be sent as SRI response).
           *
           * @param newNetworkId
           */
          void byPassHr() throws MProcRuleException;
      
      }
    • PostArrivalProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import java.util.Date;
      
      import org.apache.log4j.Logger;
      
      public interface PostArrivalProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          // actions
          /**
           * Drop the message. Success response (that a message is accepted) will be return to
           * a message originator.
           */
          void dropMessage() throws MProcRuleException;
      
          /**
           * Drop the message. A reject will be sent to a message originator.
           */
          void rejectMessage() throws MProcRuleException;
      
          // updating of a message section
          void updateMessageNetworkId(MProcMessage message, int newNetworkId);
      
          /**
           * Updating of destination address message TON. In case of bad value (<0 or >6) MProcRuleException will be thrown
           *
           * @param message
           * @param newDestTon
           * @throws MProcRuleException
           */
          void updateMessageDestAddrTon(MProcMessage message, int newDestTon) throws MProcRuleException;
      
      
          /**
           * Updating of destination address message NPI. In case of bad value (<0 or >6)
           * MProcRuleException will be thrown
           *
           * @param message
           * @param newDestNpi
           * @throws MProcRuleException
           */
          void updateMessageDestAddrNpi(MProcMessage message, int newDestNpi) throws MProcRuleException;
      
          /**
           * Updating of destination address message digits. Value can not be null and must have
           * length 1-21 characters. In case of
           * bad value MProcRuleException will be thrown
           *
           * @param message
           * @param newDigits
           * @throws MProcRuleException
           */
          void updateMessageDestAddr(MProcMessage message, String newDigits) throws MProcRuleException;
      
          /**
           * Updating of source address message TON. In case of bad value (<0 or >6) MProcRuleException will be thrown
           *
           * @param message
           * @param newSourceTon
           * @throws MProcRuleException
           */
          void updateMessageSourceAddrTon(MProcMessage message, int newSourceTon) throws MProcRuleException;
      
          /**
           * Updating of source address message NPI. In case of bad value (<0 or >6)
           * MProcRuleException will be thrown
           *
           * @param message
           * @param newSourceNpi
           * @throws MProcRuleException
           */
          void updateMessageSourceAddrNpi(MProcMessage message, int newSourceNpi) throws MProcRuleException;
      
          /**
           * Updating of source address message digits. Value can not be null and must have length 1-21 characters. In case of
           * bad value MProcRuleException will be thrown
           *
           * @param message
           * @param newDigits
           * @throws MProcRuleException
           */
          void updateMessageSourceAddr(MProcMessage message, String newDigits) throws MProcRuleException;
      
          /**
           * Updating of message text. Value must not be null and must have length 0-4300.
           * In case of bad value MProcRuleException
           * will be thrown
           *
           * @param message
           * @param newShortMessageText
           * @throws MProcRuleException
           */
          void updateShortMessageText(MProcMessage message, String newShortMessageText) throws MProcRuleException;
      
          /**
           * Updating of UDH binary content. Value can be null or must have length > 0. In case
           * of bad value MProcRuleException will
           * be thrown
           *
           * @param message
           * @param newShortMessageText
           * @throws MProcRuleException
           */
          void updateShortMessageBin(MProcMessage message, byte[] newShortMessageBin) throws MProcRuleException;
      
          /**
           * Updating of ScheduleDeliveryTime - the time before which a message will not be
           * delivered. This value can be null, this
           * means that the message will be tried to delivery immediately. This value must be at
           * least 3 hours before a delivery
           * period end. If you pass the value that is later then 3 hours before a delivery
           * period end, then 3 hours before a delivery
           * period end will be set. If you change both ValidityPeriod and ScheduleDeliveryTime
           * values, then you have to setup
           * ValidityPeriod value firstly.
           *
           * @param message
           * @param newScheduleDeliveryTime
           */
          void updateScheduleDeliveryTime(MProcMessage message, Date newScheduleDeliveryTime);
      
          /**
           * Updating delivery period end time. This value can be null, this means that delivery
           * period will be set to a default
           * delivery period value of SMSC GW. If the value is more than max validity period that
           * is configured for SMSC GW, then max
           * validity period will be used instead of a provided value. If you change both
           * ValidityPeriod and ScheduleDeliveryTime
           * values, then you have to setup ValidityPeriod value firstly.
           *
           * @param message
           * @param newValidityPeriod
           */
          void updateValidityPeriod(MProcMessage message, Date newValidityPeriod);
      
          void updateDataCoding(MProcMessage message, int newDataCoding);
      
          void updateDataCodingGsm7(MProcMessage message);
      
          void updateDataCodingGsm8(MProcMessage message);
      
          void updateDataCodingUcs2(MProcMessage message);
      
          void updateNationalLanguageSingleShift(MProcMessage message, int newNationalLanguageSingleShift);
      
          void updateNationalLanguageLockingShift(MProcMessage message, int newNationalLanguageLockingShift);
      
          void updateEsmClass(MProcMessage message, int newEsmClass);
      
          void updateEsmClass_ModeDatagram(MProcMessage message);
      
          void updateEsmClass_ModeTransaction(MProcMessage message);
      
          void updateEsmClass_ModeStoreAndForward(MProcMessage message);
      
          void updateEsmClass_TypeNormalMessage(MProcMessage message);
      
          void updateEsmClass_TypeDeliveryReceipt(MProcMessage message);
      
          void updateEsmClass_UDHIndicatorPresent(MProcMessage message);
      
          void updateEsmClass_UDHIndicatorAbsent(MProcMessage message);
      
          void updatePriority(MProcMessage message, int newPriority);
      
          void updateRegisteredDelivery(MProcMessage message, int newRegisteredDelivery);
      
          void updateRegisteredDelivery_DeliveryReceiptNo(MProcMessage message);
      
          void updateRegisteredDelivery_DeliveryReceiptOnSuccessOrFailure(MProcMessage message);
      
          void updateRegisteredDelivery_DeliveryReceiptOnFailure(MProcMessage message);
      
          void updateRegisteredDelivery_DeliveryReceiptOnSuccess(MProcMessage message);
      
          // new message posting section
          /**
           * Creating a new message template for filling and sending by postNewMessage() method
           */
          MProcNewMessage createNewEmptyMessage(OrigType originationType);
      
          MProcNewMessage createNewCopyMessage(MProcMessage message);
      
          MProcNewMessage createNewResponseMessage(MProcMessage message);
      
          /**
           * Posting a new message. To post a new message you need: create a message template
           * by invoking of createNewMessage(), fill
           * it and post it be invoking of postNewMessage(). For this new message no mproc rule
           * and diameter request will be applied.
           */
          void postNewMessage(MProcNewMessage message) throws MProcRuleException;
      
      }
    • PostPreDeliveryProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import org.apache.log4j.Logger;
      
      public interface PostPreDeliveryProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          // actions
          /**
           * Stopping of message delivery as delivery failure (generating of delivery receipts
           * and CDRs)
           */
          void dropMessage() throws MProcRuleException;
      
          /**
           * Stopping of message delivery in this networkID and reschedule of message delivery to
           * another networkID area
           * @param newNetworkId
           */
          void rerouteMessage(int newNetworkId) throws MProcRuleException;
      
          /**
           * Creating a new message template for filling and sending by postNewMessage() method
           */
          MProcNewMessage createNewEmptyMessage(OrigType originationType);
      
          MProcNewMessage createNewCopyMessage(MProcMessage message);
      
          MProcNewMessage createNewResponseMessage(MProcMessage message);
      
          /**
           * Posting a new message. To post a new message you need: create a message template
           * by invoking of createNewMessage(), fill
           * it and post it be invoking of postNewMessage(). For this new message no mproc rule
           * and diameter request will be applied.
           */
          void postNewMessage(MProcNewMessage message) throws MProcRuleException;
      }
    • PostImsiProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import org.apache.log4j.Logger;
      
      public interface PostImsiProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          // actions
          /**
           * Stopping of message delivery as delivery failure (generating of delivery
           * receipts and CDRs)
           */
          void dropMessage() throws MProcRuleException;
      
          /**
           * Stopping of message delivery in this networkID and reschedule of message delivery to
           * another networkID area
           * @param newNetworkId
           */
          void rerouteMessage(int newNetworkId) throws MProcRuleException;
      
      }
    • PostDeliveryProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import org.apache.log4j.Logger;
      
      public interface PostDeliveryProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          boolean isDeliveryFailure();
      
          // actions
          /**
           * Stopping of message delivery in this networkID and reschedule of
           * message delivery
           * to another networkID area. Applyable
           * only for a permanent failure case (will give Exception in Success case)
           *
           * @param newNetworkId
           */
          void rerouteMessage(int newNetworkId) throws MProcRuleException;
      
          /**
           * Creating a new message template for filling and sending by postNewMessage() method
           */
          MProcNewMessage createNewEmptyMessage(OrigType originationType);
      
          MProcNewMessage createNewCopyMessage(MProcMessage message);
      
          MProcNewMessage createNewResponseMessage(MProcMessage message);
      
          /**
           * Posting a new message. To post a new message you need: create a message template
           * by invoking of createNewMessage(), fill
           * it and post it be invoking of postNewMessage(). For this new message no mproc rule
           * and diameter request will be applied.
           */
          void postNewMessage(MProcNewMessage message) throws MProcRuleException;
      
      }
    • PostDeliveryTempFailureProcessor interface content:

      package org.mobicents.smsc.mproc;
      
      import org.apache.log4j.Logger;
      
      public interface PostDeliveryTempFailureProcessor {
      
          // access to environmental parameters
          /**
           * @return the logger that an application can use for logging info into server.log
           */
          Logger getLogger();
      
          // actions
          /**
           * Stopping of message delivery as delivery failure (generating of delivery receipts and CDRs)
           */
          void dropMessage() throws MProcRuleException;
      
          /**
           * Stopping of message delivery in this networkID and reschedule of message delivery
           * to another networkID area
           * @param newNetworkId
           */
          void rerouteMessage(int newNetworkId) throws MProcRuleException;
      
          /**
           * Creating a new message template for filling and sending by postNewMessage() method
           */
          MProcNewMessage createNewEmptyMessage(OrigType originationType);
      
          MProcNewMessage createNewCopyMessage(MProcMessage message);
      
          MProcNewMessage createNewResponseMessage(MProcMessage message);
      
          /**
           * Posting a new message. To post a new message you need: create a message template
           * by invoking of createNewMessage(), fill
           * it and post it be invoking of postNewMessage(). For this new message no mproc rule
           * and diameter request will be applied.
           */
          void postNewMessage(MProcNewMessage message) throws MProcRuleException;
      
      }
  11. Once all the source code is fully implemented, user should deploy it.

    • User must compile java code and create a jar library. Copy the created jar into the folder restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/lib.

    • You need to update restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml config file.

      Define factory implementing MProcRuleFactoryin above example it will be MProcRuleFactoryTestImpl:

          <bean name="MProcRuleFactoryTest" class="org.mobicents.smsc.mproc.testimpl.MProcRuleFactoryTestImpl">
          </bean>

      bean name can be some unique name.

      In the "bean name="SmscManagement"" section - property <property name="MProcRuleFactories"> - after the line <inject bean="MProcRuleFactoryDefault"/> (that means default mproc rules implementing) - add the line that describes your new created bean:

              <property name="MProcRuleFactories">
                  <list elementClass="org.mobicents.smsc.mproc.MProcRuleFactory">
                      <inject bean="MProcRuleFactoryDefault"/>
                      <inject bean="MProcRuleFactoryTest"/>
                  </list>
              </property>
  12. Start SMSC GW

  13. Create an mproc rule by using CLI interface. Let’s create a rule with id=1 that will be applied for messages which destination adresses are started with "22" and this rule will add prefix "33". To achive it run CLI console and run the following command

    smsc mproc add testrule 1 22 33

    where "testrule" is an implemented class name, "22 33" is aparameter string.

  14. Send a message to the destination address that starts with "22" (for example "221111") and find that the message will be delivered to the address with prefix "33" ("33221111" in our example).| |

5.6. SMS Home Routing

According to traditional GSM specifications, all outbound messages pass through an SMSC in the sending network. This allows the SMSC to convert the Mobile Originated (MO) messages into Mobile Terminated (MT) messages and deliver them directly to the destination devices, regardless of what network they are on. As a result, inbound messages generated on other networks will be sent directly to the destination devices under the control of the SMSC in the sending network, not the home network. In this traditional setup, operators can add value to the MO messages but not to the MT messages that the customer may receive from other networks, since they do not pass through an SMSC in the home network.

SMS Home Routing is a modification to the original GSM specifications, adopted by the 3GPP in 2007, that changed the way inbound messages are treated by the mobile networks. Home Routing uses the recipient network’s Home Location Register (HLR) to change the flow of inbound messages, directing them to an MT Services Platform, rather than straight to the destination devices. The MT Services platform can add value to the MT messages and apply advanced services such as anti-spam, protection, divert, archiving, etc. to the messages prior to delivery.

Home Routing enables operators to offer a full range of value-added services to both inbound and outbound SMS thereby enhancing customer experience while generating additional revenue for the operators.

Restcomm SMSC supports SMS Home Routing that enables you to handle Mobile Terminated messages in the network that owns the customer so you can offer a full range of advanced and value added services on both inbound and outbound SMS. You need to configure SMSC GW before you can use SMS Home Routing. For more details refer to Home Routing Settings.

There are two possible modes of home routing functionality:

  • non-transparent mode - default mode when SMSC GW returns with successfull responses to incoming MT requests (without waiting till a message is delivered to a destination).

  • transparent mode - SMSC GW waits (after a MT request) till a message is delivered to a destination and responds to the MT request with a result of message delivering (success / failure). To activate this mode you need to configure the option Messaging mode for HR messages to "Transactional".

Pay also attention that SMSC GW in Home Routing mode usually plays "HLR role" and listens an extra SSN (usually SSN 6 as additionto SSN 8 for other functionality). These parameters are configured in jboss-beans.xml file for TCAP stack. You can find below the example of configuring of two listerning SSNs (8 and 6 in the example). This configuration is a default configuration out of box.

	<bean name="TcapStack" class="org.mobicents.protocols.ss7.tcap.TCAPStackImpl">
		<constructor>
			<parameter>TcapStack</parameter>
			<parameter>
				<inject bean="SccpStack" property="sccpProvider" />
			</parameter>
			<parameter>8</parameter>
		</constructor>
		<property name="persistDir">${jboss.server.data.dir}</property>
		<property name="extraSsns">
			<list class="javolution.util.FastList" elementClass="java.lang.Integer">
				<value>6</value>
			</list>
		</property>
	</bean>

5.7. SMPP interface description

5.7.1. Encoding at SMPP interface

When message sending and recieveing via SMPP interface of SMSC GW we need to care of message body encoding and assigning of a parameter DCS (data coding schema).

DCS parameter means the encoding that will be used when a message will be transferred at SS7 part. The most common parameteres for DCS are:

  • 0 - GSM7 encoding (english characters and a little set of extra characters are supported). 7-bit encoding is used at SS7 network message transferring

  • 4 - GSM8 encoding (used mostly for binary messages). No recoding is applied. Binary messages are just transferred to the destination without any changes.

  • 8 - UCS2 encoding (all characters are supported). 2-bytes encoding is used at SS7 network message transferring.

For DCS 0 (GSM7 encdoing) and 8 (UCS2 encoding) SMSC GW decodes messages when receiving from SMPP connector and encode messages before sending them into SMPP connector. For this task it is important which data coding schema will be used for messages decoding / encoding. SMSC GW has two configurable parameters for decoding / encodoing, one for GSM 7 ancoding and another for UCS2 encoding (SMPP Encoding for GSM7 / SMPP Encoding for UCS2). See following chapter for configuring details: SMPP Encoding for GSM7/UCS2. A user schould configure these parameters before of SMSC GW usage depending on which encoding are used by user’s SMPP applications for message body encoding.

One of indication that says that message encoding parameters are wrongly configured is messages in server.log like Message length in bytes is too big for solid message: 268>134. This may mean that SMPP application sends messages to SMSC GW in UCS2 encoding and SMSC GW decodes them in UTF8 encodoing and a message bode becomes too big length after it.

5.7.2. Delivery receipts transit at SMPP interface

SMSC GW can generate delivery receipts after a message is delivered / failed to some destination. For this a SMPP application must set suitable values in the registered_delivery field. After a message is delivered / failed to some destionation, then SMSC GW will generate a delivery receipt. For simple routing such receipts back to an original ESME we can just assign to each ESME a separate networkId value and turn on the following option: Routing of delivery receipts.

But sometimes SMSC GW plays a role of a transit node and SMSC GW customers interest in delivery receipts from upper SMSC GW nodes (nodes that deliver messages directly to customers) an not from a transit SMSC GW itself. Restcomm SMSC GW can play such role and this case is more complicated. SMSC GW must accept delivery receipts from upper SMSC GW nodes, replace messageId values in these receipts by a messageId which SMSC GW used in submit_sm_response to a lower node that has sumbitted an original message and sends an updated receipt to an original ESME. We call such process as a delivery receipt transit.

To achieve this functionality we must make following configuring:

  • Turn on the option Disabling of Reciepts generating (by this we prevent SMSC GW from generating of its own delivery receipts)

  • Turn on the option Income receipts processing. This will force SMSC GW to store extra info for each received and resent original message into extra tables of cassandra database and then when a delivery receipt comes from an upper node then SMSC GW will replace messageID in the receipt to the proper messageId that was sent to the originator of submit_sm (to lower SMSC GW).

  • A sent message and a received delivery receipt must be at the same ESME cluster.

  • Then we have to force that the updated delivery receipt will be routed back to the original ESME. Routing of delivery receipts will not help us in this case. There may be several approaches for it. The recommended one - put each ESME at the separate networkID area and then add mproc rules for rerouting that will use the parameter "receiptnetworkidmask" (check the chapter Default message processing rules implementation). For example a mproc rule smsc mproc add mproc 1 receiptnetworkidmask 1 newnetworkid 1 will be applied only for delivery receipts and only for that delivery receipt an original message for which has come from netoworkId 1 area. And in this case the delivery receipt will be routed into networokId area 1.

5.8. HTTP interface description

5.8.1. Send SMS

Send message API is responsible for sending SMS messages. To send message we should create and send HTTP request in proper format. Supported HTTP methods are GET and POST. Request URL must have “sendSms” context and contain all of mandatory parameters.

Table 13. Mandatory parameters:
Parameter name Meaning

userid

Your register email in our platform (not used now)

password

Your account password (not used now)

msg

Message body (message text)

sender

Message source address digits

to

Message destination address digits. We can use multiple comma separated destinations. Maximum number of destinations is 50 000 for POST method, in GET it is limited to maximum length of URL. Destinations in international format are without "+" or "00" in beginning, e.g. 962788002265.

Table 14. Optional parameters:
Parameter name Meaning

format

Values can be "String" or "json", default is "String"

smscEncoding

Values can be "GSM7" (usually used for english letters and digits) or "UCS2" (used for arabic, cyrillic, etc letters), default is "GSM7". This parameter affects Data Coding Schema parameter.

messageBodyEncoding

Values can be "UTF8" or "UTF16". If parameter is not provided then value depends on "smscEncoding" parameter and it is taken from SMSC properties . Default value is "UTF8". This parameter affects data encoding of a message body at HTTP interface.

senderTon

TON value for a source address (if missed then Default TON value for source addresses value will be used)

senderNpi

NPI value for a source address (if missed then Default NPI value for source addresses value will be used)

udh

Optional User Data Header (UDH) part of the message. Must be URL encoded (if missed then SMSC GW will not include UDH value into message). UDH should be created by client

Format parameter controls the response format to the request. Response contains the status of request, it can be “Success” or “Error”. In case of error it contains an error code and error message. In case of success response contains a list of pairs: “request ID / destination ID:destination”.

Request examples:

http://127.0.0.1:8080/restcomm/sendSms?userid=user1&password=password&msg=exampleMessage_01&sender=1234&to=1111,2222,3333,4444,6666

http://127.0.0.1:8080/restcomm/sendSms?userid=user1&password=password&msg=exampleMessage_02&format=String&smscEncoding=GSM7&messageBodyEncoding=UTF8&sender=1234&to=1111

http://127.0.0.1:8080/restcomm/sendSms?userid=user1&password=password&msg=exampleMessage_03&format=json&smscEncoding=UCS2&messageBodyEncoding=UTF16&sender=4321&to=6666,6667&senderTon=5&senderNpi=0&udh=%06%05%04%13%01%13%01

Response examples:

{"Success","444":"2016","222":"2014","111":"2013","333":"2015"}

error:6,request not accepted

5.8.2. Get message status

Get message status API is responsible for checking sent messages status. To check message status we should create and send HTTP request in proper format. Supported HTTP methods are GET and POST. Request URL must have "msgQuery" context and contain all of mandatory parameters.

Table 15. Mandatory parameters:
Parameter name Meaning

userid

Your register email in our platform (not used now)

password

Your account password (not used now)

msgid

ID of message which will be returned. Only one ID in a parameter is allowed

Table 16. Optional parameters:
Parameter name Meaning

format

Values can be "String" or "json", default is "String"

Response contains the status of request, it can be "Success" or "Error". It contains also a status message.

Request examples:

http://127.0.0.1:8080/restcomm/msgQuery?userid=100&password=pass&msgid=2005

http://127.0.0.1:8080/restcomm/msgQuery?userid=100&password=pass&msgid=534&format=json

Response examples:

{"Success","msg sent"}

error:4,message ID not exists

5.9. Interworking with Diameter OCS server

5.9.1. General information

SMSC GW can interoperate with an OCS server via Diameter protocol connection.

For this case SMSC GW can be configured so any incoming SMPP (only submit_sm and data_sm are supported), MO SS7 and Home Routing SS7 originated messages before next processing will be sent to OCS server. Then OCS server can check if SMSC GW must accept the message or not. If yes, SMSC GW will process the message, if not, the message will be dropped. OCS server can also make any charging operations as needed.

For SMPP and MO and HR SS7 originated messages SMSC GW will return error (reject) in the response back to the originated submit message. So MO SS7, HR SS7 and SMPP part will be informed if the message is rejected.

For interconnecting with OCS Server SMSC GW uses diameter CCR (Credit-Control Request) with following filled AVPs (all of them are located in AVP Service-Information (873)):

Table 17. The AVP list
AVP name AVP code AVP Type Parent AVP Description

SMS-Information

2000

Grouped

Service-Information

SMS service specific information elements

Originator-SCCP-Address

2008

Address

SMS-Information

The CallingParty SCCP Address of MO message

SMSC-Address

2017

Address

SMS-Information

SMSC address as it is present in SM_RP_DA field in MO request. For not MO messages the value will be taken as a configured SMSC GT for networkId area

Data-Coding-Scheme

2001

Integer 32

SMS-Information

Data Coding Scheme of a message (for example 0 for GSM7 encoding or 8 for UCS2 encoding)

SM-Message-Type

2007

Message type, usually SUBMISSION (value = 0)

Originator-Interface

2009

Grouped

SMS-Information

Information related to the Interface on which the message originated.

Interface-Id

2003

UTF8-String

Originator-Interface

NetworkID value of the Interface on which the message originated.

Interface-Text

2005

UTF8-String

Originator-Interface

Name of ESME / SIP connector on which the message originated.

Recipient-Info

2026

Grouped

SMS-Information

Information associated with a recipient.

Recipient-Address

1201

Grouped

Recipient-Info

The address of message receiver (destination address)

Address-Type

899

Enum

Recipient-Address

Type of Recipient-Address: 1-MSISDN (for TON=1 - international) or 6-Other (for TON!=1)

Address-Data

897

UTF8-String

Recipient-Address

Digits of Recipient-Address

Originator-Received-Address

2027

Grouped

SMS-Information

The address of message sender (source address)

Address-Type

899

Enum

Originator-Received-Address

Type of Originator-Received-Address: 1-MSISDN (for TON=1 - international) or 6-Other (for TON!=1)

Address-Data

897

UTF8-String

Originator-Received-Address

Digits of Originator-Received-Address

When OCS server responds with 2001 code (access granted) SMSC GW will accept the message, all other respond codes will reject the message.

5.9.2. Configuring

You can use Telestax OCS server or any third party OCS server as you wish. SMSC GW party configuring is the same for both. Here there is a describtion for the case of Telestax OCS server and as an example - the simpliest case when we have OCS at the same host as SMSC GW.

Procedure: Steps for configuring of SMSC GW and OCS server
  1. SMSC GW must be already configured for accepting and sending messages (general, SS7, SMPP, etc parts)

  2. You can download for testing the Telestax OCS server from https://telestax.zendesk.com/forums/22947518-Product-Downloads. Download and unpack it to a separate folder.

  3. SMSC GW uses the updated AVP dictionary library. Before using of OCS server copy from SMSC GW the file <smsc gw root folder>/resource/ocs/dictionary.xml to Telestax OCS server to the folder <jboss>/server/default/deploy/restcomm-diameter-mux-6.2.0.GA.sar/config.

  4. for simple test configuring of SMSC GW and OCS server you can copy example config files jdiameter-config.xml

    • from <smsc gw root folder>/resource/ocs/smsc-part to SMSC GW <jboss>/server/default/deploy/restcomm-diameter-mux-6.2.0.GA.sar/config

    • from <smsc gw root folder>/resource/ocs/ocs-part to OCS server <jboss>/server/default/deploy/restcomm-diameter-mux-6.2.0.GA.sar/config

This file is already copied to SMSC GW into Simulator profile.

  1. Those configs suppose that you use Telestax OCS server and it is on the same host. If not you need to make extra configuring. In the testing config files SMSC GW plays a role of a diameter client and OCS server - a diameter server. In this case for OCS server part we need to update jdiameter-config.xml file:

    • <LocalPeer> section with URI, IPAddresses and Realm.

    • In <Network> we need to specify <Peer> (SMSC GW diameter IP) and <Realm> (name and the same Realm that is configured in SMSC GW part)

      For SMSC GW part we need to update:

    • <LocalPeer> section with URI, IPAddresses and Realm.

    • In <Network> we need to specify <Peer> (OCS server diameter IP) and <Realm> (name and the same Realm that is configured in OCS server part) You can read more for configuring in the manuals for Telestax Diameter protocol and Telestax OCS server.

  2. Start OCS server. If it is located in the same host as SMSC GW you need to run it "-b 127.0.0.2" parameter so it uses 127.0.0.2 IP address (127.0.0.1 is used by SMSC GW) Use fo starting the command like:

    run -b 127.0.0.2
  3. For accessing OCS managing console (after OCS server is started) use a browser with URL: http://127.0.0.2:8080/charging-server-rest-management/#/users

    Avoid of using of Microsoft Internet Explorer, OCS server does not work correctly with it.

    Add one or more test subscribers by the console. You need to specify an address of message sender (source address). OCS Server idendifies a subscriber by its sender address.

  4. Start SMSC GW

  5. You need to configure Destination Realm, Destination Host, Destination Port and User Name (of OCS server) - see the chapter "6.1.5. Diameter Settings" of SMSC GW Admin guide. You can take values from jdiameter-config.xml. You can assign for User Name any value (for example "telestax").

  6. You need to specify which messages will be sent to OCS server (see chapter Diameter Settings). For example if you want to charge mobile originated messages - specify "Mobile Originated SMS Charged" to value "diameter".

  7. SMSC GW is configured

5.10. Security issues

When you configure SMSC GW for the first usage you need to care for security to avoid of unauthorized usage. Here you can find some tips for this.

If we do not accept messages from SS7 connection (and any other connection) - disable of all messages from all concrete type of connections. Find extra in MO accepting and charging settings, ESME Charge Settings, SIP Charge Settings, Home routing Charge Settings, HTTP Charge Settings.

if we accept MO messages from our subscribers we need to specify (via mproc rules) that we will reject incoming messages with "sourcedigmask" value is out of our subscriber’s range (a mproc rule)

To be safe a good way to use diameter server requests for messages where we can implement logic of spam avoiding.

5.11. CDR Logging Settings

Restcomm SMSC is configured to generate CDR in a plain text file located at restcomm-smscgateway-<version>/jboss-5.1.0.GA/server/<profile>/log/cdr.log and also detailed CDR in Cassandra table MESSAGES_yyyy_mm_dd.

Restcomm SMSC can be configured to generate CDR for different message processing modes (datagramm, transactional, storeAndForward) and also for both receipt and regular messages or generate CDR only for regular messages. This is configurable by setting generateCdr, generateArchiveTable and generateReceiptCdr using the CLI or the GUI. For more details refer to Sections CDR generation, Archive table generation and Generate CDR for Receipt Messages.

The CDR generated in a text file is of a specific format. The details of the format and the possible values for the fields recorded in the CDR log file are explained in CDR Log.

6. Managing

Now that you have set up the Gateway you must configure the SS7 Stack and the Gateway. &THIS.PLATFORM;&THIS.APPLICATION;comes with a convenient user-friendly Graphical User Interface (GUI) and a Command Line Interface (CLI) that will allow you to configure, monitor and manage the Gateway. While the CLI tool allows complete configuration and control of the Gateway, the GUI-based management enhances the usability of the Gateway and gives you the ability to configure and manage the SMSC Gateway dynamically. This chapter will explain how to manage the Gateway effectively using both the GUI and the CLI.

Configuring the SS7 Stack

You must configure the SS7 stack prior to configuring SMSC. For details on configuring the SS7 Stack please refer to the Restcomm SS7 Stack User Guide. The Restcomm SS7 Stack User Guide lists all available Shell commands and GUI operations to configure SS7. In addition, help files are also available for every Shell command providing all details relevant to the command.

Configuring the Gateway

Please find below relevant information on configuring the Gateway

6.1. SMSC Gateway Server Settings

6.1.1. SMSC Server Properties

6.1.1.1. Default Validity Period (in hours)
6.1.1.1.1. Using CLI

You can set the 'Default Validity Period (in hours)' by issuing the command smsc set defaultvalidityperiodhours with appropriate parameters as described below. You can verify this by issuing the command smsc get defaultvalidityperiodhours which will display the value set for this property.

Name
	smsc set defaultvalidityperiodhours

SYNOPSIS
	smsc set defaultvalidityperiodhours <default-validity-period-hours>

DESCRIPTION
	This command is used to set a value for default validity period (in hours) for
	incoming SMSC messages that do not have their own validity period value. Validity
	period is the time duration for which the SMSC Gateway will attempt to
	send the SMS. If the time period expires before the message can be delivered,
	the SMSC Gateway will drop it.

EXAMPLES
	smsc set defaultvalidityperiodhours 3
6.1.1.1.2. Using GUI
Procedure: Set Default Validity Period using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the default validity period (in hours) by entering the value in the text field 'Default validity period hours (in hours)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.2. Maximum Validity Period (in hours)
6.1.1.2.1. Using CLI

You can set the 'Max Validity Period (in hours)' by issuing the command smsc set maxvalidityperiodhours with appropriate parameters as described below. You can verify this by issuing the command smsc get maxvalidityperiodhours which will display the value set for this property.

Name
	smsc set maxvalidityperiodhours

SYNOPSIS
	smsc set maxvalidityperiodhours <max-validity-period-hours>

DESCRIPTION
	This command is used to set a value for the maximum validity period (in hours).
	All incoming messages with a validity period set greater than the value specified
	by this parameter will either be rejected (if they are ESME originated messages)
	or the value of their validity period will be set to this value (for MO originated
	messages).

EXAMPLES
	smsc set maxvalidityperiodhours 6
6.1.1.2.2. Using GUI
Procedure: Set Maximum Validity Period using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the maximum validity period (in hours) by entering the value in the text field 'Maximum validity period (in hours)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.3. Default Type of Number (TON)
6.1.1.3.1. Using CLI

You can set the 'Default type of number (TON)' by issuing the command smsc set defaultton with appropriate parameters as described below. You can verify this by issuing the command smsc get defaultton which will display the value set for this property.

Name
	smsc set defaultton

SYNOPSIS
	smsc set defaultton <default-ton>

DESCRIPTION
	This command is used to set a value for default TON (Type Of Number). If an
	incoming message does not have a value defined for TON, i.e. if TON is set as
	'unknown', then the value specified for defaultton will be used as TON for that
	message.

EXAMPLES
	smsc set defaultton 1
6.1.1.3.2. Using GUI
Procedure: Set Default type of number (TON) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Default type of number (TON) by entering the value in the text field 'Default type of number (TON)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.4. Default numbering plan indicator (NPI)
6.1.1.4.1. Using CLI

You can set the 'Default numbering plan indicator (NPI)' value by issuing the command smsc set defaultnpi with appropriate parameters as described below. You can verify this by issuing the command smsc get defaultnpi which will display the value set for this property.

Name
	smsc set defaultnpi

SYNOPSIS
	smsc set defaultnpi <default-npi>

DESCRIPTION
	This command is used to set a value for default NPI (Number Plan Indicator). If an
	incoming message does not have a value defined for NPI, i.e. if NPI is set as
	'unknown', then the value specified for defaultnpi will be used as NPI for that
	message.

EXAMPLES
	smsc set defaultnpi 1
6.1.1.4.2. Using GUI
Procedure: Set Default numbering plan indicator (NPI) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Default numbering plan indicator (NPI) by entering the value in the text field 'Default numbering plan indicator (NPI)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.5. Cluster Name
6.1.1.5.1. Using CLI

You can set the 'Cluster Name' value by issuing the command smsc set esmedefaultcluster with appropriate parameters as described below. You can verify this by issuing the command smsc get esmedefaultcluster which will display the value set for this property. This parameter affects only for DatabaseSmsRoutingRule - see Database Routing Rules.

Name
	smsc set esmedefaultcluster

SYNOPSIS
	smsc set esmedefaultcluster <esme-default-cluster>

DESCRIPTION
	This command is used to set a value for ESME default cluster. If the
	destination-address does not match to any ESME (any Cluster Name) the message will
	be routed to the cluster with the name specified here for esme-default-cluster.
	This parameter affects only for DatabaseSmsRoutingRule (not used for default
	routing).

You can remove an ESME default cluster by issuing a command in the below format:

Name
	smsc remove esmedefaultcluster

SYNOPSIS
	smsc remove esmedefaultcluster <esme-default-cluster>

DESCRIPTION
	This command is used to remove the value configured for ESME default cluster. If
	this value is removed, all unrouted messages will be routed into the GSM network.
	This parameter affects only for DatabaseSmsRoutingRule (not used for default
	routing).
6.1.1.5.2. Using GUI
Procedure: Set Cluster Name using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Cluster Name by entering the value in the text field 'Cluster Name'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.6. SMPP Encoding for GSM7/UCS2
6.1.1.6.1. Using CLI

You can set the 'SMPP Encoding for GSM7 (DCS=0)' and 'SMPP Encoding for UCS2 (DCS=8)' value by issuing the commands smsc set smppencodingforgsm7 / smsc set smppencodingforucs2 with appropriate parameters as described below. You can verify this by issuing the commands smsc get smppencodingforgsm7 / smsc get smppencodingforucs2 which will display the value set for these property. When GSM8 encoding type no recoding of message content is made.

Name
    smsc set smppencodingforgsm7
    smsc set smppencodingforucs2

SYNOPSIS
    smsc set smppencodingforgsm7 <UTF8|UNICODE|GSM7>
	smsc set smppencodingforucs2 <UTF8|UNICODE|GSM7>

DESCRIPTION
    These commands are used to set the Encoding Scheme at SMPP side for
    different GSM data coding schemas (DCS).

    For GSM7 encoding (DCS = 0) you must use the command
    smsc set smppencodingforgsm7, in order to set text encoding style.

    For UCS2 encoding (DCS = 8), you must use the command
    smsc set smppencodingforucs2, in order to set text encoding style.

    At the SMPP side, messages accept 3 different encoding schemes namely UTF8,
    UNICODE and GSM7 (8-bit), for both sending and receiving messages. The SMSC
    can be configured to accept one of them (the one that ESME supports). If this
    is not set, then the default encoding sheme is UTF8. For GSM8 encoding (DCS = 4),
    no charset encoding made in the SMSC.

EXAMPLES
	smsc set smppencodingforgsm7 utf8
	or
	smsc set smppencodingforucs2 unicode
6.1.1.6.2. Using GUI
Procedure: Set SMPP Encoding for GSM7 and UCS2 using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the encoding scheme by choosing from the values (UTF8 | UNICODE | GSM7) in the list for 'SMPP Encoding for GSM7' (DCS=0) or 'SMPP Encoding for UCS2' (DCS=8). For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.7. Store And Forward Mode
6.1.1.7.1. Using CLI

You can set the 'Store And Forward Mode' value by issuing the command smsc set storeandforwordmode with appropriate parameters as described below. You can verify this by issuing the command smsc get storeandforwordmode which will display the value set for this property.

Name
	smsc set storeandforwordmode

SYNOPSIS
	smsc set storeandforwordmode <normal | fast>

DESCRIPTION
	This command is used to set the storeandforwordmode value.
	storeandforwordmode has two possible values:

	normal - StoreAndForward mode is used for incoming
	smpp StoreAndForward messages and all SS7 and SIP messages. All
	the incoming messages into SMSC will be persisted before trying
	for delivery.

	fast (default) - ForwardAndStore mode is used for incoming smpp
	StoreAndForward messages and all SS7 and SIP messages. This option
	can be switched without SMSC restart. All the incoming messages into
	SMSC will be tried for delivery first and only if delivery fails,
	it will be persisted for later re-try.

	Datagramm and Transactional modes will work in the same way for both normal and fast modes.

EXAMPLES
	smsc get storeandforwordmode fast
6.1.1.7.2. Using GUI
Procedure: Set Store And Forward Mode using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Store And Forward Mode by selecting the value from the dropdown field 'Store And Forward Mode'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.8. National language locking shift table
6.1.1.8.1. Using CLI

You can set the 'National language locking shift table' value by issuing the command smsc set nationallanguagelockingshift with appropriate parameters as described below. You can verify this by issuing the command smsc get nationallanguagelockingshift which will display the value set for this property.

Name
	smsc set nationallanguagelockingshift

SYNOPSIS
	smsc set nationallanguagelockingshift <NationalLanguageIdentifier>

DESCRIPTION
	National language locking shift table can be configured for messages
	that have come via SMPP, do not have UDHs inside and have GSM7 encoding
	(DCS==0).
	The default GSM data coding table is mostly used. Possible values:
	= 0: default GSM data coding table
	= 13: urdu (arabic) national language shift table
	This value can be also configured at ESME level.

EXAMPLES
	smsc set nationallanguagelockingshift 0
	smsc set nationallanguagelockingshift 13
6.1.1.8.2. Using GUI
Procedure: Set National language locking shift table using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the National language locking shift table by entering the value in the text field 'National language locking shift'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.9. National language single shift table
6.1.1.9.1. Using CLI

You can set the 'National language single shift table' value by issuing the command smsc set nationallanguagesingleshift with appropriate parameters as described below. You can verify this by issuing the command smsc get nationallanguagesingleshift which will display the value set for this property.

Name
	smsc set nationallanguagesingleshift

SYNOPSIS
	smsc set nationallanguagesingleshift <NationalLanguageIdentifier>

DESCRIPTION
	National language single shift table can be configured for messages
	that have come via SMPP, do not have UDHs inside and have GSM7 encoding
	(DCS==0).
	The default GSM data coding table is mostly used. Possible values:
	= 0: default GSM data coding table
	= 13: urdu (arabic) national language shift table
	This value can be also configured at ESME level.

EXAMPLES
	smsc set nationallanguagesingleshift 0
	smsc set nationallanguagesingleshift 13
6.1.1.9.2. Using GUI
Procedure: Set National language single shift table using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the National language single shift table by entering the value in the text field 'National language single shift'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.10. Subscriber busy due delay (in sec)
6.1.1.10.1. Using CLI

You can set the 'Subscriber busy due delay (in sec)' value by issuing the command smsc set subscriberbusyduedelay with appropriate parameters as described below. You can verify this by issuing the command smsc get subscriberbusyduedelay which will display the value set for this property.

Name
	smsc set subscriberbusyduedelay

SYNOPSIS
	smsc set subscriberbusyduedelay <subscriber-busy-due-delay>

DESCRIPTION
	This command is used to set a value for subscriber-busy-due-delay (in seconds).
	This parameter specifies the delay time period in seconds when there has
	been a delivery failure with the cause 'subscriber busy'.

EXAMPLES
	smsc set subscriberbusyduedelay 2
6.1.1.10.2. Using GUI
Procedure: Set Subscriber busy due delay (in sec) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Subscriber busy due delay by entering the value in the text field 'Subscriber busy due delay (in sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.11. First due delay (in sec)
6.1.1.11.1. Using CLI

You can set the 'First due delay (in sec)' value by issuing the command smsc set firstduedelay with appropriate parameters as described below. You can verify this by issuing the command smsc get firstduedelay which will display the value set for this property.

Name
	smsc set firstduedelay

SYNOPSIS
	smsc set firstduedelay <first-due-delay>

DESCRIPTION
	This command is used to set a value for first-due-delay (in seconds). This
	parameter specifies the delay time period in seconds between message incoming time
	and first delivery attempt.

EXAMPLES
	smsc set firstduedelay 60
6.1.1.11.2. Using GUI
Procedure: Set First due delay (in sec) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the First due delay by entering the value in the text field 'First due delay (in sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.12. Second due delay (in sec)
6.1.1.12.1. Using CLI

You can set the 'Second due delay (in sec)' value by issuing the command smsc set secondduedelay with appropriate parameters as described below. You can verify this by issuing the command smsc get secondduedelay which will display the value set for this property.

Name
	smsc set secondduedelay

SYNOPSIS
	smsc set secondduedelay <second-due-delay>

DESCRIPTION
	This command is used to set a value for second-due-delay (in seconds). This
	parameter specifies the delay time period in seconds between the first and second
	delivery attempt (i.e. if the first delivery attempt failed).

EXAMPLES
	smsc set secondduedelay 5
6.1.1.12.2. Using GUI
Procedure: Set Second due delay (in sec) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Second due delay by entering the value in the text field 'Second due delay (in sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.13. Max due delay (in sec)
6.1.1.13.1. Using CLI

You can set the 'Max due delay (in sec)' value by issuing the command smsc set maxduedelay with appropriate parameters as described below. You can verify this by issuing the command smsc get maxduedelay which will display the value set for this property.

Name
	smsc set maxduedelay

SYNOPSIS
	smsc set maxduedelay <maxduedelay>

DESCRIPTION
	This command is used to set a value for max-due-delay (in seconds). This parameter
	specifies the maximum possible delay time period in seconds between delivery
	attempts.

EXAMPLES
	smsc set maxduedelay 3600
6.1.1.13.2. Using GUI
Procedure: Set Max due delay (in sec) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Max due delay by entering the value in the text field 'Max due delay (in sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.14. Due delay multiplicator
6.1.1.14.1. Using CLI

You can set the 'Due delay multiplicator' value by issuing the command smsc set duedelaymultiplicator with appropriate parameters as described below. You can verify this by issuing the command smsc get duedelaymultiplicator which will display the value set for this property.

Name
	smsc set duedelaymultiplicator

SYNOPSIS
	smsc set duedelaymultiplicator <due-delay-multiplicator>

DESCRIPTION
	This command is used to set a value for due-delay-multiplicator. This parameter
	specifies the delay multiplicator value before another delivery attempt (after
	failure) is made.

	After a message delivery failure (if message validity period is not over and the
	failure is temporary), a delay period is induced before the next delivery attempt.
	This delay period is calculated as follows:

	Delay after the first delivery failure =
				second-due-delay

	Delay after every consecutive delivery failure =
				prev-due-delay * due-delay-multiplicator / 100
			        where prev-due-delay is the delay at the previous step.

EXAMPLES
	smsc set duedelaymultiplicator 200

	Lets take an example where the First due delay is 60 seconds, Second due delay is
	300 seconds, and the due-delay-multiplicator is 200, the attempts will be made
	as below:

	First attempt will be after 60 seconds (1 min)
	[delay is configured in First due delay]

	Second attempt will be after 300 seconds (5 min)
	[delay is configured in Second due delay assuming
	delivery failed not because of "Subscriber busy"]

	Third attempt will be after 600 sec (10 min)
	[delay is calculated based on Due delay multiplicator]
	Delay = 300 * 200 / 100	= 600

	Fourth attempt will be after 1200 sec (20 min)
	[delay is calculated based on Due delay multiplicator]
	Delay = 600 * 200 / 100	= 1200

	Fifth attempt will be after 2400 sec (40 min)
	[delay is calculated based on Due delay multiplicator]
	Delay = 1200 * 200 / 100 = 2400
6.1.1.14.2. Using GUI
Procedure: Set Due delay multiplicator using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Due delay multiplicator by entering the value in the text field 'Due delay multiplicator'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.1.15. Validity period scheduling prolongation
6.1.1.15.1. Using CLI

You can set the 'Validity period scheduling prolongation (sec)' value by issuing the command smsc set vpprolong with appropriate parameters as described below. You can verify this by issuing the command smsc get vpprolong which will display the value set for this property.

Name
	smsc set vpprolong

SYNOPSIS
	smsc set vpprolong <vpprolong>

DESCRIPTION
	This command is used to set the value of Validity period scheduling
	prolongation in seconds.
	Conditions when a message with validity period will be scheduled after delivery
	failure:
	a) validity period end time >= the time for next schedule time
	or
	b) validity period end time >= now + Validity period scheduling prolongation
	By changing of "Validity period scheduling prolongation" you can specify will
	a message be scheduled after validity period end time or not.
	Setting this parameter to 0 lead that all messages will be scheduled.
	Setting this parameter to a very big value lead that no message will be scheduled.
	The general rule is - you can allow messages to be scheduled for after validity
	period end time when scheduling is for for after long time from now.
	Default value: 120 (seconds).

EXAMPLES
	smsc set vpprolong 120
6.1.1.15.2. Using GUI
Procedure: Set Validity period scheduling prolongation using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Properties' tab in the GUI.

  3. You can specify the Validity period scheduling prolongation by entering the value in the text field 'Validity period scheduling prolongation (sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2. SS7 Settings

6.1.2.1. SMSC Gateway Global Title
6.1.2.1.1. Using CLI

You can set the 'SMSC Gateway Global Title' by issuing the command smsc set scgt with appropriate parameters as described below. You can verify this by issuing the command smsc get scgt which will display the value set for this property.

Name
        smsc set scgt

SYNOPSIS
        smsc set scgt <globalTitle> networkid <networkId>

DESCRIPTION
        This command is used to set a value for SMSC Global Title.

        networkId - a specifies Global Title for a virtual SS7
        subnetwork (this is for Multi-tenancy support). By using of
        this command with different networkIds you can specify
        Global Titles for several subnetworks.
        If this parameter is skipped - networkId will be set to "0"
        when Global Title creation (master networkId).
        When we do not specify Global Title for some networkid -
        Global Title for master networkId will be used. When we
        use "0" as Global Title value
        (like "smsc set scgt 0 networkid <xxx>") -
        this will just clear Global Title for an specified networkid.
6.1.2.1.2. Using GUI
Procedure: Set SMSC Global Title using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the SMSC Global Title by entering values into fields pair 'SMSC Gateway Global Title Indicator Network Id' and 'SMSC Gateway Global Title'. You are able to set Global Title for definite networkId. Setting of Global Title for networkId to "0" leads clearing of Global Title for networkId. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.2. SMSC Gateway Global Title Indicator
6.1.2.2.1. Using CLI

You can set the 'SMSC Gateway Global Title Indicator' by issuing the command smsc set gti with appropriate parameters as described below. You can verify this by issuing the command smsc get gti which will display the value set for this property.

Name
        smsc set gti

SYNOPSIS
        smsc set gti 0001|0010|0011|0100

DESCRIPTION
        This command is used to set the value of SMSC Gateway Global Title
        Indicator.
        This Global Title Indicator will be used for SCCP outgoing messages.
        Default value for ITU-T is 0100.
        Global title 0001 - Nature of address indicator included
        Global title 0010 - Translation type included
        Global title 0011 - Translation type, Numbering plan and Encoding
                            scheme included
        Global title 0100 - Translation type, Numbering plan, Encoding
                            scheme and Nature of address indicator included
6.1.2.2.2. Using GUI
Procedure: Set SCCP Global Title type using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the SCCP Global Title type by entering the value in the text field 'SMSC Gateway Global Title Indicator'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.3. SMSC Gateway Global Title - Translation Type
6.1.2.3.1. Using CLI

You can set the 'SMSC Gateway Global Title - Translation Type' by issuing the command smsc set tt with appropriate parameters as described below. You can verify this by issuing the command smsc get tt which will display the value set for this property.

Name
        smsc set tt

SYNOPSIS
        smsc set tt <translation type value>

DESCRIPTION
        This command is used to set the value of SCCP translation type
        value. Translation type value will be used for SCCP outgoing
        messages. Default value for ITU-T is 0.
6.1.2.3.2. Using GUI
Procedure: Set SCCP translation type value using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the SCCP translation type value by entering the value in the text field 'SMSC Gateway Global Title - Translation Type'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.4. SMSC Sub System Number (SSN)
6.1.2.4.1. Using CLI

You can set the 'SMSC SSN' by issuing the command smsc set scssn with appropriate parameters as described below. You can verify this by issuing the command smsc get scssn which will display the value set for this property.

Name
        smsc set scssn

SYNOPSIS
        smsc set scssn <smscSubSystemNumber>

DESCRIPTION
        This command is used to set the value of SMSC Sub System Number (SSN). Issuing
        this command in CLI will set the SSN value but you must ensure that the SSN number
        is properly configured in the TCAP Stack in the xml descriptor file
        "mobicents-smscgateway-version/jboss-5.1.0.GA/server/default/deploy/
        mobicents-smsc-server/META-INF/jboss-beans.xml".
6.1.2.4.2. Using GUI
Procedure: Set SMSC Sub System Number (SSN) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the SMSC Sub System Number (SSN) by entering the value in the text field 'SMSC Gateway subsystem number'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.5. HLR Sub System Number (HLR SSN)
6.1.2.5.1. Using CLI

You can set the 'HLR SSN' by issuing the command smsc set hlrssn with appropriate parameters as described below. You can verify this by issuing the command smsc get hlrssn which will display the value set for this property.

Name
        smsc set hlrssn

SYNOPSIS
        smsc set hlrssn <hlrSubSystemNumber>

DESCRIPTION
        This command is used to set the value of HLR Sub System Number (SSN).
6.1.2.5.2. Using GUI
Procedure: Set HLR Sub System Number (SSN) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the HLR Sub System Number (SSN) by entering the value in the text field 'HLR subsystem number'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.6. MSC Sub System Number (SSN)
6.1.2.6.1. Using CLI

You can set the 'MSC SSN' by issuing the command smsc set mscssn with appropriate parameters as described below. You can verify this by issuing the command smsc get mscssn which will display the value set for this property.

Name
        smsc set mscssn

SYNOPSIS
        smsc set mscssn <mscSubSystemNumber>

DESCRIPTION
        This command is used to set the value of MSC Sub System Number (SSN).
6.1.2.6.2. Using GUI
Procedure: Set MSC Sub System Number (SSN) using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the MSC Sub System Number (SSN) by entering the value in the text field 'MSC subsystem number'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.7. MAP Application Context version
6.1.2.7.1. Using CLI

You can set the 'MAP Application Context version' by issuing the command smsc set maxmapv with appropriate parameters as described below. You can verify this by issuing the command smsc get maxmapv which will display the value set for this property.

Name
        smsc set maxmapv

SYNOPSIS
        smsc set maxmapv <version-number>

DESCRIPTION
        This command is used to set the value of MAP Application Context version. The
        version number set here will be used for SMS messages exchanged. RestComm SMSC
        Gateway supports version negotiation. So if you set this to a higher version (say
        for example version 3, however your network only understands version 2), the SMSC Gateway
        will automatically do the version negotiation and exchange V2 messages when V3
        exchange fails. However this causes additional messages to be exchanged and
        increases the overall load on the system. Therefore it is advisable to always set
        the correct version.
6.1.2.7.2. Using GUI
Procedure: Set MAP Application Context version using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the MAP Application Context version by entering the value in the text field 'MAP version supported'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.8. Max Message Length Reducer
6.1.2.8.1. Using CLI

You can set the 'Max Message Length Reducer' value by issuing the command smsc set maxmessagelengthreducer with appropriate parameters as described below. You can verify this by issuing the command smsc get maxmessagelengthreducer which will display the value set for this property.

Name
	smsc set maxmessagelengthreducer

SYNOPSIS
	smsc set maxmessagelengthreducer <max-message-length-reducer>

DESCRIPTION
	This command is used to set an integer value for max-message-length-reducer.
	The recommended value is 6. Possible values are numbers from 0 to 12.

	Empty TC-BEGIN will be used if the message length is greater than the maximum
	possible message length minus the value specified for max-message-length-reducer.

	(message-length > max-possible-message-length - max-message-length-reducer)

	Empty TC-BEGIN is used in MAP Version 2 and 3 for forwardSM and Mt-ForwardSM
	requests. In MAP Version 2 the dailog portion
	(ApplicationContextName, MAPOpenInfo primitive) and the component portion
	(forwardSM and mt-ForwardSM requests) may both together be too long to fit within
	a MTP message. In Empty TC-BEGIN case, it first sends the dailog portion in
	TC-BEGIN followed by the component portion in the next TC-CONTINUE.
	Whether empty TC-BEGIN is used or not depends on the length of a message and the
	length of SCCP addresses. This option increases the guarantee of delivery of a
	message  to some network.

EXAMPLES
	smsc set maxmessagelengthreducer 6
6.1.2.8.2. Using GUI
Procedure: Set Max Message Length Reducer using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify the Max Message Length Reducer by entering the value in the text field 'Max Message Length Reducer'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.9. Pre-configured HLR address for SRI requests
6.1.2.9.1. Using CLI

You can set a pre-configured HLR address for SRI requests by issuing the command smsc set hrhlrnumber with appropriate parameters as described below. You can remove this pre-configured address by issuing the command smsc remove hrhlrnumber. You can verify this by issuing the command smsc get hrhlrnumber which will display the value set for this property.

Name
	smsc set hrhlrnumber
	smsc remove hrhlrnumber

SYNOPSIS
	smsc set hrhlrnumber <hlr GT digits> networkid <networkId>
	smsc remove hrhlrnumber networkid <networkId>

DESCRIPTION
	This command is used to set a pre-configured HLR address for SRI requests.

	In some scenarios it may be required to set a HLR address instead of a
	MSISDN address into the SCCP 'CalledPartyAddress' of 'SendRoutingInfo'
	requests issued by the SMSC GW in both mobile terminated and home routing
	modes. In such cases, you must set this parameter 'hrhlrnumber' to a
	pre-configured HLR address.

	For all other scenarios where this is not required, you may leave this
	parameter empty. When this is empty, the SCCP 'CalledPartyAddress' of
	'SendRoutingInfo' request will be set to the destination MSISDN of a
	subscriber.

	networkId - specifies a virtual SS7 subnetwork (this is for Multi-tenancy
	support). By using of this command with different networkIds you can
	specify hrhlrnumber for several subnetworks.
	If this parameter is skipped - networkId will be set to "0".
6.1.2.9.2. Using GUI
Procedure: Set Pre-configured HLR address for SRI requests using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify (set or remove) the "Pre-configured HLR address for SRI requests" by entering appropriate values for a specified networkID. Select needed "Pre-configured HLR address for SRI requests Network Id" field value or type a new networkId value if no such value already specifyied. Then type needed HLR address into below field. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.2.10. SRI responses Cache Time (in secs)
6.1.2.10.1. Using CLI

You can set a SRI responses Cache Time by issuing the command smsc set sriresponselivetime with appropriate parameters as described below. You can verify this by issuing the command smsc get sriresponselivetime which will display the value set for this property.

Name
	smsc set sriresponselivetime

SYNOPSIS
	smsc set sriresponselivetime <time in seconds>

DESCRIPTION
	This command is used to set a SRI responses Cache Time.

	SMSC GW can store successfull SendRoutinInfo (SRI) responses (with IMSI and
	NetworkNodeNumber data) into an internal cach for some configurable time.
	SMSC GW	parameter "sriresponselivetime" specifies the minimum time value
	for storing of a response. Caching of SRI responses takes some system
	resources and is recommended only if you need it for some scenarious (like
	you send firstly only an SRI request and do not deliver a message just to
	understend IMSI / NetworkNodeNumber (this scenario is achieavable by mproc
	rules) and then send a message in short time if needed).

DEFAULT VALUE
	0 - this means no caching.

EXAMPLES
	smsc set sriresponselivetime 0
6.1.2.10.2. Using GUI
Procedure: Set SRI responses Cache Time using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'SS7 Settings' tab in the GUI.

  3. You can specify (set or remove) the "SRI responses Cache Time (in secs)" by entering appropriate values. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3. Cassandra Settings

You can manage Cassandra Settings using the CLI or GUI. Note that the modified settings will become effective only when the SMSC is re-started.

6.1.3.1. Cassandra Configuration - Host Addresses
6.1.3.1.1. Using CLI

You can set the 'host addresses' value for Cassandra settings by issuing the command smsc set dbhosts with appropriate parameters as described below. You can verify this by issuing the command smsc get dbhosts which will display the value set for this property.

Name
	smsc set dbhosts

SYNOPSIS
	smsc set dbhosts <host-ip>

DESCRIPTION
	This command is used to set the host-ip addresses for Cassandra Database access.

EXAMPLES
	smsc set dbhosts 127.0.0.1
6.1.3.1.2. Using GUI
Procedure: Set Cassandra Configuration - Host Addresses using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the host-ip address by entering appropriate values in the text field 'Host Address'. For more details of these parameters, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.2. Cassandra Configuration - Port
6.1.3.2.1. Using CLI

You can set the 'port' value for Cassandra settings by issuing the command smsc set dbport with appropriate parameters as described below. You can verify this by issuing the command smsc get dbport which will display the value set for this property.

Name
    smsc set dbport

SYNOPSIS
    smsc set dbport <port>

DESCRIPTION
	This command is used to set the host-ip address for Cassandra Database
	access. Pass comma separated values if Cassandra is setup in cluster
	and can be accessed via multiple IP's

EXAMPLES
    smsc set dbport 9042
6.1.3.2.2. Using GUI
Procedure: Set Cassandra Configuration - Port using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the host-ip address and port by entering appropriate values in the text field 'Port'. For more details of these parameters, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.3. Cassandra Configuration - Keyspace Name
6.1.3.3.1. Using CLI

You can set the 'DB Keyspace Name' by issuing the command smsc set keyspacename with appropriate parameters as described below. You can verify this by issuing the command smsc get keyspacename which will display the value set for this property.

Name
	smsc set keyspacename

SYNOPSIS
	smsc set keyspacename <keyspacename>

DESCRIPTION
	This command is used to set the Keyspace name for Cassandra Database. If you use
	the script available in the distributive the name will be set to 'RestCommSMSC' by
	default.
6.1.3.3.2. Using GUI
Procedure: Set Cassandra Configuration - Keyspace Name using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the Keyspace Name by entering the value in the text field 'Keyspace Name'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.4. Cassandra Configuration - Cluster Name
6.1.3.4.1. Using CLI

You can set the 'DB Cluster Name' value by issuing the command smsc set clustername with appropriate parameters as described below. You can verify this by issuing the command smsc get clustername which will display the value set for this property.

Name
	smsc set clustername

SYNOPSIS
	smsc set clustername <cluster-name>

DESCRIPTION
	This command is used to set the Cluster name for Cassandra Database. If you use
	the script available in the distributive the name will be set to 'RestCommSMSC' by
	default.

EXAMPLES
	smsc set clustername RestCommSMSC
6.1.3.4.2. Using GUI
Procedure: Set Cassandra Configuration - Cluster Name using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the Cluster Name by entering the value in the text field 'Cluster Name'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.5. Cassandra Configuration - User Name
6.1.3.5.1. Using CLI

You can set the 'Cassandra User Name' by issuing the command smsc set cassandrauser with appropriate parameters as described below. You can verify this by issuing the command smsc get cassandrauser which will display the value set for this property.

Name
	smsc set cassandrauser

SYNOPSIS
	smsc set cassandrauser <username>

DESCRIPTION
	This command is used to set the user name for Cassandra Database. Default user is `cassandra`
	You must restart SMSC GW to take effect.
6.1.3.5.2. Using GUI
Procedure: Set Cassandra Configuration - User Name using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the User Name by entering the value in the text field 'User Name'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.6. Cassandra Configuration - Password
6.1.3.6.1. Using CLI

You can set the 'Cassandra Password' by issuing the command smsc set cassandrapass with appropriate parameters as described below. You can verify this by issuing the command smsc get cassandrapass which will display the value set for this property.

Name
	smsc set cassandrapass

SYNOPSIS
	smsc set cassandrapass <password>

DESCRIPTION
	This command is used to set the password for Cassandra Database. Default password is `cassandra`
	You must restart SMSC GW to take effect.
6.1.3.6.2. Using GUI
Procedure: Set Cassandra Configuration - Password using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the Cassandra Password by entering the value in the text field 'Password'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.7. Cassandra Configuration - Removing Live Tables Days
6.1.3.7.1. Using CLI

You can set the 'Removing Live Tables Days' value by issuing the command smsc set removinglivetablesdays with appropriate parameters as described below. You can verify this by issuing the command smsc get removinglivetablesdays which will display the value set for this property.

Name
	smsc set removinglivetablesdays

SYNOPSIS
	smsc set removinglivetablesdays <value>

DESCRIPTION
	This command is used to configure the SMSC to automatically drop LIVE tables from
	the Cassandra Database. The SMSC will attempt to delete tables just after
	midnight and after every SMSC restart.

PARAMETERS
	removinglivetablesdays		- This parameter is used to specify the number
					  of days the LIVE tables should be kept before
					  attempting to drop them automatically.

					  If this value is specified as "0", the SMSC
					  will not drop tables automatically. In this case
					  you must manually drop tables.

					  You must specify a value of 3 or more. You can
					  not set this value to 1 or 2 days. This is to
					  ensure the tables will be kept for a minimum
					  of 2 days after creation date.

					  The SMSC wil attempt to delete tables for one
					  day. If the Cassandra Database keeps tables for
					  older days, then the administrator should drop
					  these manually.
6.1.3.7.2. Using GUI
Procedure: Set Cassandra Configuration - Removing Live Tables Days
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the Removing Live Tables Days by entering the value in the text field 'Removing Live Tables Days'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.3.8. Cassandra Configuration - Removing Live Tables Days
6.1.3.8.1. Using CLI

You can set the 'Removing Live Tables Days' value by issuing the command smsc set removingarchivetablesdays with appropriate parameters as described below. You can verify this by issuing the command smsc get removingarchivetablesdays which will display the value set for this property.

Name
	smsc set removingarchivetablesdays

SYNOPSIS
	smsc set removingarchivetablesdays <value>

DESCRIPTION
	This command is used to configure the SMSC to automatically drop ARCHIVE tables
	from the Cassandra Database. The SMSC will attempt to delete tables just after
	midnight and after every SMSC restart.

PARAMETERS
	removingarchivetablesdays	- This parameter is used to specify the number
					  of days the ARCHIVE tables should be kept before
					  attempting to drop them automatically.

					  If this value is specified as "0", the SMSC
					  will not drop tables automatically. In this case
					  you must manually drop tables.

					  You must specify a value of 3 or more. You can
					  not set this value to 1 or 2 days. This is to
					  ensure the tables will be kept for a minimum
					  of 2 days after creation date.

					  The SMSC wil attempt to delete tables for one
					  day. If the Cassandra Database keeps tables for
					  older days, then the administrator should drop
					  these manually.
6.1.3.8.2. Using GUI
Procedure: Set Cassandra Configuration - Removing Archive Tables Days
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Cassandra' tab in the GUI.

  3. You can specify the Removing Archive Tables Days by entering the value in the text field 'Removing Archive Tables Days'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4. Scheduler Settings

You can modify Scheduler settings using the CLI or GUI. The modified settings for Fetch Period will become effective only when the SMSC is re-started. However modified settings for Max Rows and Max Activity Count will take effect immediately.

6.1.4.1. Fetch Period (in ms)
6.1.4.1.1. Using CLI

You can set the 'Fetch Period' value by issuing the command smsc set fetchperiod with appropriate parameters as described below. You can verify this by issuing the command smsc get fetchperiod which will display the value set for this property.

Name
	smsc set fetchperiod

SYNOPSIS
	smsc set fetchperiod <fetch-period>

DESCRIPTION
	This command is used to set the fetch period value in milli-seconds for the
	Cassandra database. The parameter fetch-period specifies the time
	period (in milli-seconds) of fetching messages for delivery from the database.
	The default value is 5 seconds.

EXAMPLES
	smsc set fetchperiod 5000
6.1.4.1.2. Using GUI
Procedure: Set Cassandra Configuration - Cluster Name using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the Fetch Period by entering the value in the text field 'Fetch Period (in ms)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.2. Max Rows
6.1.4.2.1. Using CLI

You can set the 'Max Rows' value by issuing the command smsc set fetchmaxrows with appropriate parameters as described below. You can verify this by issuing the command smsc get fetchmaxrows which will display the value set for this property.

Name
	smsc set fetchmaxrows

SYNOPSIS
	smsc set fetchmaxrows <fetch-max-rows>

DESCRIPTION
	This command is used to set the maximum message fetching count for every fetching
	step from the database.
	The default value is 100 messages.

EXAMPLES
	smsc set fetchmaxrows 200
6.1.4.2.2. Using GUI
Procedure: Set Max Rows using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the Max Rows by entering the value in the text field 'Max Rows'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.3. Max Activity Count
6.1.4.3.1. Using CLI

You can set the 'Max Activity Count' value by issuing the command smsc set maxactivitycount with appropriate parameters as described below. You can verify this by issuing the command smsc get maxactivitycount which will display the value set for this property.

Name
	smsc set maxactivitycount

SYNOPSIS
	smsc set maxactivitycount <max-activity-count>

DESCRIPTION
	This command is used to set the maximum count of delivering activities that are
	possible at the same time. 'Count of delivering activities' means the count of
	messages that are in the state 'delivering' (messages that are fetched from the
	database and may be already sent or are going to be sent but
	no delivery acception/rejection has been received).
	When the delivery process of a message is in progress, field LIVE.IN_SYSTEM==2.

EXAMPLES
	smsc set maxactivitycount 500
6.1.4.3.2. Using GUI
Procedure: Set Max Activity Count using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the Max Activity Count by entering the value in the text field 'Max Activity Count'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.4. Revise period after SMSC restart
6.1.4.4.1. Using CLI

You can set the 'Revise period (in seconds) after SMSC restart' value by issuing the command smsc set revisesecondsonsmscstart with appropriate parameters as described below. You can verify this by issuing the command smsc get revisesecondsonsmscstart which will display the value set for this property. If unspecified, the default value for this parameter is 60 seconds.

Name
	smsc set revisesecondsonsmscstart <seconds>

SYNOPSIS
	smsc set revisesecondsonsmscstart <seconds>

DESCRIPTION
	This command is used to set the revise period (in seconds). After every restart,
	the SMSC Gateway will revise the last 'x' seconds before shutdown to ensure that
	all the arrived messages are processed; where 'x' is the value set in seconds
	for the parameter 'revisesecondsonsmscstart' using this command.
EXAMPLES
	smsc set revisesecondsonsmscstart 30
6.1.4.4.2. Using GUI
Procedure: Set Revise Period using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the revise period in seconds by entering the value in the text field 'Revise period after SMSC restart (sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.5. Cache timeout period
6.1.4.5.1. Using CLI

You can set the 'Cache timeout period' value by issuing the command smsc set processingsmssettimeout with appropriate parameters as described below. You can verify this by issuing the command smsc get processingsmssettimeout which will display the value set for this property. If unspecified, the default value for this parameter is 600 seconds. Generally, you may not have to modify this value.

Name
	smsc set processingsmssettimeout <seconds>

SYNOPSIS
	smsc set processingsmssettimeout <seconds>

DESCRIPTION
	This command is used to set the Cache timeout period (in seconds).
	Messages are cached in the SMSC until the processing is completed. In case of a
	delivery failure, these cached messages are force cleaned by the SMSC after
	waiting for the timeout period set for the parameter 'processingsmssettimeout'
	using this command.
EXAMPLES
	smsc set processingsmssettimeout 45
6.1.4.5.2. Using GUI
Procedure: Set Cache timeout Period using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the Cache timeout period in seconds by entering the value in the text field 'Processing Sms set cache timeout (sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.6. Delivery timeout
6.1.4.6.1. Using CLI

You can set the 'Delivery timeout' value by issuing the command smsc set deliverytimeout with appropriate parameters as described below. You can verify this by issuing the command smsc get deliverytimeout which will display the value set for this property. If unspecified, the default value for this parameter is 600 seconds. Generally, you may not have to modify this value.

Name
	smsc set deliverytimeout

SYNOPSIS
	smsc set deliverytimeout <delivery-timeout>

DESCRIPTION
	This command is used to set a length of delivery process timeout
	in seconds. Timeout occurs if no actions for delivering (delivery confirmation
	or a new item delivery) for long time). If the timeout occurs SMSC GW will
	terminate delivery process.
	Default value: 120 seconds.

EXAMPLES
	smsc set deliverytimeout 120
6.1.4.6.2. Using GUI
Procedure: Set Delivery timeout using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. You can specify the Delivery timeout in seconds by entering the value in the text field 'Delivery timeout (sec)'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.4.7. Skipping of scheduled for the past and not yet sent messages ("In process" due_slot shifting).
6.1.4.7.1. Using CLI

This command will skip of processing / fetching of messages that was scheduled for delivering for the time in the past but have not yet delivered by SMSC GW because of SMSC GW was turned off or overloaded. <time in seconds> means the point of the time (actual current time - <time in seconds>) to which the point of processing / fetching of messages will be shifted. If the value "0" is provided this means SMSC GW will be shifted into an actual (current) time ("in process" due_slot will be shifted to "in time" due_slot). If the value is positive this means SMSC GW "in process" due_slot will be shifted into a some time in the past (for example if the value is 3600 - to the time before the current time ("in time" due_slot) for 1 hour). Negative values are not accepted. "In process" due_slot can be shifted only forward. It is not possible to shift "in process" due_slot backward (and resend messages that was already sent once).

Name
    smsc skipunsentmessages

SYNOPSIS
    smsc skipunsentmessages <time in seconds>

DESCRIPTION
	Executing of this command leads SMSC GW to switch "In process" due_slot
	forward to the current time or to some time before the current time.
	This is possible only if there is some lag in message processing by
	SMSC GW. This also leads of skipping of sending messages that were
	scheduled for time in the past but have not delivered so far.

EXAMPLES
	smsc skipunsentmessages 0
6.1.4.7.2. Using GUI
Procedure: Skipping of scheduled for the past and not yet sent messages ("In process" due_slot shifting) by the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Scheduler' tab in the GUI.

  3. Set "Skip Unsent Messages (in sec) " field to 0 or positive value.

  4. You must click on the button 'Save' that is below to skip scheduled messages. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5. Diameter Settings

You can modify Diameter settings using the CLI or GUI.

6.1.5.1. Destination Realm
6.1.5.1.1. Using CLI

You can set the 'Destination Realm' value by issuing the command smsc set diameterdestrealm with appropriate parameters as described below. You can verify this by issuing the command smsc get diameterdestrealm which will display the value set for this property.

Name
	smsc set diameterdestrealm

SYNOPSIS
	smsc set diameterdestrealm <value>

DESCRIPTION
	This command is used to set the Diameter Destination Realm for connection to OCS.
	Default value is "mobicents.org".

EXAMPLES
	smsc set diameterdestrealm mobicents.org
6.1.5.1.2. Using GUI
Procedure: Set Diameter Destination Realm using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can specify the Destination Realm by entering the value in the corresponding text field. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.2. Destination Host
6.1.5.2.1. Using CLI

You can set the 'Destination Host' value by issuing the command smsc set diameterdesthost with appropriate parameters as described below. You can verify this by issuing the command smsc get diameterdesthost which will display the value set for this property.

Name
	smsc set diameterdesthost

SYNOPSIS
	smsc set diameterdesthost <value>

DESCRIPTION
	This command is used to set the Diameter Destination Host for connection to OCS.
    Default value is "127.0.0.1".

EXAMPLES
	smsc set diameterdesthost 127.0.0.1
6.1.5.2.2. Using GUI
Procedure: Set Diameter Host using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can specify the Destination Host by entering the value in the corresponding text field. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.3. Destination Port
6.1.5.3.1. Using CLI

You can set the 'Destination Port' value by issuing the command smsc set diameterdestport with appropriate parameters as described below. You can verify this by issuing the command smsc get diameterdestport which will display the value set for this property.

Name
	smsc set diameterdestport

SYNOPSIS
	smsc set diameterdestport <value>

DESCRIPTION
	This command is used to set the Diameter Destination Port for connection to OCS.
    Default value is 3868.

EXAMPLES
	smsc set diameterdestport 3868
6.1.5.3.2. Using GUI
Procedure: Set Diameter Port using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can specify the Destination Port by entering the value in the corresponding text field. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.4. Destination Username
6.1.5.4.1. Using CLI

You can set the 'Destination Username' value by issuing the command smsc set diameterusername with appropriate parameters as described below. You can verify this by issuing the command smsc get diameterusername which will display the value set for this property.

Name
	smsc set diameterusername

SYNOPSIS
	smsc set diameterusername <value>

DESCRIPTION
	This command is used to set the Diameter Username for connection to OCS.

EXAMPLES
	smsc set diameterdestusername svinu
6.1.5.4.2. Using GUI
Procedure: Set Diameter Username using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can specify the Username by entering the value in the corresponding text field. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.5. MO accepting and charging settings
6.1.5.5.1. Using CLI

You can set the 'MO (mobile originated) Charging' value by issuing the command smsc set mocharging with appropriate parameters as described below. You can verify this by issuing the command smsc get mocharging which will display the value set for this property.

Name
	smsc set mocharging

SYNOPSIS
	smsc set mocharging <accept|reject|diameter>

DESCRIPTION
    This command is used to set the value of the parameter 'moCharging' to
    an appropriate value. This value is set to "accept" by default.
    - accept - all Mobile Originated messages are accepted
    - reject - all Mobile Originated messages are rejected
    - diameter - all Mobile Originated messages are charged by OCS via
      Diameter, prior to being sent

EXAMPLES
	smsc set mocharging accept
6.1.5.5.2. Using GUI
Procedure: Set MO Charge using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can set 'Mobile Originated SMS Charged' value to true or false, in the corresponding list. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.6. ESME Charge Settings
6.1.5.6.1. Using CLI

You can set the 'ESME Originated SMS Charged' value by issuing the command smsc set txsmppcharging with appropriate parameters as described below. You can verify this by issuing the command smsc get txsmppcharging which will display the value set for this property.

Name
	smsc set txsmppcharging

SYNOPSIS
	smsc set txsmppcharging <None|Selected|All>

DESCRIPTION
	This command is used to set the value of the parameter 'txsmppcharging' to None,
	Selected or All.

	If this is set to 'Aall', all ESME Originated messages will be charged by OCS via
	Diameter, prior to being sent.

	If this is set to 'Selected', only those messages originating from ESMEs marked
	with the parameter 'charging-enabled'=true at the time of ESME creation  will be
	charged by OCS via Diameter, prior to being sent.

	If this is set to 'None', none of the ESME Originated messages will be charged by
	OCS via Diameter, prior to being sent.

	The parameter 'txsmppcharging' is set to 'None' by default.

EXAMPLES
	smsc set txsmppcharging Selected
6.1.5.6.2. Using GUI
Procedure: Set ESME Charge using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can set 'ESME Originated SMS Charged' value to none, selected or all, in the corresponding list. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.7. SIP Charge Settings
6.1.5.7.1. Using CLI

You can set the 'SIP Originated SMS Charged' value by issuing the command smsc set txsipcharging with appropriate parameters as described below. You can verify this by issuing the command smsc get txsipcharging which will display the value set for this property.

Name
    smsc set txsipcharging

SYNOPSIS
    smsc set txsipcharging <None|Selected|All>

DESCRIPTION
	This command is used to set the value of the parameter 'txsipcharging'

	If this is set to 'All', all SIP Originated messages will be charged by OCS via
	Diameter, prior to being sent.

	If this is set to 'None' or 'Selected', none of the SIP Originated messages will
	be charged by OCS via Diameter, prior to being sent.

    The parameter 'txsipcharging' is set to 'None' by default.

EXAMPLES
    smsc set txsipcharging Selected
6.1.5.7.2. Using GUI
Procedure: Set SIP Charge using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can set 'SIP Originated SMS Charged' value to none, selected or all, in the corresponding list. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.8. Home routing Charge Settings
6.1.5.8.1. Using CLI

You can set the 'Home routing Originated SMS Charged' value by issuing the command smsc set hrcharging with appropriate parameters as described below. You can verify this by issuing the command smsc get hrcharging which will display the value set for this property.

Name
    smsc set hrcharging

SYNOPSIS
    smsc set hrcharging <accept|reject|diameter>

DESCRIPTION
    This command is used to set the value of the parameter 'hrcharging' to
    an appropriate value. This value is set to "accept" by default. This
    option works like mocharging option but affects on SS7 messages in home
    routing mode from upper SMSC (mocharging affects on mobile originated
    SS7 incoming messages).
    - accept - all Home Routing originated messages are accepted
    - reject - all Home Routing originated messages are rejected
    - diameter - all Home Routing Originated messages are charged by OCS via
      Diameter, prior to being sent

EXAMPLES
    smsc set hrcharging accept
6.1.5.8.2. Using GUI
Procedure: Set Home Routing Charge using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can set 'Home Routed SMS Charged' value to none, selected or all, in the corresponding list. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.5.9. HTTP Charge Settings
6.1.5.9.1. Using CLI

You can set the 'HTTP Originated SMS Charged' value by issuing the command smsc set txhttpcharging with appropriate parameters as described below. You can verify this by issuing the command smsc get txhttpcharging which will display the value set for this property.

Name
	smsc set txhttpcharging

SYNOPSIS
	smsc set txhttpcharging <accept|reject|diameter>

DESCRIPTION
	This command is used to set the value of the parameter 'txHttpCharging' to
	needed values (accepting of messages that come from a HTTP connector).
	This value is set to accept by default.

	If this is set to
	accept - all incoming messages are accepted without charging
	reject - all incoming messages will be rejected
	diameter - all incoming messages are checked by Diameter peer before delivering
	(this option is not supported now)

EXAMPLES
	smsc set txhttpcharging accept
6.1.5.9.2. Using GUI
Procedure: Set HTTP originated Charge using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Diameter' tab in the GUI.

  3. You can set 'HTTP originated SMS Charged' value to accept, reject or diameter, in the corresponding list. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.6. Home Routing Settings

Restcomm SMSC Gateway supports Non Transparent Home Routing as explained in 3GPP 23.840 5.2.3. This option can be disabled by setting "hrcharging" option to "reject" (see Home routing Charge Settings). SMSC GW will accept SendRoutinInfo requests from a remote SMSC, then create a unique "correlationId" value for a requested MSISDN, then send SendRoutinInfo request to HLR, store received by HLR info into a cache and sends back to the remote SMSC SendRoutinInfo response with "correlationId" value in IMSI field and SMSC GlobalTytle (or another special configured GlobalTytle value) in LocationInfo field. Then SMSC GW will accept MtForwardSM messages from the remote SMSC, seaches in the cache for "correlationId" and HLR subscriber’s and use this data for processing a message further.

6.1.6.1. Correlation table CC and MCC-MNC for home routing mode managing.

For home routing mode we may need to fill a special table for correlation between CC (CountryCodes) of incoming MSISDN address and MCC-MNC prefix of a generated correlationId value. CorrelationId value will be returned as IMSI in SRI response to an upper SMSC GW. As an extra field "smsc" field can be specified for each entry of this table. If this field is specified and not empty then this value will be returned as a LocationInfo in SRI response to an upper SMSC GW, else SMSC GW address will be returned. Correlation table is stored into "jboss-5.1.0.GA/server/<server instanse, for example 'default'>"/data" and has name "SmscManagement_cc_mccmnc.xml". The content of this should follow the following template:

<?xml version="1.0" encoding="UTF-8" ?>
  <CcMccmncCollection>
  <ccMccmncList>
    <ccMccmnc countryCode="0111" mccMnc="77702"/>
    <ccMccmnc countryCode="0222" mccMnc="9999999"/>
    <ccMccmnc countryCode="02" mccMnc="8888888" smsc="06060606"/>
    <ccMccmnc countryCode="" mccMnc="22323"/>
  </ccMccmncList>
</CcMccmncCollection>

The file structure consists on one or several instances of countryCode / mccMnc pairs. When SMSC GW reads a correlation table from the file (or when a user add new entries into the table) it sorts it so that the longer CountryCode values (more detailed "CountryCode") are put at first places of the list then shorter CountryCode values. For example "44779" will be before "44". First found "mccMnc" value will be used for correlationId generating. When SMSC GW receives a SRI request from an upper SMSC GW it looks throught the table, checks if incoming MSISDN digits start from countryCode value from a table entry. The last entry in the correlation table must be empty ("") countryCode value. This entry will be used as a default value. All MSISDN that are not fit to any other entries will use mccMnc of the entry of "". You can also add an optional extra field "smsc" into any record. This value will be used as LocationInfo field in SendRoutinInfo response.

6.1.6.2. Living time of elements in correlation cache
6.1.6.2.1. Using CLI

In home routing mode SMSC GW specifies correlationId for any recieved SRI requests from upper SMSC. After it this correlationId value and corresponded to MSISDN data are stored into internal cache and will be used for processing of next coming MtForwardSM messages from other SMSC. Correlationidlivetime value defines how much time minimum is correlationId in cache. You can set the 'correlationidlivetime' option by issuing the command smsc set correlationidlivetime with appropriate parameters as described below. You can verify this by issuing the command smsc get correlationidlivetime which will display the value set for this property.

Also pay attention that when Telestax SMSC delivers messages received under "home routing" procedure SMSC GW will try to reuse location info and IMSI data that SMSC GW has obtained when request to HLR under "home routing" procedure. SMSC GW will try to reuse this info only till it is kept in correlationId cache. When ForwardAndStore and datagram modes this is usually achived in correlationidlivetime is 60 seconds. In StoreAndForward mode messages delivery can be started some time after messages have come to SMSC GW. This delay depends on both SMSC GW setting (first delivery attempt) and SMSC GW overloadload rate. For StoreAndForward mode we need to caluclate a proper correlationidlivetime value depending on othe SMSC setting. But do not make this value too big - this will waste memory and location info can occure too old.

Name
    smsc set correlationidlivetime

SYNOPSIS
    smsc set correlationidlivetime <digital option>

DESCRIPTION
    This command is used to set min time duration for which
    correlationId and corresponded data kept in cache. Max
    duratuion is two times more then correlationidlivetime.
    Value is in seconds.

    Default value: 60 (seconds).

EXAMPLES
    smsc set correlationidlivetime 90
6.1.6.2.2. Using GUI
Procedure: Setting of living time of elements in correlation cache using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Home Routing' tab in the GUI.

  3. You can specify CDR generation option by selecting an appropriate value in the field "Correlation Id Cache Time (in secs)". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.6.3. Bypassing of SRI request to a local HLR
6.1.6.3.1. Using CLI

SMSC GW home routing procedure for each networkId area can be configured to send or do not send SendRoutinInfo request to a local HLR. This is configured by parameter "hrsribypass". Default value is "false" - this means that SMSC GW will send SRI requests to local HLR before sending back SRI response.

Messageflow for home routing procedure when hrsribypass==false

SRI request: remote SMSC GW → Telscale SMSC GW

SRI request: Telscale SMSC GW → local HLR

SRI response: local HLR → Telscale SMSC GW

SRI response: Telscale SMSC GW → remote SMSC GW

MT request: remote SMSC GW → Telscale SMSC GW

MT response: Telscale SMSC GW → remote SMSC GW

Messageflow for home routing procedure when hrsribypass==true (SRI request to local HLR bypassing)

SRI request: remote SMSC GW → Telscale SMSC GW

SRI response: Telscale SMSC GW → remote SMSC GW

MT request: remote SMSC GW → Telscale SMSC GW

MT response: Telscale SMSC GW → remote SMSC GW You can set the 'hrsribypass' option by issuing the command smsc set hrsribypass with appropriate parameters as described below. You can verify this by issuing the command smsc get hrsribypass which will display the value set for this property.

Name
    smsc set hrsribypass

SYNOPSIS
    smsc set hrsribypass <digital option> networkid <networkId>

DESCRIPTION
    This command is used to set if SMSC GW will
    bypass a SRI to a local HLR.

	networkId - specifies a virtual SS7 subnetwork (this is for Multi-tenancy
	support). By using of this command with different networkIds you can
	specify hrsribypass for several subnetworks.
	If this parameter is skipped - networkId will be set to "0".
	If you have not specified hrsribypass parameter for a networkId
	then a master hrsribypass will be used (that was specified for
	networkId 0).

    Default value: false.

EXAMPLES
    smsc set hrsribypass true
    smsc set hrsribypass false networkid 2
6.1.6.3.2. Using GUI
Procedure: Setting of living time of elements in correlation cache using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Home Routing' tab in the GUI.

  3. You can specify hrsribypass option by selecting an appropriate value in the field "Bypassing of SRI request to a local HLR" for a specified networkId. Select needed "Bypassing of SRI request to a local HLR Network Id" field value or type a new networkId value if no such value already specifyied. Then select needed value into below field ("Removing value from networkId" means just remove "Bypassing of SRI request" for a selected networkId). For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.6.4. Create an entry for correlation table CC and MCC-MNC
6.1.6.4.1. Using CLI

In home routing mode SMSC GW we may need to specify the correlation table CC and MCC-MNC (Correlation table CC and MCC-MNC for home routing mode managing.). You can add an entry of this table by issuing the command smsc hrccmccmnc add with appropriate parameters as described below.

Name
    smsc hrccmccmnc add

SYNOPSIS
    smsc hrccmccmnc add <countrycode> <mccmnc> smscgt <smsc-gt>

DESCRIPTION
    This command is used to add an entry to the correlation
    table CC and MCC-MNC.
    mscgt parameter is optional. If it is missed will be set]
    to "null" value. For "null" value for <smsc-gt> we can
    to specify "-1" value in CLI.

EXAMPLES
    smsc hrccmccmnc add 2223 55322 smscgt 733211232342
6.1.6.4.2. Using GUI
Procedure: Creation an entry for correlation table CC and MCC-MNC using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Home Routing CC - MCC MNC Table' in the left panel.

  2. You can add an entry of the table - you can specify "Country Code", "Mobile Country Code and Mobile Network Code", "Global Title" (optionally) and press "Add" button. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

6.1.6.5. Modification of an entry for correlation table CC and MCC-MNC
6.1.6.5.1. Using CLI

In home routing mode SMSC GW we may need to specify the correlation table CC and MCC-MNC (Correlation table CC and MCC-MNC for home routing mode managing.). You can modify an entry of this table by issuing the command smsc hrccmccmnc modify with appropriate parameters as described below.

Name
    smsc hrccmccmnc modify

SYNOPSIS
    smsc hrccmccmnc modify <countrycode> <mccmnc> smscgt <smsc-gt>

DESCRIPTION
    This command is used to modify an entry to the correlation
    table CC and MCC-MNC.
    mscgt parameter is optional. If this parameter is missed mscgt
    value will not updated. To set "null" value for <smsc-gt> we
    need to specify "-1" value in CLI.

EXAMPLES
    smsc hrccmccmnc modify 2223 55322 smscgt 733211232342
6.1.6.5.2. Using GUI
Procedure: Modification of an entry for correlation table CC and MCC-MNC using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Home Routing CC - MCC MNC Table' in the left panel.

  2. You can modify an entry of the table - you can specify "Country Code", "Mobile Country Code and Mobile Network Code", "Global Title" (optionally) and press "Update" button. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

6.1.6.6. Removing of an entry for correlation table CC and MCC-MNC
6.1.6.6.1. Using CLI

In home routing mode SMSC GW we may need to specify the correlation table CC and MCC-MNC (Correlation table CC and MCC-MNC for home routing mode managing.). You can remove an entry of this table by issuing the command smsc hrccmccmnc remove with appropriate parameters as described below.

Name
    smsc hrccmccmnc remove

SYNOPSIS
    smsc hrccmccmnc remove <countrycode>

DESCRIPTION
    This command is used to remove an entry to the correlation
    table CC and MCC-MNC.

EXAMPLES
    smsc hrccmccmnc remove 2223
6.1.6.6.2. Using GUI
Procedure: Removing of an entry for correlation table CC and MCC-MNC using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Home Routing CC - MCC MNC Table' in the left panel.

  2. You can delete an entry of the table you - can specify "Country Code" and press "Delete" button. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

6.1.6.7. Displaying of an entry / full list of correlation table CC and MCC-MNC
6.1.6.7.1. Using CLI

In home routing mode SMSC GW we may need to specify the correlation table CC and MCC-MNC (Correlation table CC and MCC-MNC for home routing mode managing.). You can observe an entry or a full list of this table by issuing the command smsc hrccmccmnc show with appropriate parameters as described below.

Name
    smsc hrccmccmnc show

SYNOPSIS
    smsc hrccmccmnc show <countrycode>

DESCRIPTION
    This command is used to display of content of an entry
    or a full list of the correlation table CC and MCC-MNC.
    <countrycode> is an optional parameter. If you specify
    it data for only this entry will be displayed. If not
    - data for all entries of that table.

EXAMPLES
    smsc hrccmccmnc show 2223
6.1.6.7.2. Using GUI
Procedure: Displaying of an entry for correlation table CC and MCC-MNC using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Home Routing CC - MCC MNC Table' in the left panel.

  2. You can view content of an entry of the table you or of all table. For viewing of one entry you need to specify "Country Code". Then press "View" button. Results will be shown in the bottom of the screen For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

6.1.7. CDRs and archive tables

6.1.7.1. CDR generation
6.1.7.1.1. Using CLI

SMSC GW can store CDR records for each delivered or failed for delivering messages into log file (see [_cdr_logging_settings]). Which records will be stored is defined by 'generatecdr' SMSC option. You can set the 'generatecdr' option by issuing the command smsc set generatecdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generatecdr which will display the value set for this property.

Name
	smsc set generatecdr

SYNOPSIS
	smsc set generatecdr <0 | 1 | 2 | 4 | 7>

DESCRIPTION
	This command is used to set the generatecdr value. generatecdr
	defines which messages records will be added into .txt CDR's

	Options will have following bits values:

	1 - records will be done for SMPP originated messages with
	datagramm mode
	2 - records will be done for SMPP originated messages with
	transactional mode
	4 - records will be done for SMPP originated messages with
	storeAndForward mode and for all SS7 or SIP originated messages

	Value 0 will mean store none and value 7 - store all.
	Default value: 7

EXAMPLES
	smsc set generatecdr 7
6.1.7.1.2. Using GUI
Procedure: Set CDRs generation SMSC option using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify CDR generation option by selecting an appropriate value in the field "CDR generation". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.2. Archive table generation
6.1.7.2.1. Using CLI

SMSC GW can store CDR records for each delivered or failed for delivering messages into special archive tables of cassandra database. Names of such tables have the following format: MESSAGES_yyyy_mm_dd. You can refer to fields definitions in [_messages_yyyy_mm_dd] chapter. Which records will be stored is defined by 'generatearchivetable' SMSC option. You can set the 'generatearchivetable' option by issuing the command smsc set generatearchivetable with appropriate parameters as described below. You can verify this by issuing the command smsc get generatearchivetable which will display the value set for this property.

Name
    smsc set generatearchivetable

SYNOPSIS
    smsc set generatearchivetable <digital option>

DESCRIPTION
    This command is used to set which messages (or none) will be stored into
    archive tables. Options will have following bits values:
    bit 1 - records will be done for SMPP originated messages with datagramm
            mode
    bit 2 - records will be done for SMPP originated messages with
            transactional mode
    bit 4 - records will be done for SMPP originated messages with
            storeAndForward mode and for all SS7 or SIP originated messages
    Value 0 will mean store none and value 7 - store all.
    Default value: 7 (store all)
EXAMPLES
    smsc set generatearchivetable 7
6.1.7.2.2. Using GUI
Procedure: Set archive table CDRs generation SMSC option using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify archive table CDR generation option by selecting an appropriate value in the field "Archive table generation". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.3. Generate CDR for Receipt Messages
6.1.7.3.1. Using CLI

You can set the 'generatereceiptcdr' value to true/false by issuing the command smsc set generatereceiptcdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generatereceiptcdr which will display the value set for this property.

Name
	smsc set generatereceiptcdr

SYNOPSIS
	smsc set generatereceiptcdr <true | false>

DESCRIPTION
	The SMSC can be configured to generate CDR for both receipt and regular messages
	or generate CDR only for regular messages. By default the SMSC will generate CDR
	for regular messages only. However if you require the SMSC to generate CDR for
	receipt messages as well, you must set the parameter 'generatereceiptcdr' to true.
	Default value: false

EXAMPLES
	smsc set generatereceiptcdr false
6.1.7.3.2. Using GUI
Procedure: Set 'generate CDR for receipt messages' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should generate CDR for receipt messages by choosing the value true for the field 'Generate receipt CDR'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.4. Generate CDR for Rejected Messages as a message sumbission step
6.1.7.4.1. Using CLI

You can set the 'generaterejectioncdr' value to true/false by issuing the command smsc set generaterejectioncdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generaterejectioncdr which will display the value set for this property.

Name
	smsc set generaterejectioncdr

SYNOPSIS
	smsc set generaterejectioncdr <true | false>

DESCRIPTION
	The SMSC can be configured to generate CDRs for rejections at submission step,
	you must set the parameter 'generaterejectioncdr' to true.
	Default value: false

EXAMPLES
	smsc set generaterejectioncdr false
6.1.7.4.2. Using GUI
Procedure: Set 'generate CDR for Rejected Messages as a message sumbission step' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should generate CDR for receipt messages by choosing the value true for the field 'Generate CDR for message rejection'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.5. Generate Detailed CDR for Messages
6.1.7.5.1. Using CLI

You can set the 'generatedetailedcdr' value to true/false by issuing the command smsc set generatedetailedcdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generatedetailedcdr which will display the value set for this property.

Name
	smsc set generatedetailedcdr

SYNOPSIS
	smsc set generatedetailedcdr <true | false>

DESCRIPTION
	The SMSC can be configured to generate both regular and detailed CDR for messages
	or to generate just regular CDR. By default the SMSC will only generate regular CDR.
	However if you want the SMSC to also generate detailed CDR, you have to set the
	parameter 'generatedetailedcdr' to true.
	Default value: false

EXAMPLES
	smsc set generatedetailedcdr false
6.1.7.5.2. Using GUI
Procedure: Set 'generate detailed CDR for messages' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should generate detailed CDR for messages by choosing the value true for the field 'Generate detailed CDR'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.6. Generate CDR for temporary failure case
6.1.7.6.1. Using CLI

You can set the 'generatetempfailurecdr' value to true/false by issuing the command smsc set generatetempfailurecdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generatetempfailurecdr which will display the value set for this property.

Name
	smsc set generatetempfailurecdr

SYNOPSIS
	smsc set generatetempfailurecdr <true | false>

DESCRIPTION
	The SMSC can be configured to generate CDR for a successful delivery case,
	a permanent failure case and a temporary failure case. If we configure
	generatetempfailurecdr to true then CDR will be generated for all cases.
	If we configure generatetempfailurecdr to false then CDR will be generated for
	successful delivery and permanent failure cases and not for a temporary failure
	case.
	Default value: true

EXAMPLES
	smsc set generatetempfailurecdr true
6.1.7.6.2. Using GUI
Procedure: Set 'generate CDR for a temporary failure case' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should generate CDR for for a temporary failure case by choosing the value true for the field 'Generate CDR for a temporary failure case'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.7. Generate CDR for Message Processing Errors
6.1.7.7.1. Using CLI

You can set the 'generateprocessingerrorcdr' value to true/false by issuing the command smsc set generateprocessingerrorcdr with appropriate parameters as described below. You can verify this by issuing the command smsc get generateprocessingerrorcdr which will display the value set for this property.

Name
  smsc set generateprocessingerrorcdr

SYNOPSIS
  smsc set generateprocessingerrorcdr <true | false>

DESCRIPTION
  The SMSC can be configured to generate CDR also for unsuccessful message
  processing. This applies both to a variety of SMSC errors (unexpected
  internal and/or external) as well as to intentional message rejection by
  MProc rules.
  Default value: false

EXAMPLES
  smsc set generateprocessingerrorcdr false
6.1.7.7.2. Using GUI
Procedure: Set 'generate CDR for message processing error' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should generate CDR for message processing errors by choosing the value true for the field 'Generate CDR for an SMSC processing error case'. For more details of this parameter, please refer to the description of the CLI command in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.8. Calculating of message parts and characters count per a CDR record
6.1.7.8.1. Using CLI

You can set the 'calculatemsgpartslencdr' value to true/false by issuing the command smsc set calculatemsgpartslencdr with appropriate parameters as described below. You can verify this by issuing the command smsc get calculatemsgpartslencdr which will display the value set for this property.

Name
	smsc set calculatemsgpartslencdr

SYNOPSIS
	smsc set calculatemsgpartslencdr <true | false>

DESCRIPTION
	When SMSC GW generates CDR records it can calculate message parts and characters
	count per a CDR record. Message parts count means a count of parts to that
	SMSC GW will have to split a long messages when sending messages into SS7 network.
	This demands some extra calculating and therefore is disabled by default.
	You can turn it on by setting to a true of calculatemsgpartslencdr option.
	Default value: false

EXAMPLES
	smsc set calculatemsgpartslencdr false
6.1.7.8.2. Using GUI
Procedure: Set 'calculating of message parts and characters count per a CDR record' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should calculating of message parts and characters count per a CDR record by choosing the value true for the field 'Calculating of message parts and characters count per a CDR record'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.7.9. Adding of delay parameters into a CDR record
6.1.7.9.1. Using CLI

You can set the 'delayparametersincdr' value to true/false by issuing the command smsc set delayparametersincdr with appropriate parameters as described below. You can verify this by issuing the command smsc get delayparametersincdr which will display the value set for this property.

Name
	smsc set delayparametersincdr

SYNOPSIS
	smsc set delayparametersincdr <true | false>

DESCRIPTION
	When SMSC GW generates CDR records it can calculate a message processing time,
	delivery delay, schedule delivery delay and delivery count per a CDR record.
	This demands some extra calculating and therefore is disabled by default.
	You can turn it on by this option.
	Default value: false

EXAMPLES
	smsc set delayparametersincdr true
6.1.7.9.2. Using GUI
Procedure: Set 'Adding of delay parameters into a CDR record' using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'CDR' tab in the GUI.

  3. You can specify if the SMSC should add of delay parameters into a CDR record by choosing the value true for the field 'Delay parameters in CDR'. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8. Processing

6.1.8.1. Messaging mode for MO messages
6.1.8.1.1. Using CLI

You can set the messaging mode for MO originated messages value by issuing the command smsc set modefaultmessagingmode with appropriate parameters as described below. You can verify this by issuing the command smsc get modefaultmessagingmode which will display the value set for this property.

Name
	smsc set modefaultmessagingmode

SYNOPSIS
	smsc set modefaultmessagingmode <messaging mode value>

DESCRIPTION
	This command is used to set a value for default messaging mode
	value for mobile originated (MO) messages.
	Possible values: 0-default SMSC mode, 1-datagram, 2-transactional,
	3-storeAndForward.
	Default value is 3.

EXAMPLES
	smsc set modefaultmessagingmode 3
6.1.8.1.2. Using GUI
Procedure: Set the messaging mode for MO originated messages option using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify the messaging mode for MO originated messages option by selecting an appropriate value in the field "Default messaging mode - MO messages". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.2. Messaging mode for HR messages
6.1.8.2.1. Using CLI

You can set the messaging mode for HR originated messages value by issuing the command smsc set hrdefaultmessagingmode with appropriate parameters as described below. You can verify this by issuing the command smsc get hrdefaultmessagingmode which will display the value set for this property.

Name
	smsc set hrdefaultmessagingmode

SYNOPSIS
	smsc set hrdefaultmessagingmode <messaging mode value>

DESCRIPTION
	This command is used to set a value for default messaging mode
	value for messages that came by SS7 Home Routing procedure.
	Possible values: 0-default SMSC mode, 1-datagram, 2-transactional
	(this means HR transparent mode), 3-storeAndForward.
	Default value is 3.

EXAMPLES
	smsc set hrdefaultmessagingmode 3
6.1.8.2.2. Using GUI
Procedure: Set the messaging mode for HR originated messages option using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify the messaging mode for HR originated messages option by selecting an appropriate value in the field "Default messaging mode - HR messages". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.3. Messaging mode for SIP messages
6.1.8.3.1. Using CLI

You can set the messaging mode for SIP originated messages value by issuing the command smsc set sipdefaultmessagingmode with appropriate parameters as described below. You can verify this by issuing the command smsc get sipdefaultmessagingmode which will display the value set for this property.

Name
	smsc set sipdefaultmessagingmode

SYNOPSIS
	smsc set sipdefaultmessagingmode <messaging mode value>

DESCRIPTION
	This command is used to set a value for default messaging mode
	value for messages from a SIP connector.
	Possible values: 0-default SMSC mode, 1-datagram, 2-transactional,
	3-storeAndForward. Transactional mode mode is not supported now.
	Default value is 3.

EXAMPLES
	smsc set sipdefaultmessagingmode 1
6.1.8.3.2. Using GUI
Procedure: Set the messaging mode for SIP originated messages option using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify the messaging mode for SIP originated messages option by selecting an appropriate value in the field "Default messaging mode - SIP messages". For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.4. SMSC pausing
6.1.8.4.1. Using CLI

A user can pause SMSC for message delivering by issuing the command smsc set deliverypause with appropriate parameters as described below. When SMSC delivery is paused no more messages are scheduled for delivering. When SMSC is configured in ForwardAndStore (fast) mode all incoming messages will be rejected. When SMSC is configured in StoreAndForward (normal) mode datagramm and transactional SMPP originated messages will be rejected but StoreAndForward SMPP originated and all SS7 / SIP originated messages will be stored into cassandra database without delivery attempts. Use this option with extreme caution.

	Name
	    smsc set deliverypause

	SYNOPSIS
	    smsc set deliverypause <true|false>

	DESCRIPTION
	    Setting to true puts SMSC GW into a pause mode and setting to false
	    (default value) returns SMSC GW to a normal message processing.
	EXAMPLES
	    smsc set deliverypause true
6.1.8.4.2. Using GUI
Procedure: Pause SMSC using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. You can select "true" or "false" value. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  3. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.5. Disabling of Reciepts generating
6.1.8.5.1. Using CLI

SMCS can generate receipts of messages delivering results (success / error). See chapter "Appendix B. Delivery Receipt Format" of "Short Message Peer to Peer. Protocol Specification v3.4." You can set the 'receiptsdisabling' value to true/false by issuing the command smsc set receiptsdisabling with appropriate parameters as described below. You can verify this by issuing the command smsc get receiptsdisabling which will display the value set for this property.

Name
    smsc set receiptsdisabling

SYNOPSIS
    smsc set receiptsdisabling <true | false>

DESCRIPTION
    The SMSC can be configured to generat or not delivery receipts.
     Setting of receiptsdisabling to false enables of receipts generation.
     Setting of receiptsdisabling to true disables of receipts generation.
     Default value: false (receipts will be generated).
6.1.8.5.2. Using GUI
Procedure: Disabling of Reciepts generating using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify if the SMSC should disable of receipt generating by setting the value for the field 'Disable Delivery Receipt' to true or false accordingly. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.6. Allowing of generating of intermediate receipts
6.1.8.6.1. Using CLI

SMCS can generate intermediate receipts (for temporary failures). You can set the 'enableintermediatereceipts' value to true/false by issuing the command smsc set enableintermediatereceipts with appropriate parameters as described below. You can verify this by issuing the command smsc get enableintermediatereceipts which will display the value set for this property.

Name
    smsc set enableintermediatereceipts

SYNOPSIS
    smsc set enableintermediatereceipts <true | false>

DESCRIPTION
    The SMSC can be configured to generate or not delivery intermediate receipts
	(these are receipts for temporary delivery failures).
	Default value: false (intermediate receipts will not be generated).
6.1.8.7. Income receipts processing
6.1.8.7.1. Using CLI

SMCS can processing of incoming delivery receipts from remote SMSC GW (replacing of messageId in the receipt by a local messageId). You can set the 'incomereceiptsprocessing' value to true/false by issuing the command smsc set incomereceiptsprocessing with appropriate parameters as described below. You can verify this by issuing the command smsc get incomereceiptsprocessing which will display the value set for this property.

Name
    smsc set incomereceiptsprocessing

SYNOPSIS
    smsc set incomereceiptsprocessing <true | false>

DESCRIPTION
	Enabling of processing of incoming delivery receipts from remote SMSC GW.
	When a delivery receipt comes from a remote SMSC GW, then
	SMSC GW will replace messageId in the receipt by a local messageId.
	This action is needed for a possibility of delivery receipts processing
	in mproc rules staff and delivery receipts transit to message originators.
	Default value: false (no remote delivery receipts processing).
6.1.8.7.2. Using GUI
Procedure: Allowing of generating of intermediate receipts using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify of processing of incoming delivery receipts by setting the value for the field 'Income receipts processing' to true or false accordingly. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.8. Routing of delivery receipts
6.1.8.8.1. Using CLI

If this option is turned on for each generated delivery receipts and SMS-STATUS-REPORTs networkId will be assigned to the value of networkId of an ESME via which the original message has come to SMSC. This can help for routing of receipts back to the originated ESME. If this option is turned off then the networkId of receipts will be taken from networkId of ESME / SS7 / SIP via which the original message has left SMSC GW. You can configure this option by issuing the command smsc set orignetworkidforreceipts with appropriate parameters as described below.

Name
    smsc set orignetworkidforreceipts

SYNOPSIS
    smsc set orignetworkidforreceipts <true | false>

DESCRIPTION

	Settings of this option will affect of which networkId will be assigned
	to a message delivery receipt.
	true: networkId of the connector via which an original message has
	      left SMSC GW
	false: networkId of the connector via which an original message has
	       come SMSC GW. This value is default.
6.1.8.8.2. Using GUI
Procedure: Routing of delivery receipts option update by the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify routing of delivery receipts by setting the value for the field 'Delivery receipts will be routed to the origination networkId' to true or false accordingly. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.9. Minimum MessageId value
6.1.8.9.1. Using CLI

You can set the 'Minimum MessageId value' value by issuing the command smsc set minmessageid with appropriate parameters as described below. You can verify this by issuing the command smsc get minmessageid which will display the value set for this property.

Name
	smsc set minmessageid

SYNOPSIS
	smsc set minmessageid <min-MessageId-value>

DESCRIPTION
	This command is used to set the value of minimum MessageId value
	that is put into SMPP submit_sm_response.
	Default value is 1.
	You need to restart SMSC GW in order to changing will make effect.
6.1.8.9.2. Using GUI
Procedure: Minimum MessageId value option update by the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify routing of delivery receipts by setting the value for the field 'Minimum MessageId value' to a neede value. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.1.8.10. Maximum MessageId value
6.1.8.10.1. Using CLI

You can set the 'Maximum MessageId value' value by issuing the command smsc set maxmessageid with appropriate parameters as described below. You can verify this by issuing the command smsc get maxmessageid which will display the value set for this property.

Name
	smsc set maxmessageid

SYNOPSIS
	smsc set maxmessageid <max-MessageId-value>

DESCRIPTION
	This command is used to set the value of maximum MessageId value
	that is put into SMPP submit_sm_response.
	Default value is 10000000000L.
	You need to restart SMSC GW in order to changing will make effect.
6.1.8.10.2. Using GUI
Procedure: Maximum MessageId value option update by the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'Server Settings' in the left panel.

  2. The main panel will display the existing Settings, segregated into eight horizontal tabs: Properties, SS7 Settings, Cassandra, Scheduler, Diameter, Processing, CDR and Home Routing. Switch to the 'Processing' tab in the GUI.

  3. You can specify routing of delivery receipts by setting the value for the field 'Maximum MessageId value' to a neede value. For more details of this parameter, please refer to the description of the CLI command for the same in the preceding section.

  4. You must click on the button 'Save' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.2. SMPP Server Settings

6.2.1. View SMPP Server Details

6.2.1.1. Using GUI
Procedure: View SMPP Server Details using the GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'SMPP Server' in the left panel.

  2. The main panel will display the existing SMPP Server details as configured in the section SmscManagement in the xml descriptor file restcomm-smsc-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml.

  3. You can view the current Session details of the SMPP Server by clicking on the row corresponding to the name of the SMPP Server (SmscManagement in this case).

6.2.2. Edit SMPP Server Properties

6.2.2.1. Using CLI

You can edit the properties of the SMPP Server by issuing appropriate commands for every property as described below:

Name
	smpp smppserver set port

SYNOPSIS
	smpp smppserver set port <port>

DESCRIPTION
	This command is used to set the port that the SMSC server is listening to for
	incoming bind request.

	If unspecified, the default port is 2776.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set bindipaddress

SYNOPSIS
	smpp smppserver set bindipaddress <ip-address>

DESCRIPTION
	This command is used to set the IP for SMPP server.
	The SMSC server will use this ip for listening incoming bind request from SMPP client.

	If unspecified, the default value is 0.0.0.0, that means SMPP server will listen on all interfaces.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set bindtimeout

SYNOPSIS
	smpp smppserver set bindtimeout <bind-timeout>

DESCRIPTION
	This command is used to set a value for bind-timeout in milli-seconds.
	Once the TCP socket is established, the SMSC server will wait for the time period
	specified by the parameter bind-timeout in milli-seconds, for the peer to send a
	bind request, after which it will kill the TCP socket.

	If unspecified, the default value is 5000 milli-seconds.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set writetimeout

SYNOPSIS
	smpp smppserver set writetimeout <bind-timeout>

DESCRIPTION
	This command is used to set a value for write-timeout in milli-seconds.
	This parameter sets a timeout which occurs when we can not properly sent
	a message into TCP channel.

	If unspecified, the default value is 0 (no timeout).

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set systemid

SYNOPSIS
	smpp smppserver set systemid <system-id>

DESCRIPTION
	This command is used to set the value for system-id. This is the 'system-id'
	included in the Bind response.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set autonegotiateversion

SYNOPSIS
	smpp smppserver set autonegotiateversion <true/false>

DESCRIPTION
	This command is used to specify if auto-negotiate-version is enabled or not.
	If it is set to 'true' and a Bind is received with version <= 3.3 for
	interface version, then it is normalized to version 3.3. If a Bind is received
	with version >= 3.4 for interface version, it is normalized to version 3.4.

	The default value is true.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set interfaceversion

SYNOPSIS
	smpp smppserver set interfaceversion <interface-version>

DESCRIPTION
	This command is used to specify the SMPP version that the Server supports.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set maxconnectionsize

SYNOPSIS
	smpp smppserver set maxconnectionsize <max-connection-size>

DESCRIPTION
	This command is used to specify the maximum number of connections/sessions this
	Server is expected to handle.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set defaultwindowsize

SYNOPSIS
	smpp smppserver set defaultwindowsize <defaultwindowsize>

DESCRIPTION
	This command is used to specify the default window size for this Server.
	The window size is the amount of unacknowledged requests that are permitted to be
	outstanding/unacknowledged at any given time. If more requests are added, the
	underlying stack will throw an exception.

	The default value is 100.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set defaultwindowwaittimeout

SYNOPSIS
	smpp smppserver set defaultwindowwaittimeout <default-window-wait-timeout>

DESCRIPTION
	This command is used to specify the default-window-wait-timeout for this Server
	in milli-seconds.
	The window wait timeout is the time within which the connection to remote SMSC
	Server should be established.

	The default value is 30000 milli seconds.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set defaultrequestexpirytimeout

SYNOPSIS
	smpp smppserver set defaultrequestexpirytimeout <default-request-expiry-timeout>

DESCRIPTION
	This command is used to specify the default-request-expiry-timeout for the Server
	in milli-seconds. The request expiry timeout is the time to wait for an end-point
	to respond to before it expires.

	The default value is 30000 milli seconds.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set defaultwindowmonitorinterval

SYNOPSIS
	smpp smppserver set defaultwindowmonitorinterval <default-window-monitor-interval>

DESCRIPTION
	This command is used to specify the default-window-monitor-interval for the Server
	in milli-seconds. This is the time between executions of monitoring the window for
	requests that expire. It is recommended that this value, generally, either matches
	or is half the value of 'request-expiry-timeout'. Therefore, in the worst case
	scenario, a request could take upto 1.5 times the 'requestExpiryTimeout' to
	clear out.

	The default value is 15000 milli seconds.

	You must restart the SMPP Server for the new value to take effect.
Name
	smpp smppserver set defaultsessioncountersenabled

SYNOPSIS
	smpp smppserver set defaultsessioncountersenabled <true/false>

DESCRIPTION
	This command is used to set the parameter 'defaultsessioncountersenabled' value
	to true or false.
	When this is enabled, SMSC exposes the statistics for SMPP connections.

	The default value is true.

	You must restart the SMPP Server for the new value to take effect.
6.2.2.2. Using GUI
Procedure: Edit SMPP Server Properties using GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'SMPP Server' in the left panel.

  2. The main panel will display the existing SMPP Server details as configured in the section SmscManagement in the xml descriptor file restcomm-smsc-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml.

  3. You can edit the properties of the SMPP Server by launching the edit window. You can achieve this by clicking on the blue coloured 'edit' button at the end of the row. The edit window will display all SMPP properies as shown in the figure below. For more details of these parameters please refer to the descriptions of the CLI commands for the same in the preceding section.

    GUI SMSC GW SMPP EDIT
    Figure 2. SMPP Server - GUI - Restcomm SMSC
  4. To edit any property, click on the edit icon of the row corresponding to the property. This action will display an editable text field for the property as shown in the figure above. Adjacent to the editable text field, you will find a 'tick' icon and a 'x' icon. To accept the newly entered value for the property, you must click on the 'tick' icon. To discard the change and stop the editing of the property, you must click on the 'x' icon.

    SMPP Server can be setup for SSL so every incoming connection request should first do SSL hand-shake. Settingup SSL is only possible from GUI.

  5. You must click on the button 'Apply Changes' at the top of the window to save your settings. If there is an error in setting the value, then you will find the details of the error in the Management Console Log section below.

6.2.3. Start SMPP Server

6.2.3.1. Using GUI
Procedure: Start SMPP Server using GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'SMPP Server' in the left panel.

  2. The main panel will display the existing SMPP Server details as configured in the section SmscManagement in the xml descriptor file restcomm-smsc-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml.

  3. You can start the SMPP Server by clicking on the 'Start' icon lit green in the row corresponding to the SmscManagement unit. This icon will be enabled only if the SMPP server is currently stopped.

  4. This action will start the SMPP Server.

  5. If there is an error in starting the SMPP Server, then you will find the details of the error in the Management Console Log section below.

6.2.4. Stop SMPP Server

6.2.4.1. Using GUI
Procedure: Stop SMPP Server using GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'SMPP Server' in the left panel.

  2. The main panel will display the existing SMPP Server details as configured in the section SmscManagement in the xml descriptor file restcomm-smsc-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml.

  3. You can stop the SMPP Server by clicking on the 'Stop' icon lit red in the row corresponding to the SmscManagement unit. This icon will be enabled only if the SMPP server is currently running.

  4. This action will stop the SMPP Server.

  5. If there is an error in stopping the SMPP Server, then you will find the details of the error in the Management Console Log section below.

6.2.5. Reset Counters for SMPP Server

6.2.5.1. Using GUI
Procedure: Reset Counters for SMPP Server using GUI
  1. In the GUI Management Console for SMSC Gateway, click on 'SMPP Server' in the left panel.

  2. The main panel will display the existing SMPP Server details as configured in the section SmscManagement in the xml descriptor file restcomm-smsc-<version>/jboss-5.1.0.GA/server/<profile>/deploy/restcomm-smsc-server/META-INF/jboss-beans.xml.

  3. You can view the current Session details of the SMPP Server by clicking on the row corresponding to the name of the SMPP Server (SmscManagement in this case).

  4. This action will display the current session details of the SMPP Server. If you scroll to the bottom, you will find a button named 'Reset Counters'. Click on it if you wish to reset all counters for SMPP Server.

  5. If there is an error resetting the counters, then you will find the details of the error in t