If you configure the Gateway to log CDR to a Database, then every transaction of the Gateway is logged in the HSQLDB that comes bundled with JBoss AS and leverages the JBoss AS DataSource. However this is only made available to allow the platform to run “out of the box”. You must configure a production ready Database prior to using the Gateway in a production environment.

Mobicents USSD Gateway has been tested with PostgreSQL and MySQL. In this section, you will find instructions for configuring MySQL database for CDR logging.

The post USSD – Configuring MySQL as datasource appeared first on Telestax Docs Online.

Introduction to USSD Gateway

USSD Gateway is an Open Source Java based USSD Gateway Platform that routes USSD messages from the signaling network to service applications and the other way around. It enables operators to offer real-time interactions to mobile subscribers and deliver interactive content to their mobile phones. USSD Gateway strictly adheres to the standards and specifications defined by the International Telecommunications Union (ITU).

USSD Gateway acts as an intermediary platform linking the service applications to the GSM network in a session oriented communication. The platform is easy-to-install and easy-to-deploy allowing you to have the Gateway set up and configured very quickly.

USSD Gateway comes with an efficient Command Line Interface (CLI) tool allowing you to completely configure the Gateway at run-time and manage it using simple commands rather than do everything manually. USSD Gateway also comes with a Graphical User Interface (GUI) that will allow you to configure, monitor and manage the Gateway through a convenient user-friendly interface.

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.

The post USSD – Introduction to USSD Gateway appeared first on Telestax Docs Online.

The post USSD – Overview appeared first on Telestax Docs Online.

Restcomm USSD Gateway is based on 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 diagram below depicts top design overview:

Restcomm USSD Gateway provides Load Balancing and Fault Tolerance. Two or more third-party Application Servers can be paired to provide Fault-Tolerance on the Gateway and GSM Network level.

Geographic Redundancy can be achieved as shown in the diagram below:

Below diagram shows how to achieve load-balancing by connecting to two STP’s from Operator side.

The post USSD – Architecture appeared first on Telestax Docs Online.

Restcomm USSD Gateway is able to work in multi-tenant mode by connecting to a set of different SS7 operators. The procedure is based on dividing of USSD routing rules into several areas (“subnetworks”).

Each area has its unique digital “netwokId” value. You can assign a unique USSD Global Title for each netwokId. Each SS7 SCCP service access point (SAP) and each USSD Routing Rule belongs to one of the networks (to each of them a networkId value is assigned). Default netwokId value is “0”. If a user does not specify a netwokId value when USSD Routing Rule or SAP rule creation, networkId=0 will be assigned.

When a PULL request comes from SS7 network, a networkId value from SAP will be assigned to a USSD dialog. Then USSD Routing Rule with assigned networkId will be chosen for request routing to a proper HTTP or SIP application.

When a PUSH request comes from HTTP application, a networkId value from HTTP XML payload (“networkId” attribute) is taken (or is assigned as 0 if “networkId” attribute is missed in the XML payload). Then SS7 SAP will be chosen when routing USSD request to SS7 network.

When a PUSH request comes from SIP application, a networkId value is always assigned as 0. It is impossible now to use SIP App originated messages for multi-tenancy.

For configuring of USSD Global Titles – see chapters Section 6.6.7, “USSD Global Title”.

The post USSD – Multi-tenancy support appeared first on Telestax Docs Online.

5.2. Running the Gateway – Simulator Profile

The Restcomm USSD Gateway 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. 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 USSD Simulator profile is configured for use in Linux systems. For using it in Microsoft Windows systems, you must configure the parameters as explained below.

Open the filemobicents-ussdgateway-<version>/jboss-5.1.0.GA/server/simulator/data/SCTPManagement_sctp.xml and replace in two places, the parameter ipChannelType="0" with ipChannelType="1" to enable TCP connection instead of SCTP since Windows does not support SCTP. If you are using in a Linux system, there is no modification required to the settings.

5.2.1. Running USSD Examples in Simulator

If you are not familiar with the Mobicents 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. In this section you will find a sample USSD Pull and USSD Push examples explained using the jSS7 Simulator.

Procedure 5.3. Running Restcomm jSS7 Simulator – USSD Pull Example

 

• Change the working directory to the bin folder in the Simulator’s installation directory.
  

  [vinu@vinu-neha ~]$ cd Mobicents-ussd-<version>/tools/Mobicents-ss7-simulator/bin

• Ensure that the run.sh start script is executable.
  

  bin$ chmod +x run.sh

• Execute the run.sh Bourne shell script with the command ./run.sh gui.
  

  bin$ ./run.sh gui

  
  This will launch the Simulator GUI Application.
• 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 USSD Gateway (running in simulator profile). Press ‘Run test’ and again click on ‘Start’ in the next screen. The Simulator will connect to USSD (via m3ua protocol). The Low level part is configured to SCTP (not TCP) protocol and hence you can test the USSD in a Linux environment. To test under Windows OS, you must change the SS7 simulator settings to TCP.

1. After approximately 30 seconds you will see the state of the Simulator change to “M3UA connection is active” as in figure below:

    

   Figure 5.1. USSD SS7 Simulator – Active
2. Restcomm USSD Gateway is configured with a routing rule for *519#. Dial *519# in your Simulator GUI and press ‘Send ProcessUnstructuredRequest’. The example will respond to you with the message “Hello World 1. Balance 2. Texts Remaining”.

   Figure 5.2. USSD SS7 Simulator – Process Unstructured Request
3. Now Dial 1 in your Simulator GUI and press ‘Send UnstructuredResponse’. You should get a response “Thank you!”.

   Figure 5.3. USSD SS7 Simulator – Unstructured Request

Procedure 5.4. Running USSD Simulator (HLR) – USSD Push Example

1. You must first start the USSD Gateway in simulator profile.
   

   [vinu@vinu-neha ~]$ cd mobicents-ussdgateway-<version>/jboss-5.1.0.GA/bin
   [vinu@vinu-neha bin]$./run.sh -b 127.0.0.1 -c simulator

2. To send a PUSH request go to http://localhost:8080/jmx-console/ and click the linkorg.mobicents.ussdgateway.example in the left menu. Then open the MBean 'name=HttpPush'.
3. MBean provides two operations: 1) sendNotify to push Notification and 2) sendRequest to push USSD menu based tree. The parameter Isdn is the MSISDN to which Notify or Request is to be sent.

Figure 5.4. Restcomm USSD Simulator – Notify

You can simulate a simple Notify dialog by following the below steps:

• Fill the ISDN field with a preferred ISDN number, for example “1111” is good for SS7 Simulator. Now press “Apply changes”.
• Perform “reset” operation.
• Perform “sendNotify” operation with parameters: String=<Text of your notification>, boolean=false, int=60000 and String=<any random string>. Parameters definition is as below
  • 1st String is USSD message that you want to push to mobile
  • 2nd Boolean if set to true means USSD Gw will send empty TCAP Begin and try to establish dialog before sending actual message.
  • 3rd Int is custom invoke timeout. User must respond within this period else USSD Gw will terminate Dialog and Application will get appropriate error message
  • 4th String is random string that is stored at USSD Gw side as custom object. When ever response comes back, USSD Gw will include this custom string in XML Payload.
• Perform “close” operation.

You will now find a notification at the SS7 Simulator.

You can also simulate more complicated scenarios like pushing the tree based menu to user and expecting some input from users by calling sendRequest. The below Class provides more explanation for attributes and operations of HttpPush.

/**

 * Simple MBean interface. This MBean is front end of simple example for ussd

 * push via HTTP.

 * 

 */

public interface HTTPPushMBean {


    /**

     * The URI where HTTP Post request is to be submitted. This should point the

     * USSD Gateway. Basically http://USSD-IP:8080/mobicents

     * 

     * @param uri

     */

    public void setTargetUri(String uri);


    /**

     * Get the URI pointing to USSD Gateway for push

     * 

     * @return

     */

    public String getTargetUri();


    /**

     * Set the MSISDN where USSD Push is to be sent

     * 

     * @param isdn

     */

    public void setIsdn(String isdn);


    /**

     * Get the MSISDN where USSD request is to be pushed

     * 

     * @return

     */

    public String getIsdn();


    /**

     * Reset( remove local dialog ) in case something goes wrong

     */

    public void reset();


    /**

     * Starts dialog if not already started. Sends Unstructured Request. It can

     * be sent multiple times in the same dialog

     * 

     * @param ussdRequest

     *            The actual USSD String request

     * @param emptyDialogHandshake

     *            If true, USSD Gateway will first establish Dialog by doing

     *            handshake before sending USSD request. If false the USSD

     *            request will be added in Dialog begin message

     * @param invokeTimeout

     *            Time in milliseconds USSD gateway will wait for user to

     *            respond, if user doesn't respond back within specified time,

     *            USSD Gateway will abort the dialog and send back Abort error

     *            to HTTP App

     * @param userData

     *            User Data to be sent with every request to USSD Gateway which will be

     *            returned back with response from USSD Gw. This is just in case if 

     *            application wants to keep some data at Dialog level, for example MSISDN

     * 

     *                        

     * @throws Exception

     */

    public void sendRequest(String ussdRequest, boolean emptyDialogHandshake, int invokeTimeout, String userData) throws Exception;


    /**

     * Starts dialog if not already started. Sends Notify Request. It can be

     * sent multiple times in the same dialog

     * 

     * @param ussdRequest

     *            The actual USSD String request

     * @param emptyDialogHandshake

     *            If true, USSD Gateway will first establish Dialog by doing

     *            handshake before sending USSD request. If false the USSD

     *            request will be added in Dialog begin message

     * @param invokeTimeout

     *            Time in milliseconds USSD gateway will wait for user to

     *            respond, if user doesn't respond back within specified time,

     *            USSD Gateway will abort the dialog and send back Abort error

     *            to HTTP App

     * @param userData

     *            User Data to be sent with every request to USSD Gateway which will be

     *            returned back with response from USSD Gw. This is just in case if 

     *            application wants to keep some data at Dialog level, for example MSISDN            

     * @throws Exception

     */

    public void sendNotify(String ussdRequest, boolean emptyDialogHandshake, int invokeTimeout, String userData) throws Exception;


    /**

     * USER Abort the underlying MAP Dialog

     * 

     * @throws Exception

     */

    public void abort() throws Exception;


    /**

     * Close the underlying MAP Dialog. This will send TCAP End to peer

     * 

     * @throws Exeption

     */

    public void close() throws Exception;


    /**

     * Return current status of service - what has been sent, what has been

     * received etc.

     * 

     * @return

     */

    public String getStatus();

}

 

[$] ./ss7-cli.sh

version=2.0.0-SNAPSHOT,name=mobicents CLI,prefix=mobicents,vendor=TeleStax
mobicents>

5.4. Running the Graphical User Interface

Open a Web Browser and navigate to http://localhost:8080/mobicents-management/. 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 USSD Gateway you will find the tabs for JAIN-SLEE, JMX, SS7 and USSD 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 USSD Gateway.

Switch to the USSD 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, Routing Rules, Metrics). 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.

Figure 5.5. GUI – Restcomm USSD Gateway

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

5.4.2. Authentication

RestcommUSSD Gateway GUI Management Security is based on the JBoss Security Framework. However please note that the feature is not fully functional yet and you will not be able to sign-out or sign-in using the login panel at the top right corner of the GUI. Future releases will offer a full implementation.

As of now, there is basic authentication offered (which is based on the JBoss Security framework). When you try to start the Web Console, you will be prompted to enter login credentials. These credentials can be configured in the filesjmx-console-roles.properties and jmx-console-users.properties located atmobicents-ussdgateway-<version>/jboss-5.1.0.GA/server/<profile>/conf/props/.

You can also change the authentication from flat file system to database by making necessary configurations in the filemobicents-ussdgateway-<version>/jboss-5.1.0.GA/server/<profile>/conf/login-config.xml.

For detailed instructions and to know more about JBoss Security Framework please refer to the JBoss Installation Guide here.

Note

Default 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 andjmx-console-users.properties located atmobicents-ussdgateway-/jboss-5.1.0.GA/server//conf/props/

The post USSD – Running appeared first on Telestax Docs Online.

You must fine-tune Memory and Database settings for better performance before using Restcomm USSD Gateway in production. Once you complete setting up the Gateway you must configure the SS7 Stack, USSD routing rules and USSD paramters. Restcomm USSD Gateway 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 USSD Gateway dynamically. This chapter will explain how to manage the Gateway effectively using both the GUI and the CLI.

CREATE TABLE USSD_GW_CDRS (ID VARCHAR(150) NOT NULL, L_SPC INT, L_SSN SMALLINT, L_RI SMALLINT, L_GT_I SMALLINT, L_GT_DIGITS VARCHAR(18), R_SPC INT, R_SSN SMALLINT, R_RI SMALLINT, R_GT_I SMALLINT, R_GT_DIGITS VARCHAR(18), SERVICE_CODE VARCHAR(50), OR_NATURE SMALLINT, OR_PLAN SMALLINT, OR_DIGITS VARCHAR(18), DE_NATURE SMALLINT, DE_PLAN SMALLINT, DE_DIGITS VARCHAR(18), ISDN_NATURE SMALLINT, ISDN_PLAN SMALLINT, ISDN_DIGITS VARCHAR(18), VLR_NATURE SMALLINT, VLR_PLAN SMALLINT, VLR_DIGITS VARCHAR(18), IMSI VARCHAR(100), STATUS VARCHAR(30) NOT NULL , TYPE VARCHAR(30) NOT NULL , TSTAMP TIMESTAMP NOT NULL , LOCAL_DIALOG_ID BIGINT, REMOTE_DIALOG_ID BIGINT, PRIMARY KEY(ID,TSTAMP));

where

ID : Primary unique key 

L_SPC : Local Signaling Pointcode 

L_SSN : Local Subsystem Number 

L_RI : Local Routing Indicator

L_GT_I : Local Global Title Indicator whose values are 
NO_GLOBAL_TITLE_INCLUDED(0)
GLOBAL_TITLE_INCLUDES_NATURE_OF_ADDRESS_INDICATOR_ONLY(1)
GLOBAL_TITLE_INCLUDES_TRANSLATION_TYPE_ONLY(2)
GLOBAL_TITLE_INCLUDES_TRANSLATION_TYPE_NUMBERING_PLAN_AND_ENCODING_SCHEME(3)
GLOBAL_TITLE_INCLUDES_TRANSLATION_TYPE_NUMBERING_PLAN_ENCODING_
					     SCHEME_AND_NATURE_OF_ADDRESS(4)

L_GT_DIGITS : Local Global Title Digits

R_SPC : Remote Signaling Pointcode 

R_SSN : Remote Subsystem Number 

R_RI : Remote Routing Indicator

R_GT_I : Remote Global Title Indicator

R_GT_DIGITS : Remote Global Title Digits

SERVICE_CODE : The short code dialed by user, for example *519#

OR_NATURE : AddressNature of origination
If the MAP Dialog carries Originating Address Reference this is captured in this column
Possible values are:
unknown(0), international_number(1), national_significant_number(2), network_specific_number(3), 
subscriber_number(4), reserved( 5), abbreviated_number(6) and reserved_for_extension(7)

OR_PLAN : Numbering Plan of origination. 
Possible values are:
unknown(0), ISDN(1), spare_2(2), data(3), telex(4), spare_5(5), land_mobile(6), 
spare_7(7), national(8), private_plan(9), reserved(15);

OR_DIGITS : Digits of origination

DE_NATURE : AddressNature of Destination 

DE_PLAN : Numbering Plan of Destination 

DE_DIGITS : Digits of destination

ISDN_NATURE : AddressNature 
The incoming MAP Dialog carries ISDN Address of mobile that dialed this shortcode.
The column ISDN_NATURE captures ISDN details.

ISDN_PLAN : Numbering Plan as explained above 

ISDN_DIGITS : Digits of MSISDN

VLR_NATURE : AddressNature
If MAP version is Ericsson MAP (E-MAP), it carries VLR address and IMSI

VLR_PLAN : Numbering Plan as explained above 

VLR_DIGITS : Digits of VLR

IMSI : IMSI

STATUS : Final status of Dialog. Possible values are explained below: 


TYPE : If the USSD request is pull, its value is PULL or its PUSH

TSTAMP : Time stamp when this request was executed

LOCAL_DIALOG_ID : Local Transaction Id of TCAP Dialog

REMOTE_DIALOG_ID : Remote Transaction Id of TCAP Dialog

Name
	ussd set noroutingruleconfigerrmssg

SYNOPSIS
	ussd set noroutingruleconfigerrmssg <message>

DESCRIPTION
	This command is used to set the message to be displayed to the end user if the 
	USSD Gateway is not configured for the dialled short code. For example, if the 
	dialled short code is *345#, but the USSD Gateway is not configured with an 
	appropriate routing rule for this code, then the message displayed to the 
	end user will be the value set for the parameter 'noroutingruleconfigerrmssg'.

EXAMPLES
	ussd set noroutingruleconfigerrmssg Not valid short code. Please dial valid 
	short code.

	The above command will set the value of the parameter 
	'noroutingruleconfigerrmssg' as "Not valid short code. Please dial valid short 
	code." and the terminal will display the message "Parameter has been successfully 
	set". 
	
	You can verify this by issuing the 'ussd get noroutingruleconfigerrmssg' command 
	whose output will be as below:

	ussd get noroutingruleconfigerrmssg
	noroutingruleconfigerrmssg = Not valid short code. Please dial valid short code

Name
	ussd set dialogtimeouterrmssg

SYNOPSIS
	ussd set dialogtimeouterrmssg <message>

DESCRIPTION
	This command is used to set the error message to be displayed to the end user
	when a request timeout occurs. For example, if the dialed short code is *123#, and 
	the USSD Gateway is configured to route this request to a third party application
	'xyz' but the application 'xyz' takes longer than the time specified by the 
	value of the parameter 'dialogtimeout' to respond, then the USSD Gateway will kill
	the session and send an error message to be displayed to the user. This error 
	message displayed to the end user will be the value set for the parameter
	'dialogtimeouterrmssg'.

EXAMPLES
	ussd set dialogtimeouterrmssg Request timedout please try again after 
	sometime.

	The above command will set the value of the parameter 'dialogtimeouterrmssg' as 
	"Request timedout please try again after sometime." and the terminal will display 
	the message "Parameter has been successfully set". 
	
	You can verify this by issuing
	the 'ussd get dialogtimeouterrmssg' command whose output will be as below:

	ussd get dialogtimeouterrmssg
	dialogtimeouterrmssg = Request timedout please try again after sometime

Name
	ussd set servererrmssg

SYNOPSIS
	ussd set servererrmssg <message>

DESCRIPTION
	This command is used to set the message to be displayed to the end user when there
	is an error in the USSD Gateway. For example if the application server
	responds to the Gateway's request with a NOT OK (200) response or with an OK 
	response but the XML Payload is corrupt, then the USSD Gateway will kill the 
	session and send a Server error message to be displayed to the end user specified 
	by the value of this paramter 'servererrmssg'. 

EXAMPLES
	ussd set servererrmssg Server error, please try again after sometime

	The above command will set the value for the parameter 'servererrmssg' to "Server 
	error, please try again after sometime" and the terminal will display the message 
	"Parameter has been successfully set". 

	You can verify this by issuing the 
	'ussd get servererrmssg' command whose output will be as below:

	ussd get servererrmssg
	servererrmssg = Server error, please try again after sometime

Name
	ussd set dialogtimeout

SYNOPSIS
	ussd set dialogtimeout <timeout-value>

DESCRIPTION
	This command is used to set the request timeout duration in milliseconds.
	For	example, the end user dials the short code *123#, and the USSD
	Gateway is configured to route this request to a third party application
	'xyz'. The value of the parameter 'dialogtimeout' is the maximum time
	allowed by the Gateway for the application 'xyz' to respond. If the
	application 'xyz' takes longer than the time specified by the value of
	the parameter 'dialogtimeout' to respond, then the USSD Gateway will kill
	the session and send an error message to be displayed to the user.
	Pay attention that "Dialog Timeout" can not be bigger than TCAP Dialog
	timeout value (that equals by default 1 minute by default). If you want to
	setup "Dialog Timeout" value you have to care also for TCAP Dialog timeout.
	Look at "TCAP" chapture of Mobicents jSS7 Stack User Guide.

EXAMPLES
	ussd set dialogtimeout 25000

	The above command will set the value of the parameter 'dialogtimeout' to  25000
	milliseconds and the terminal will display the message "Parameter has been 
	successfully set". 
	
	You can verify this by issuing the 'ussd get dialogtimeout' command whose 
	output will be as below:

	ussd get dialogtimeout
	dialogtimeout = 25000

Name
	ussd set hrhlrnumber

SYNOPSIS
	ussd set hrhlrnumber 

DESCRIPTION
	This command is used to set the HLR address to be used, instead of MSISDN, to
	be included in the 'calledPartyAddress' field of the SCCP address in the
	'SendRoutingInfo' message (PUSH mode). This parameter is required in scenarios 
	when the SMSC GW is also configured, specifically in Home Routing mode. 
	If this parameter is not set the default value is '-1' implying MSISDN address 
	will be used. 
	
EXAMPLES
	ussd set hrhlrnumber9823232322

	The above command will set the value of the parameter 'hrhlrnumber' to
	9823232322. You can verify this by issuing the 'ussd get hrhlrnumber' command.

Name
	ussd set cdrloggingto

SYNOPSIS
	ussd set cdrloggingto <Database | Textfile>

DESCRIPTION
	This command is used to set CDR logging to either Database or Textfile. 
	By default, the value is Textfile and all transactions are logged to a
	plain text file.

Name
	ussd set ussdgt

SYNOPSIS
	ussd set ussdgt  networkid 

DESCRIPTION
	This command is used to set a value for USSD 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 "ussd set ussdgt 0 networkid ") -
	this will just clear Global Title for an specified networkid.

EXAMPLES
	ussd set ussdgt912020015
	ussd set ussdgt912020015 networkid 2

	The above command will set the value for the parameter 'globalTitle' to 
	'912020015'and the terminal will display the message 
	"Parameter has been successfully set".
	The first command assigns ussdgt for networkId=0,
	the second command assigns ussdgt for networkId=2

	You can verify this by issuing the 'ussd get ussdgt' command.

	ussd get ussdgt
	ussdgt =912020015

Name
	ussd set ussdssn

SYNOPSIS
	ussd set ussdssn <ussdSubSystemNumber>

DESCRIPTION
	This command is used to set the value for USSD Sub System Number (SSN). Issuing 
	this command in CLI will set the SSN value but you must ensure that the SSN value
	is properly configured in the TCAP Stack in the xml descriptor file
	'mobicents-ussdgateway-version/jboss-5.1.0.GA/server/<profile>/deploy/
	 mobicents-ussd-gateway/META-INF/jboss-beans.xml'

EXAMPLES
	ussd set ussdssn 6

	The above command will set the value for the parameter 'ussdSubSystemNumber' to 
	'6'and the terminal will display the message 
	"Parameter has been successfully set". 

	You can verify this by issuing the 'ussd get ussdssn' command.

	ussd get ussdssn
	ussdssn = 6

Name
	ussd set hlrssn

SYNOPSIS
	ussd set hlrssn <hlrSubSystemNumber>

DESCRIPTION
	This command is used to set the value for HLR Sub System Number (SSN). 

EXAMPLES
	ussd set hlrssn 7

	The above command will set the value for the parameter 'hlrSubSystemNumber' to 
	'7'and the terminal will display the message 
	"Parameter has been successfully set". 

	You can verify this by issuing the 'ussd get hlrssn' command.

	ussd get hlrssn
	hlrssn = 7

Name
	ussd set mscssn

SYNOPSIS
	ussd set mscssn <mscSubSystemNumber>

DESCRIPTION
	This command is used to set the value for MSC Sub System Number (SSN). 

EXAMPLES
	ussd set mscssn 8

	The above command will set the value for the parameter 'mscSubSystemNumber' to 
	'8'and the terminal will display the message 
	"Parameter has been successfully set". 

	You can verify this by issuing the 'ussd get mscssn' command.

	ussd get mscssn
	mscssn = 8

Name
	ussd set maxmapv

SYNOPSIS
	ussd set maxmapv <version-number>

DESCRIPTION
	This command is used to set the value for MAP Application Context version. The 
	version number set here will be used for SendRoutingInfo operation. 
	Mobicents USSD Gateway supports version negotiation.  So if you set this to a
	higher version (say for example version 2, however your network only understands 
	version 1), the ussd Gateway will automatically do the version negotiation and 
	exchange V1 messages when V2 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.

EXAMPLES
	ussd set maxmapv 3

	The above command will set the value for the parameter 'version-number' to 
	'3'and the terminal will display the message 
	"Parameter has been successfully set". 

	You can verify this by issuing the 'ussd get maxmapv' command.

	ussd get maxmapv
	maxmapv = 3

Name
	ussd scrule show

SYNOPSIS
	ussd scrule show <short-code> <networkid>

DESCRIPTION
	This command is used to view the details of all or specified configured
	routing rules in the USSD Gateway.
	If you run a CLI command without <short-code> and <networkid> parameters,
	then all rules will be displayed. If you specify both <short-code> and
	<networkid> parameters, then the rule for the specified short code and
	the networkid if such rule is configured. If you specify only
	<short-code> parameter, then the rule for the specified short code and
	networkid==0 if such rule is configured.

Name
	ussd scrule create

SYNOPSIS
	ussd scrule create <short-code> <url> <flag> <protocol> <network-id>

DESCRIPTION
	This command is used to create a new routing rule for a short code for 
	PULL case only. This is not applicable for PUSH case.
	You can create a separate routing rule for an equal short code for each
	networkId. This means that a short code and networkId pair is used as a
	routing rule identifier.

PARAMETERS
	Standard Parameters

	short-code  - USSD short code which when dialed by user and received 
				by USSD Gw, will forward request to configured URL

	url			- If rule is configured as HTTP, this should be the URL
				where HTTP POST with XML payload should be forwarded to.
				If rule is configured as SIP, INVITE will be sent to this 
				ip:port

    Optional Parameters

	flag		- flag is either true or false, default is true. If true that 
				means this is exact match between the configured short code and the
				dialed by subscriber value. If false, that means the dialed 
				short-code begins with configured short-code. For example 
				if you created below rule, and user dials *123*7776543*223#, 
				it will match the rule and request will be forwarded to the 
				URL http://myip:8080/mobiussd/recharge.

				ussd scrule create *123* http://myip:8080/mobiussd/recharge false

	protocol	- USSD Gateway supports 2 protocols - HTTP and SIP (3GPP
				Specification 24.390). If not specified default is HTTP.
				If protocol is HTTP, gateway will forward request as HTTP POST.
				If its SIP, INVITE will be sent SIP Client.

	networkid	- USSD Gateway can be connected to multiple operators/network
				at same time and each operator exposing same or different short-code.
				Each operator (jSS7 stack configured) has its unique networkid assigned
				and incoming request can be matched with configured networkid here.
				Only if short-code and networkid match's, request is forwarded to
				corresponding url. Default value is 0.

EXAMPLES
    ussd scrule create *519# http://localhost:8080/ussddemo/test

	The above command will create a new routing rule in the USSD Gateway for
	the short code *519#. When the user dials the short code *519#, the USSD
	Gateway will direct the HTTP POST request to the URL
	http://localhost:8080/ussddemo/test as specified by the routing rule.
	This rule will belong to the default networkId 0.

    ussd scrule create *916* http://localhost:8080/ussddemo/test2 true HTTP 2	

	The above command will create a new routing rule in the USSD Gateway for
	the short codes that are started from *916*. 
	Gateway will direct the HTTP POST request to the URL
	http://localhost:8080/ussddemo/test2 as specified by the routing rule.
	This rule will belong to the networkId 2.

    ussd scrule create *123* 127.0.0.1:5065 true SIP

	The above command will create a new routing rule in the USSD Gateway for
	the short codes that are started from *123*.
	Gateway will direct the SIP INVITE request to 127.0.0.1:5065.
	This rule will belong to the default networkId 0.

    ussd scrule create *321# 127.0.0.1:5066 SIP 4

	The above command will create a new routing rule in the USSD Gateway for
	the short code *321#.
	Gateway will direct the SIP INVITE request to 127.0.0.1:5066.
	This rule will belong to the networkId 4.

Name
	ussd scrule modify

SYNOPSIS
    ussd scrule modify <short-code> <url> <flag> <protocol> <network-id>

DESCRIPTION
	This command is used to modify a new routing rule for a short code for 
	PULL case only. This is not applicable for PUSH case.
	A short code and networkId pair is used as a unique routing rule identifier.

PARAMETERS
	Standard Parameters

	short-code	- USSD short code which when dialed by user and received 
				by USSD Gw, will forward request to configured URL

	url			- If rule is configured as HTTP, this should be the URL
				where HTTP POST with XML payload should be forwarded to.
				If rule is configured as SIP, INVITE will be sent to this 
				ip:port

    Optional Parameters

	flag		- flag is either true or false, default is true. If true that 
				means this is exact match between the configured short code and the
				dialed by subscriber value. If false, that means the dialed 
				short-code begins with configured short-code. For example 
				if you created below rule, and user dials *123*7776543*223#, 
				it will match the rule and request will be forwarded to the 
				URL http://myip:8080/mobiussd/recharge.

				ussd scrule create *123* http://myip:8080/mobiussd/recharge false

	protocol	- USSD Gateway supports 2 protocols - HTTP and SIP (3GPP
				Specification 24.390). If not specified default is HTTP. If
				protocol is HTTP, gateway will forward request as HTTP POST.
				If its SIP, INVITE will be sent SIP Client.

    networkid	- USSD Gateway can be connected to multiple operators/network at same time
				and each operator exposing same or different short-code. Each operator 
				(jSS7 stack configured) has its unique networkid assigned and incoming
				request can be matched with configured networkid here. Only if short-code 
				and networkid match's, request is forwarded to corresponding url. Default
				value is 0.

EXAMPLES
    ussd scrule modify *519# http://localhost:8080/ussddemo/test

    Above rule will update the routing rule for the short code *519# and
    networkId 0 for HTTP url http://localhost:8080/ussddemo/test and the
    matching flag "false".

    ussd scrule modify *916* http://localhost:8080/ussddemo/test2 true HTTP 2	

    Above rule will update the routing rule for the short code *916* and
    networkId 2 for HTTP url http://localhost:8080/ussddemo/test2 and the
    matching flag "true".

    ussd scrule modify *123* 127.0.0.1:5065 true SIP

    Above rule will update the routing rule for the short code *123* and
    networkId 0 for SIP destination 127.0.0.1:5065 and the matching flag
    "true".

    ussd scrule modify *321# 127.0.0.1:5066 SIP 4

    Above rule will update the routing rule for the short code *321# and
    networkId 4 for SIP destination 127.0.0.1:5066 and the matching flag
    "false".

Name
	ussd scrule delete

SYNOPSIS
	ussd scrule delete <short-code> <networkid>

DESCRIPTION
	This command is used to delete an existing routing rule for a short code .
	A short code and networkId pair is used as a unique routing rule identifier.
	
	Standard Parameters
	
	short-code	- USSD short code which when dialed by user and received 
				by USSD Gw, will forward request to configured URL

	Optional Parameters

	networkid	- USSD Gateway can be connected to multiple operators/network at
				same time and each operator exposing same or different short-code.
				Each operator (jSS7 stack configured) has its unique networkid assigned
				and incoming request can be matched with configured networkid here.
				Only if short-code and networkid match's, request is forwarded to
				corresponding url. Default value is 0.

EXAMPLES
	ussd scrule delete *519#
	
	The above command will delete the routing rule in the USSD Gateway for the
	short code *519# and network-id 0.
	
	ussd scrule delete *519# 1
	
	The above command will delete the routing rule in the USSD Gateway for the
	short code *519# and network-id 1.

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

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 110255255
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 8 0 1 4 * solitary 1 origination-type localOriginated
sccp rule create 2 K 82 0 8 0 1 4 * solitary 2 origination-type remoteOriginated
sccp rsp create 1 1 0 0
sccp rss create 1 1 8 0

ussd set dialogtimeout 25000
ussd set ussdgt923330053058
ussd set ussdssn 8
ussd set hlrssn 6
ussd set mscssn 8
ussd set maxmapv 3

ussd scrule create *519# http://127.0.0.1:8080/ussddemo/test true HTTP
ussd scrule create *518# http://127.0.0.1:5080 true SIP

The post USSD – Configuring appeared first on Telestax Docs Online.

Restcomm USSD Gateway supports implementation of HTTP 1.1 standards and acts as a HTTP Client invoking the HTTP Application deployed on the third-party Application Server. The HTTP Request/Response carries XML payload with USSD specific information.

The HTTP callback mechanism allows the third-party Application to be agnostic to Operating System, Programming Language and Framework. The third-party Application could be one of the following technologies on any Operating System:

• Apache Tomcat, JBoss AS, Oracle Application Server, IBM Websphere etc for JSP/Servlet on Java
• PHP
• Microsoft IIS for ASP

HTTP errors are supported and recognized by the USSD Gateway

7.1. HTTP Message Structure – USSD Pull

The diagram below depicts an example message sequence for interacting with the Restcomm USSD Gateway HTTP API.

1. When the subscriber initiates a USSD Request, the HLR sends a MAP_PROCESS_UNSTRUCTURED_SS_REQUEST to the USSD Gateway.
2. Upon receipt of the MAP_PROCESS_UNSTRUCTURED_SS_REQUEST of type Begin, USSD Gateway invokes the third-party Application through a HTTP POST Request, carrying an XML Payload with USSD specific information. The XML Structure of this payload is explained in the sections below.
3. The third-party Application will now get a new Session and maintain it till the last response. The Application will send aHTTP Response, carrying an XML Payload, to the USSD Gateway.
4. The USSD Gateway will send a MAP_UNSTRUCTURED_SS_REQUEST of type Continue to the HLR.
5. The Subscriber will receive a menu to choose from and reply. When the subscriber replies, the HLR will send aMAP_UNSTRUCTURED_SS_RESPONSE of type Continue to the USSD Gateway.
6. The USSD Gateway will send a HTTP POST Request, carrying an XML Payload, to the third-party Application in the same session.
7. Based on the input from the subscriber, the third-party Application will send a final response (HTTP Response, carrying an XML Payload) and invalidate the session.
8. The USSD Gateway will send a MAP_PROCESS_UNSTRUCTURED_SS_RESPONSE of type End to the HLR. Consequently, the subscriber will receive a final response.

7.2. HTTP Message Structure – USSD Push

For USSD PUSH, the third party application should send a HTTP POST request to the Restcomm USSD Gateway. The URL for sending this is http://<bind address of JBoss>:8080/mobicents. The diagram below depicts an example message sequence (USSD Push) for interacting with the Restcomm USSD Gateway HTTP API.

7.3. HTTP Payload

7.3.1. XML Structure

The HTTP Request/Response carries XML Payload with USSD specific information as defined below:

<dialog type="Begin" appCntx="networkUnstructuredSsContext_version2"
	networkId="0" localId="1" remoteId="1" mapMessagesSize="1"
	returnMessageOnError="false">
	....
	....
	....
</dialog>

7.3.2. Dialog Attributes

The XML element <dialog> contains various attributes to represent the state and the parameters of the Dialog. Some of them are mandatory while others are optional. This section explains in detail all possible attributes and what they represent. The list of mandatory attributes that a USSD application must supply will be described for an each concrete response.

Parameters

type

Represents the state of the Dialog. This parameter is for information only and is not used by the USSD Gateway to take any decision on the fate of the underlying MAP Dialog. The possible values for ‘type’ are:Unidirectional, Begin, End, Continue, Abort, Unknown. You do not need to supply this parameter in payload from HTTP App.

appCntx

Represents the MAP Application Context for USSD GW request. Now it always “networkUnstructuredSsContext_version2”. You do not need to supply this parameter in payload from HTTP App. For outgoung USSD operations it is always networkUnstructuredSsContext version 2. For outgoing SRI request an initial MAP operation version is defined by the ‘maxmapv’ parameter configured in Section 6.6.11, “MAP Application Context version”.

networkId

Represents a networkId value. USSD Gateway can be connected to multiple operators/network at same time. For each operator unique networkId is assigned. In the initial PUSH (unstructuredSS-Request or unstructuredSS-Notify) message HTTP app can specify networkId parameter for forsing of usage of desired network operator. If this value is missed then the default value (“0”) will be used.

localId

Represents the local TCAP transaction ID. You do not need to supply this parameter in payload from HTTP App because localId values for all outgoing MAP dialogs is assigned by TCAP stack itself. All subsequent messages from the USSD Gateway will have the actual value.

remoteId

Represents the remote TCAP transaction ID. You do not need to supply this parameter in payload from HTTP App.

mapMessagesSize

Represents the actual number of MAP messages carried in the <dialog>. This value can be 0 if no MAP messages are carried or 1 when a USSD message is present. This parameter is mandatory in payload from HTTP App and is usually “1” when you are sending a message or “0” for an empty TC-END response in PUSH case.

returnMessageOnError

For USSD GW originated XMP payload this parameter corresponds to SCCP message returnMessageOnError parameter. You can supply this parameter in payload from HTTP App. This will affect to outgoing SCCP messages. (SCCP will return the notification is the message has non been delivered to the peer). Mostly we do not need to specify this parameter. By default this is true.

prearrangedEnd

This parameter can only be present in payload from HTTP App. If this parameter is present, it means the underlying TCAP Dialog will be closed. The value can be true or false. If it is false, the messages will be sent to peer and the TCAP dialog ended. If it is true, all the messages in the Dialog are dropped and the Dialog is closed without informing peer. If this parameter is not present, all the messages in the Dialog are sent to peer as TCAP Continue. If you do not want to close dialog this step do not include this parameter. If you want to close dialog this step include this parameter with value “false”.

mapAbortProviderReason

If this parameter is present, it means the underlying Dialog is Provider Aborted. The example below will describe in detail:

<dialog type="Unknown" localId="12" remoteId="13" mapMessagesSize="0" 
mapAbortProviderReason="SupportingDialogueTransactionReleased" 
returnMessageOnError="false">
	<errComponents/>
</dialog>

The possible values for mapAbortProviderReason areProviderMalfunction, SupportingDialogueTransactionReleased, ResourceLimitation, MaintenanceActivity, VersionIncompatibility, AbnormalMAPDialogueLocal, AbnormalMAPDialogueFromPeerand InvalidPDU. You do not need to supply this parameter in payload from HTTP App.

mapRefuseReason

If this parameter is present, it means the underlying Dialog is refused by peer. The example below will describe in detail:

<dialog type="Unknown" localId="12" remoteId="13" mapMessagesSize="0" 
mapRefuseReason="NoReasonGiven" returnMessageOnError="false">
	<errComponents/>
</dialog>

The possible values for mapRefuseReason areApplicationContextNotSupported, InvalidDestinationReference, InvalidOriginatingReference, NoReasonGiven, RemoteNodeNotReachableand PotentialVersionIncompatibility. You do not need to supply this parameter in payload from HTTP App.

mapUserAbortChoice

If this parameter is present, it means peer user has aborted Dialog. The example below will describe in detail:

<dialog type="Unknown" localId="12" remoteId="13" mapMessagesSize="0" 
mapUserAbortChoice="isUserSpecificReason" returnMessageOnError="false">
	<errComponents/>
</dialog>

The possible values for mapUserAbortChoice areisProcedureCancellationReason_handoverCancellation, isProcedureCancellationReason_radioChannelRelease, isProcedureCancellationReason_networkPathRelease, isProcedureCancellationReason_callRelease, isProcedureCancellationReason_associatedProcedureFailure, isProcedureCancellationReason_tandemDialogueRelease, isProcedureCancellationReason_remoteOperationsFailure, isResourceUnavailableReason_shortTermResourceLimitation, isResourceUnavailableReason_longTermResourceLimitation, isUserResourceLimitationand isUserSpecificReason. Even the HTTP App can Abort a specific Dialog by setting this value and sending it to the USSD Gateway.

dialogTimedOut

If this parameter is present, it means the underlying TCAP Dialog has timedout. The deafult value of TCAP Dialog timeout should always be greater than USSD Timeout value set in Section 6.6.4, “Dialog Timeout”.

<?xml version="1.0" encoding="UTF-8" ?>
<dialog type="Unknown" localId="12" remoteId="13" mapMessagesSize="0" dialogTimedOut="true" 
returnMessageOnError="false">
	<errComponents/>
</dialog>

You do not need to supply this parameter in payload from HTTP App.

emptyDialogHandshake

This parameter can only be present in payload from HTTP App. This is used only when USSD gateway is initiating Dialog (Push case). This parameter indicates that USSD Gateway should firstly send empty dialog (without USSD Payload) and only once dialog is accepted by peer, USSD message should be sent.

<dialog mapMessagesSize="1" emptyDialogHandshake="true">
...
...
</dialog>

customInvokeTimeOut

This parameter can only be present in payload from HTTP App. Each MAP operation has its own default invoke timeout, for example for the unstructuredSS-Request MAP operation default invoke timeout is 10 min. HTTP App can set custom invoke timeout for each USSD message it sends to other end by using of this parameter (value is in milliseconds).

Pay attention that customInvokeTimeOut can not be bigger than TCAP Dialog timeout value (that equals by default 1 minute by default). If you want to setup customInvokeTimeOut value you have to care also for TCAP Dialog timeout. Look at “TCAP” chapture of Restcomm jSS7 Stack User Guide.

invokeTimedOut

This parameter indicates the invoke sent by USSD Gw has timed out. This generally means user has taken longer than expected to respond to USSD message. HTTP App can set custom invoke timeout for each ussd message by setting customInvokeTimeOut explained above. Once invoke timesout, USSD gateway will automatically abort the Dialog and send corresponding message to HTTP App. You do not need to supply this parameter in payload from HTTP App.

userObject

Application can set some user specific String value that the USSD gateway will always send back in corresponding messages exchanged:

7.3.3 Child Elements

The element <dialog> may contain any of these child elements but the order has to be respected. The possible child elements and the order to be followed, if present, must be as in the below list:

• SCCP Address
• AddressString
• Error Components
• processUnstructuredSSRequest_Request
• processUnstructuredSSRequest_Response
• unstructuredSSRequest_Request
• unstructuredSSRequest_Response
• unstructuredSSNotify_Request
• unstructuredSSNotify_Response

 

 7.3.3.1. SCCP Address

 

Dialog carries SCCP information like <localAddress>, which is the SCCP Address of USSD gateway and <remoteAddress>, which is the SCCP address from where the Dialog is initiated, in case if this Dialog is received from other side (USSD Pull) or SCCP Address of remote side, incase of USSD Gateway acting as Proxy. Both the elements are optional and if they are not passed, the USSD Gateway will get the values from the Global Title configured from Section 6.6.7, “USSD Global Title” for <localAddress>. If the USSD Gateway is acting as proxy, it mandatory to set the <remoteAddress>, else this parameter is ignored. Attributes of SCCP (localAddress and remoteAddress) address are:

• pc: Mandatory parameter. Represents the point code.
• ssn: Mandatory parameter. Represents the Sub System Number.

Child elements of SCCP Address are <ai> and <gt>, where <ai> is Address indicator and suggests if routing is based on PC + SSN or GT. If it is based on GT, include <gt> element. Please refer to the examples below:

a) Routing based on PC + SSN

	
		
	

b) Routing based on GT
	
		
		9960639902"/>

 

Different Gloabl Titles are GlobalTitle0001, GlobalTitle0010, GlobalTitle0011 and GlobalTitle0100. For more details about SCCP, please refer to the jSS7 Admin Guide included in the documentation.

7.3.3.2. AddressString

Dialog carries the AddressString information like <destinationReference> and <originationReference>. The attributes of AddressString are defined below:

"nai" : nature of address indicator. The values are 
	0 : unknown
	1 : international_number
	2 : national_significant_number
	3 : network_specific_number
	4 : subscriber_number
	5 : reserved
	6 : abbreviated_number
	7 : reserved_for_extension

"npi" : Numbering plan. The values are 
	0 : unknown
	1 : ISDN
	2 : spare_2
	3 : data
	4 : telex
	5 : spare_5
	6 : land_mobile
	7 : spare_7
	8 : national
	9 : private_plan
	15 : reserved

"number" : The actual number

The XML example is 
204208300008002" nai="international_number" npi="land_mobile"/>
204208300008002" nai="international_number" npi="ISDN"/>

 

7.3.3.3. Error Components

If peer reports ErrorComponents, same is forwarded to the Application through the child element <errComponents/>. The example of payload is:

<dialog type="End" networkId="0" localId="0" remoteId="0" mapMessagesSize="0" sriPart="true" emptyDialogHandshake="true" returnMessageOnError="false">
	<errComponents>
		<invokeId value="1"/>
		<errorComponent type="MAPErrorMessageAbsentSubscriberSM" errorCode="6">
			<absentSubscriberDiagnosticSM value="IMSIDetached"/>
		</errorComponent>
	</errComponents>
</dialog>

 

7.3.3.4. processUnstructuredSSRequest_Request

This message is always sent by the USSD Gateway to the Application as a HTTP POST request or from the Application to the USSD Gateway if it is acting as Proxy. The Application should always send back processUnstructuredSSResponseindicating that it is the last message of this dialog or can also send unstructuredSSRequest indicating that the Application is expecting more response from the user (menu structure).

The Attributes of processUnstructuredSSRequest_Request are defined below:

• “invokeId” : All message types have the mandatory invokeId attribute helping to relate the response to request. For example, processUnstructuredSSResponse will have the same invokeId as carried byprocessUnstructuredSSRequest. Hence if the Application has a multi-level menu, it should store the invokeId, received in the processUnstructuredSSRequest in a HTTP Session, for later use. Also for every new request in the same dialog,invokeId should be incremented by 1. For example when the Application sends unstructuredSSRequest to a receivedprocessUnstructuredSSRequest with invokeId equal to zero, it should set the invokeId equal to 1 inunstructuredSSRequest.
• “dataCodingScheme” : The Attribute dataCodingScheme is mandatory and represents the actual USSD Message.dataCodingScheme is the encoding parameter of the USSD Message.
• “string” : The Attribute string is mandatory and represents the USSD String length. In GSM 0902 160, octets are stated as the maximum length for the USSD String. However due to underlying signalling layers the maximum length of the USSD string depends on the message and can be less than 160.

The XML structure is defined below:

79273605819"/>

Child elements of processUnstructuredSSRequest_Request are <msisdn> and <alertingPattern>. The child element <msisdn> is optional and included only if the actual MAP message received by the USSD Gateway carries this value. This is MSISDN of the user who originated this request.

Note

If is not included in processUnstructuredSSRequest, originationReference will be included in the dialog and this will be the MSISDN of the user originating the request.

<alertingPattern> is also an optional attribute.

7.3.3.5. processUnstructuredSSRequest_Response

This message is always sent by the Application to the USSD GateWay as a response to the receivedprocessUnstructuredSSRequest or unstructuredSSResponse. If the USSD Gateway is acting as Proxy, this message is sent from the USSD Gateway to the Application. This should always be the last message in the dialog.

The XML structure is defined below:

<processUnstructuredSSRequest_Response invokeId="0" dataCodingScheme="15" string="Thank You!"/>

7.3.3.6. unstructuredSSRequest_Request

This message is sent by the Application to the USSD GateWay in response to the received processUnstructuredSSRequestor unstructuredSSResponse in case of USSD Pull. In case of USSD Push, the Application can send this message to initiate a tree based menu push. This indicates that the Application is expecting some response from the user. If the USSD Gateway is acting as Proxy, this message is sent by the USSD Gateway to the Application.

The XML structure is defined below:

<unstructuredSSRequest_Request invokeId="0" dataCodingScheme="15" string="USSD String : Hello World&#10; 1. Balance&#10; 2. Texts Remaining"/>

7.3.3.7. unstructuredSSRequest_Response

This message is sent by the USSD GateWay to the Application in HTTP POST request. This is a response tounstructuredSSRequest sent by the Application earlier. If the USSD Gateway acts as proxy, this message is sent by the Application to the USSD Gateway in response to unstructuredSSRequest_Request received by the Application.

The XML structure is defined below:

<unstructuredSSRequest_Response invokeId="0" dataCodingScheme="15" string="1"/>

7.3.3.8. unstructuredSSNotify_Request

This message is sent by the Application to the USSD GateWay to initiate USSD Push. This is just to notify the user and no input is expected back from the user. If the USSD Gateway is acting as proxy, this message is sent by USSD Gateway to the Application.

The XML structure is defined below: <unstructuredSSNotify_Request invokeId=”0″ dataCodingScheme=”15″ string=”Your new balance is 34.38 AFN and expires on 30.07.2012. Cost of last event was 0.50 AFN.”/>

7.3.3.9. unstructuredSSNotify_Response

This message is sent by the USSD Gateway to the Application in response to unstructuredSSNotify_Request sent by the Application. If the USSD Gateway is acting as proxy, the Application will send this message to the USSD Gateway.

The XML structure is defined below:

<unstructuredSSRequest_Response invokeId="0"/>

7.3.3.10. Using non-Latin menu

If you wish to send non-Latin text (example, Cyrillic, Arabic, etc) then you must set the value of the attributedataCodingScheme to “72” (unlike the case of latin/digits where this is set to 15). You must ensure that any message text that contains non-Latin symbols must be UTF-8 encoded. The entire length of the message (in characters) must be less because this uses 2-byte encoding per character.

7.3.4. Typical usage of USSD application originated XML payload.

For USSD PULL case, a USSD application can usually issue following messages:

• PROCESS_UNSTRUCTURED_SS_RESPONSE
• UNSTRUCTURED_SS_REQUEST

For USSD PUSH case, a USSD application can usually issue following messages:

• UNSTRUCTURED_NOTIFY_REQUEST
• UNSTRUCTURED_SS_REQUEST
• RELEASE COMPLETE – finishing of a dialog

We will discuss few payload examples in this section.

7.3.4.1. PULL case – PROCESS_UNSTRUCTURED_SS_RESPONSE

Payload example:

<?xml version="1.0" encoding="UTF-8" ?>
<dialog mapMessagesSize="1" prearrangedEnd="false">
  <processUnstructuredSSRequest_Response invokeId="1" dataCodingScheme="15" string="Your balance is 1 USD"/>
</dialog>

This message must finish PULL Dialog so we set “prearrangedEnd=”false””. For USSD GW a count of internal messages is always 1, but this field is mandatory and we have to include it into a payload: mapMessagesSize=”1″. You have to also set “invokeId=”1″” record which must be equal invokeId from processUnstructuredSSRequest_Request. “dataCodingScheme” value is usually “15” (GSM7 encoding) or “72” (USC2 encoding). “string” is USSD string value. Pay attention that as for GSM specification USSD string length has maximum length 182 characters for GSM7 coding and 80 characters for USC2 encoding.

7.3.4.2. PULL case – UNSTRUCTURED_SS_REQUEST

Payload example:

<?xml version="1.0" encoding="UTF-8" ?>
<dialog mapMessagesSize="1">
  <unstructuredSSRequest_Request dataCodingScheme="15" string="Press 1 for paying or press 2 for aborting"/>
</dialog>

 

This message will continue PULL Dialog. “userObject” attribute is optional. You can use it for identification puposes. This value will be return to USSD application with the all next xml payloads.

7.3.4.3. PUSH case – UNSTRUCTURED_NOTIFY_REQUEST

Payload example:

<a id="xml_payload_examples_UNSTRUCTURED_NOTIFY_REQUEST"></a>

You are initiating a PUSH dialog. We need to include “msisdn” parameter which identifies a destination subscriber phone number (nai is “Nature of address”, npi means “Numeric plan”). “msisdn” parameter must be included only in the first unstructuredSSNotify_Request or unstructuredSSRequest_Request of the PUSH dialog.

7.3.4.4. PUSH case – UNSTRUCTURED_SS_REQUEST

Payload example:

<a id="xml_payload_examples_PUSH_UNSTRUCTURED_SS_REQUEST"></a>

7.3.4.5. PUSH case – RELEASE COMPLETE – finishing dialog

Payload example:

<?xml version="1.0" encoding="UTF-8" ?>
<dialog mapMessagesSize="0" prearrangedEnd="false">
</dialog>

PUSH dialog can include one or more UNSTRUCTURED_NOTIFY_REQUEST or UNSTRUCTURED_SS_REQUEST. After this USSD application must finish the dialog by this payload. PUSH dialog always uses several HTTP request to create, continue and terminatie it. For successfull processing it is needed to use a http cookie JSESSIONID. First http response contains a session cookie like “Set-Cookie: JSESSIONID=1379BF8AF4DB8CACF444AEA6375AD85E; Path=/mobicents”. Every next request must contain a tag like: “Cookie: JSESSIONID=1379BF8AF4DB8CACF444AEA6375AD85E” Every request (UNSTRUCTURED_SS_REQUEST and UNSTRUCTURED_NOTIFY_REQUEST) can contain extra parameter “customInvokeTimeout” in the dialog section to set up a custom invoke timeout (in milliseconds). For example (for 10 minutes invoke timeout):

 

The post USSD – HTTP Transfer Mechanism appeared first on Telestax Docs Online.

Restcomm USSD Gateway supports implementation of Session Initiation Protocol (SIP) for using Unstructured Supplementary Service Data (USSD) operations for mobile initiated MMI mode over IP Multimedia Core Network Subsystem (IMS). 3GPP Specification 24.390 “Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS” further explains flow of USSD over IMS leveraging SIP.

Restcomm USSD Gateway can easily be integrated with RestComm via SIP to enable developers to rapidly build voice, video, WebRTC, USSD, SMS, fax and rich messaging applications. More details about RestComm can be obtained from here

Following sections shows SIP flow and integration with RestComm. Instead of RestComm, user can easily integrate SIP phone that supports USSD.

The diagram below depicts an example message sequence for interacting with the Mobicents USSD Gateway SIP API. Belowflow assumes that third-party application sends back tree based menu.

1. When the subscriber initiates a USSD Request, the HLR sends a MAP_PROCESS_UNSTRUCTURED_SS_REQUEST to the USSD Gateway.
2. Upon receipt of the MAP_PROCESS_UNSTRUCTURED_SS_REQUEST of type Begin, USSD Gateway invokes the third-party Application through a SIP INVITE Request, carrying an XML Payload with USSD specific information. The XML Structure of this payload is explained in the sections below.
   

   <ussd-data>
       					<language>en</language>
       					<ussd-string>*123#</ussd-string>
       					<anyExt> 
          						<message-type>processUnstructuredSSRequest_Request</message-type> 
        					</anyExt> 
   					</ussd-data>

   
   The To Header of SIP INVITE Request carries MSISDN from where the USSD request is initiated.
3. The third-party Application will send SIP OK and after receiving SIP ACK, SIP Dialog is established between USSD Gateway and Application

   The third-party Application will then send SIP INFO Request, carrying an XML Payload with USSD specific information. The XML Structure of this payload is explained in the sections below.

   <ussd-data>
       					<language>en</language>
       					<ussd-string>Press 1 for SMS Credit and 2 for Call Credit</ussd-string>
       					<anyExt> 
          						<message-type>unstructuredSSRequest_Request</message-type> 
        					</anyExt> 
   					</ussd-data>

    

4. The USSD Gateway will send a MAP_UNSTRUCTURED_SS_REQUEST of type Continue to the HLR.
5. The Subscriber will receive a menu to choose from and reply. When the subscriber replies, the HLR will send aMAP_UNSTRUCTURED_SS_RESPONSE of type Continue to the USSD Gateway.
6. The USSD Gateway will send a SIP INFO Request, carrying an XML Payload, to the third-party Application in the same session. The XML Structure of this payload is explained in the sections below.

   <ussd-data>
       					<language>en</language>
       					<ussd-string>1</ussd-string>
       					<anyExt> 
          						<message-type>unstructuredSSRequest_Response</message-type> 
        					</anyExt> 
   					</ussd-data>

    

7. Based on the input from the subscriber, the third-party Application will send a final (SIP BYE Request, carrying an XML Payload) and invalidate the session.

   <ussd-data>
       					<language>en</language>
       					<ussd-string>Balance is 87 sms's</ussd-string>
       					<anyExt> 
          						<message-type>processUnstructuredSSRequest_Response</message-type> 
        					</anyExt> 
   					</ussd-data>

    

8. The USSD Gateway will send a MAP_PROCESS_UNSTRUCTURED_SS_RESPONSE of type End to the HLR. Consequently, the subscriber will receive a final response.

The diagram below depicts an example message sequence (USSD Push) for interacting with the Mobicents USSD Gateway SIP API. Below example initiate USSD Tree based menu.

The post USSD – SIP Transfer Mechanism appeared first on Telestax Docs Online.

******************Important Notice**********************

Mobicents Restcomm ships with G.729 codec. G.729 includes patents from several companies and is licensed by Sipro Lab Telecom. Sipro Lab Telecom is the authorized Intellectual Property Licensing Administrator for G.729 technology and patent pool.

In a number of countries, the use of G.729 may require a license fee and/or royalty fee.

****************************************

Step 1 – Stop Restcomm and Change the Media Server configuration

• Go to $RESTCOMM_HOME/mediaserver/deploy/server-beans.xml
• Find the Signal processort factory section as shown below

<!-- Signal processor factory -->
<bean name="DSP" class="org.mobicents.media.server.component.DspFactoryImpl">
    <property name="codecs">
        <list value-type="java.lang.String">
            <value>org.mobicents.media.server.impl.dsp.audio.l16.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.l16.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.alaw.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.alaw.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.ulaw.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.ulaw.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.gsm.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.gsm.Decoder</value>
        </list>
    </property>
</bean>

• Edit the section to add the G729 codec as shown below

<!-- Signal processor factory -->
<bean name="DSP" class="org.mobicents.media.server.component.DspFactoryImpl">
    <property name="codecs">
        <list value-type="java.lang.String">
            <value>org.mobicents.media.server.impl.dsp.audio.l16.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.l16.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.alaw.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.alaw.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.ulaw.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g711.ulaw.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.gsm.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.gsm.Decoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g729.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g729.Decoder</value>
        </list>
    </property>
</bean>

How to remove the G729 codec from the media server

• Remove the g729 codec from the $RESTCOMM_HOME/mediaserver/deploy/server-beans.xml file

<value>org.mobicents.media.server.impl.dsp.audio.g729.Encoder</value>
            <value>org.mobicents.media.server.impl.dsp.audio.g729.Decoder</value>

The post Restcomm – How to Add G729 Codec to the Media Server appeared first on Telestax Docs Online.

Environment variables

RestComm docker container provides the option to use a file to configure environment variables. These variable are used with the Restcomm Docker  RUN command.

• ENVCONFURL Set the URL for environment variables configuration file location/repository.
• REPOUSR Set Username for environment variables configuration file Authentication if needed.
• REPOPWRD Set Password for environment variables configuration file Authenitcation if needed.
• MEDIASERVER_LOGS_LOCATION Set the location were to store Mediaserver logs.

The RestComm docker image supports a set of environment variables to configure the application.

• STATIC_ADDRESS Set the public ip address that RestComm should use
• USE_STANDARD_PORTS Use Default ports such as 80, 443, 5060, …
• OUTBOUND_PROXY Set the SIP Outbound proxy
• OUTBOUND_PROXY_USERNAME Set the SIP Outbound proxy username
• OUTBOUND_PROXY_PASSWORD Set the SIP Outbound proxy password
• MEDIASERVER_LOWEST_PORT Set the Media Server lowest RTP port
• MEDIASERVER_HIGHEST_PORT Set the Media Server highest RTP port
• PROVISION_PROVIDER Set the Provision Provider, choose one of the following: VI (VoipInnovation), BW (Bandwidth), NX (Nexmo), VB (Voxbone)
• DID_LOGIN Set the DID Provider username
• DID_PASSWORD Set the DID Provider password
• DID_ENDPOINT Set the Endpoint ID for VoipInnovation Provision Provider
• DID_SITEID Set the Site Id for Bandwidth Provision Provider
• DID_ACCOUNTID Set the Account Id for Bandwidth Provision Provider
• INTERFAX_USER Set the Interfax username
• INTERFAX_PASSWORD Set the Interfax password
• ISPEECH_KEY Set the iSpeech speech recognition key
• VOICERSS_KEY Set the VoiceRss Text-To-Speech key
• ACAPELA_APPLICATION Set the Acapela Text-To-Speech application key
• ACAPELA_LOGIN Set the Acapela Text-To-Speech username
• ACAPELA_PASSWORD Set the Acapela Text-To-Speech password
• SMPP_TYPE Set the SMPP Type ie the unique name for the SMPP Connection and sets the SMPP to be enabled for the SMS API and RVD Tag
• S3_BUCKET_NAME Set the S3 Bucket Name so that Restcomm stores the Recording in Amazon Web Services S3 Service
• S3_ACCESS_KEY Set the S3 Access Key so that Restcomm stores the Recording in Amazon Web Services S3 Service
• S3_SECURITY_KEY Set the S3 Security Key so that Restcomm stores the Recording in Amazon Web Services S3 Service
• HSQL_PERSIST Path to use for persist date using HSQL.
• SMTP_USER Set the SMTP User so that Restcomm configures the SMTP Service for the Email API and RVD Tag
• SMTP_PASSWORD Set the SMTP Password so that Restcomm configures the SMTP Service for the Email API and RVD Tag
• SMTP_HOST Set the SMTP Host so that Restcomm configures the SMTP Service for the Email API and RVD Tag
• MYSQL_USER Set the MySQL User so that Restcomm configures RestComm to use a MySQL DB instead of In memory DB
• MYSQL_PASSWORD Set the MySQL Password so that Restcomm configures RestComm to use a MySQL DB instead of In memory DB
• MYSQL_HOST Set the MySQL Host so that Restcomm configures RestComm to use a MySQL DB instead of In memory DB
• MYSQL_SCHEMA Set the MySQL Schema so that Restcomm configures RestComm to use a MySQL DB instead of In memory DB
• SSL_MODE Set the SSL Mode for Restcomm and RVD to query External Service over HTTPS. Values : allowall, strict
• RVD_LOCATION Set the Location for Restcomm Visual Designer to store the workspaces in a shared filesystem
• LOG_LEVEL Set the Log Level for Restcomm and MMS
• CORE_LOGS_LOCATION Set the location were to store Restcomm logs
• MEDIASERVER_LOGS_LOCATION Set the location were to store Mediaserver logs
• RESTCOMM_TRACE_LOG Set the location were to store network trace logs (pcap files)
• RESTCOMMHOST Set the hostname for this machine for RestComm to recognize it and use it for relative URL requests

HTTPS related configuration

• SECURESSL Configure RestComm to be used in secure mode ie only on HTTPS not HTTP and SIP Over Secure WebSockets + TLS (Values: AUTH – need to provide JKS file & DER file. SELF – self sighned certificate generation)
• TRUSTSTORE_PASSWORD Set the password to use for RestComm to configure the certificate for HTTPS and SIP TLS
• TRUSTSTORE_ALIAS Set the Alias to use for RestComm to configure the certificate for HTTPS and SIP TLS

SECURESSL=AUTH

• CERTCONFURL JKS file URL location
• CERTREPOUSR Username for authentication if needed.
• CERTREPOPWRD Password for authentications if needed
• DERCONFURL DER file URL location
• DERREPOUSR Username for authentication if needed
• DERREPOPWRD Password for authentication if needed

SMPP related configuration

• GENERIC_SMPP_TYPE The SMPP type
• GENERIC_SMPP_ID The SMPP id
• GENERIC_SMPP_PASSWORD The SMPP password
• GENERIC_SMPP_PEER_IP The SMPP peer IP Address
• GENERIC_SMPP_PEER_PORT The SMPP peer port
• GENERIC_SMPP_SOURCE_MAP The SMPP source map
• GENERIC_SMPP_DEST_MAP The SMPP destination map

The post Restcomm – Docker Environment Variables appeared first on Telestax Docs Online.

Using self signed certificate

In case you want to start RestComm container using a self-signed certificate, you use the SECURESSL environment variable set to “SELF”.

Example:

docker run -e SECURESSL="SELF" -e SSL_MODE="allowall" -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="VOICERSS_KEY_HERE" --name=restcomm -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

The generated truststore file will be located at /opt/Mobicents-Restcomm-JBoss-AS7/standalone/configuration/restcomm-combined.jks and the password $TRUSTSTORE_PASSWORD

The post Restcomm – Docker Using Self-signed Certificate appeared first on Telestax Docs Online.

RestComm binds to the ip address of the host and following ports:

• http: 8080
• sip/udp: 5080
• sip/tcp: 5080
• sip/tls: 5081
• sip/ws: 5082 (Used for WebRTC – SIP Over WebSockets)
• sip/wss: 5083 (Used for WebRTC – Secure SIP Over WebSockets)
• rtp/udp: 65000 – 65535

If you use -e USE_STANDARD_PORTS, RestComm will binds to the ip address of the host and following ports:

• http: 80
• sip/udp: 5060
• sip/tcp: 5060
• sip/tls: 5061
• sip/ws: 5062 (Used for WebRTC – SIP Over WebSockets)
• sip/wss: 5063 (Used for WebRTC – Secure SIP Over WebSockets)
• rtp/udp: 65000 – 65535

The post Restcomm – Docker Important Ports appeared first on Telestax Docs Online.

Persist your work using shared filesystem

You can persist the logs, database, recordings, text-to-speech cache and RVD workspace using shared filesystem, so even if you stop and remove your container, your work won’t be lost.

Download the restcomm_workspace that contains the default database, default RVD workspace and the required folders and unzip it to a folder in your filesystem.

Next run Restcomm image using the following volume arguments:

• Restcomm logs -v $YOUR_FOLDER/restcomm_workspace/restcomm/log:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/log
• Restcomm recordings -v $YOUR_FOLDER/restcomm_workspace/restcomm/recordings:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/recordings
• Restcomm tts cache -v $YOUR_FOLDER/restcomm_workspace/restcomm/cache:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/cache

HSQL database persistant data In order to properly manage to persist data on a host directory, it is necessary to use HSQL_PERSIST option. Then need to mount the volume set at the HSQL_PERSIST option at a directory on the host. (e.g. -v /$YOUR_FOLDER/restcomm_workspace/restcomm/data:/dir_to_HSQL_PERSIST)

__RestComm logs additional information __

If you are using specific log paths (CORE_LOGS_LOCATION, MEDIASERVER_LOGS_LOCATION, RESTCOMM_TRACE_LOG) use them to mount volumes to host. -V HOST_CORE_LOGS_LOCATION:CORE_LOGS_LOCATION -V HOST_MEDIASERVER_LOGS_LOCATION:MEDIASERVER_LOGS_LOCATION -V HOST_TRACE_LOGS_LOCATION:RESTCOMM_TRACE_LOG

Example if you unzip the restcomm_workspace.zip to /opt/restcomm_workspace/

•  docker run command will be:

docker run --name=restcomm --restart=always -d -e VOICERSS_KEY="YOUR_VOICERSS_KEY" -p 8080:8080 -p 5080:5080 -p 5080:5080/udp -p 65000-65535/udp -v /opt/restcomm_workspace/restcomm/log:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/log -v /opt/restcomm_workspace/restcomm/recordings:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/recordings -v /opt/restcomm_workspace/restcomm/cache:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/cache -v /opt/restcomm_workspace/restcomm/data:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/WEB-INF/data/hsql -v /opt/restcomm_workspace/mms/log:/opt/Mobicents-Restcomm-JBoss-AS7/mediaserver/log -v /opt/restcomm_workspace/rvd/workspace:/opt/Mobicents-Restcomm-JBoss-AS7/standalone/deployments/restcomm-rvd.war/workspace mobicents/restcomm:latest

The post Restcomm – Docker – How to Persist Your Work on a Filesystem appeared first on Telestax Docs Online.

You can run RestComm Docker image using the official Docker for OSX installation found at https://docs.docker.com/engine/installation/mac/ (more details on the issues at: https://github.com/Mobicents/Restcomm-Docker/issues/10). Here’s an alternative that works until those issues are fixed:

• Install Virtual Box
• Install a Docker-capable linux distribution as a guest in the Virtual Box (in this example we installed Ubuntu Server 14.04)
• Shut down guest
• Setup networking for guest, use ‘Bridged Adapter’ setting. That will make the guest reachable in the local LAN (for example if host is 192.168.2.3, guest would most likely get 192.168.2.4) and you won’t have to do any special port mapping
• Start up the guest
• Install latest docker inside the guest (https://docs.docker.com/engine/installation/ubuntulinux/)
• Download the latest docker image for RestComm $ sudo docker pull mobicents/restcomm:latest
• Start up the docker image using commands found above, in my case that I wanted a secure installation the command is: $


sudo docker run -e SECURESSL="true" -e SSL_MODE="allowall" -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="VOICERSS_KEY_HERE" --name=restcomm -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

• The RestComm installation is available from the host system at: https://<guest ip>/
• You can use the Olympus WebRTC Web App at: https://<guest ip>/olympus

The post Restcomm – Docker Image in OSX host appeared first on Telestax Docs Online.

Check the –env-file option that docker provides : docker

• The –env-file=[ ] reads the required environment variables from a file.
• Create a file similar to the one  HERE

Run the following command :

sudo docker run -i -d --name=restcomm -v /var/log/restcomm:/var/log/restcomm/ --env-file="/PATH/TO/FILE/restcomm_localenv_basic" -e STATIC_ADDRESS="IP_OF_SERVER" -e RESTCOMMHOST="ADD_HOSTNAME" -e LOG_LEVEL="INFO" -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

The post Restcomm – Docker How to Load Environment Variable from a File appeared first on Telestax Docs Online.

Automatically restart the container in case of a failure or host restart,

• Use the flag –restart-always

docker run -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="YOUR_VOICESS_KEY_HERE" --name=restcomm --restart=always -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

Get basic environment configuration file from RestComm-Docker repository

• Use the flag : ENVCONFURL

docker run -i -d  --name=restcomm -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_basic.sh"  -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

 To run on standard ports ie 80 for HTTP, 443 for HTTPs, 5060 for SIP,

• You have to use the USE_STANDARD_PORTS

docker run -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="YOUR_VOICESS_KEY_HERE" --name=restcomm -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

Provide your VoiceRSS key for Text-To-Speech and Outbound proxy

• set env variable VOICERSS_KEY and OUTBOUND_PROXY

docker run -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="YOUR_VOICESS_KEY_HERE" -e OUTBOUND_PROXY="YOUR_OUTBOUND_PROXY_HERE" --name=restcomm -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest

The post Restcomm – Docker Advanced Configuration appeared first on Telestax Docs Online.

This guide deals with scenarios where Telestax provides you with a Jar file as a patch or as a sponsored feature that requires testing before using in a production environment.

Apply new JAR to an already running container

The steps below will explain how to apply/overide specific jar on a running container.

Default jar files are located in the directory below

• /opt/TelScale-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/WEB-INF/lib/

To be able to change Restcomm jars in the WEB-INF/lib/ directory, you must :

Mount a host directory as a data volume as explained here(https://docs.docker.com/engine/userguide/dockervolumes/).
How to update the jar file

1. Login to the server through ssh.
2. Create a directory /tmp/lib/
3. Get the Restcomm docker container ID : sudo docker ps
4. Launch an interactive bash shell inside running container (enter to the container running) using:
5. sudo docker exec -it container_ID bash
6. Go to the directory :  cd /opt/TelScale-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/WEB-INF/lib/
7. copy all jars to the new directory.
8. cp * /tmp/lib/
9. Type exit to get out of the bash container
10. stop the running container: sudo docker stop Restcomm_Container_ID
11. Copy the new jar provided by Telestax to the /tmp/lib/ directory
12. The above step will replace one of the existing jar files
13. Add the following option to the docker run startup command
14. -v  /tmp/lib/:/opt/TelScale-Restcomm-JBoss-AS7/standalone/deployments/restcomm.war/WEB-INF/lib/
15. This will override the jars in the WEB-INF/lib/ with the jars in the /tmp/lib/ directory
16. Start the container for the changes to take effect
17. sudo docker start Restcomm_container_ID

This process can be repeated as required.

The post Restcomm – Docker Adding a Jar File to an Exiting Container appeared first on Telestax Docs Online.

Restcomm USSD Gateway exposes easy to use Java framework to serialize and deserialize the MAP messages. So if you are using Java Servlets for your business logic, this framework will make it very easy to compose your business logic. However using this framework is not mandatory and you are free to create your own XML parser.

Maven dependency

If you are using maven to build your project define following dependencies to use XML Framework in your project

<dependency>
            <groupId>org.mobicents.ussd</groupId>
            <artifactId>xml</artifactId>
            <version>6.1.5.GA</version>
        </dependency>

Note

Restcomm maintains the archieve in private repository. please add the following in your pom’s repositories tag

<repository>
          <id>mobicents-releases-repository</id>
          <name>Mobicents Releases Repository</name>
          <url>http://telestax.artifactoryonline.com/telestax/releases</url>
          <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>false</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>                
        </repository>
        <repository>
          <id>mobicents-snapshots-repository</id>
          <name>Mobicents Snapshots Repository</name>
          <url>http://telestax.artifactoryonline.com/telestax/snapshots</url>
          <releases>
            <enabled>false</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>                
        </repository>

 

         

Important

Restcomm Releases and Snapshots Repository are password protected. Ask support to get your password.

Once you have user name and password add following to your servers definition in your maven settings located in M2_HOME/conf/settings.xml

<server>
      <id>mobicents-releases-repository</id>
      <username>xxx</username>
      <password>xxx</password>
    </server>
    <server>
      <id>mobicents-snapshots-repository</id>
      <username>xxx</username>
      <password>xxx</password>
    </server>

Simple example – Tree based Menu

Below is the simple HttpServlet example to create a tree based menu structure. The flow of message is same as shown in Section 7.1, “HTTP Message Structure – USSD Pull”.

public class TestServlet extends HttpServlet {1 


    private static final Logger logger = Logger.getLogger(TestServlet.class);


    private EventsSerializeFactory factory = null;


    @Override

    public void init() {

            factory = new EventsSerializeFactory();2

    }


    @Override

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {

        

    }


    @Override

    public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException {3

        ServletInputStream is = request.getInputStream();

        try {

            Dialog original = factory.deserialize(is);4

            HttpSession session = request.getSession(true);5

            if (logger.isInfoEnabled()) {

                logger.info("doPost. HttpSession=" + session.getId() + " Dialog = " + original);

            }


            USSDString ussdStr = null;

            byte[] data = null;

            final FastList<MAPMessage> capMessages = original.getMAPMessages();


            MessageType messageType = original.getTCAPMessageType();


            // This is initial request, if its not NTFY, we need session

            for (FastList.Node<MAPMessage> n = capMessages.head(), end = capMessages

                    .tail(); (n = n.getNext()) != end;) {

                final MAPMessage rawMessage = n.getValue();

                final MAPMessageType type = rawMessage.getMessageType();


                switch (messageType) {

                

                    case Begin:6

                    switch (mapMessage.getMessageType()) {

                        case processUnstructuredSSRequest_Request:

                            ProcessUnstructuredSSRequest processUnstructuredSSRequest = (ProcessUnstructuredSSRequest) mapMessage;

                            CBSDataCodingScheme cbsDataCodingScheme = processUnstructuredSSRequest

                                .getDataCodingScheme();

                            if (logger.isInfoEnabled()) {

                                logger.info("Received ProcessUnstructuredSSRequestIndication USSD String="

                                        + processUnstructuredSSRequest.getUSSDString().getString());

                            }

                            

                            session.setAttribute(

                                "ProcessUnstructuredSSRequest_InvokeId",

                                processUnstructuredSSRequest.getInvokeId());7

                                                            

                            //You business logic here and finally send back response

                            

                            //Urdu

                            //CBSDataCodingScheme cbsDataCodingSchemeUrdu = new  CBSDataCodingSchemeImpl(72);

                            //ussdStr = new USSDStringImpl("\u062C\u0645\u064A\u0639 \u0627\u0644\u0645\u0633\u062A\u0639\u0645\u0644\u064A\u0646 \u0627\u0644\u0622\u062E\u0631\u064A\u0646 \u062A\u0645 \u0625\u0636\u0627\u0641\u062A\u0647\u0645",

                            //      cbsDataCodingSchemeUrdu, null);

                            //UnstructuredSSRequest unstructuredSSRequestIndication = new UnstructuredSSRequestImpl(

                            //      cbsDataCodingSchemeUrdu, ussdStr, null, null);

    

                            //English

                                                    

                            ussdStr = new USSDStringImpl(

                                "USSD String : Hello World\n 1. Balance\n 2. Texts Remaining",

                                cbsDataCodingScheme, null);

                            UnstructuredSSRequest unstructuredSSRequestIndication = new UnstructuredSSRequestImpl(

                                cbsDataCodingScheme, ussdStr, null, null);8

        

                            original.reset();

                            original.setTCAPMessageType(MessageType.Continue);

                            original.addMAPMessage(unstructuredSSRequestIndication);9

        

                            data = factory.serialize(copy);10

        

                            response.getOutputStream().write(data);

                            response.flushBuffer();11

        

                            break;

                        default:

                            // This is error. If its begin it should be only Process

                            // Unstructured SS Request

                            logger.error("Received Dialog BEGIN but message is not ProcessUnstructuredSSRequestIndication. Message="

                                    + mapMessage);

                            break;

                        }

    

                    break;

                    case Continue:12

                    switch (type) {

                    case unstructuredSSRequest_Response:

                        UnstructuredSSResponse unstructuredSSResponse = (UnstructuredSSResponseImpl) rawMessage;


                        CBSDataCodingScheme cbsDataCodingScheme = unstructuredSSResponse

                                .getDataCodingScheme();


                        long invokeId = (Long) session

                                .getAttribute("ProcessUnstructuredSSRequest_InvokeId");


                        USSDString ussdStringObj = unstructuredSSResponse

                                .getUSSDString();

                        String ussdString = null;

                        if (ussdStringObj != null) {

                            ussdString = ussdStringObj.getString(null);

                        }


                        logger.info("Received UnstructuredSSResponse USSD String="

                                + ussdString

                                + " HttpSession="

                                + session.getId() + " invokeId=" + invokeId);


                        cbsDataCodingScheme = new CBSDataCodingSchemeImpl(0x0f);

                        ussdStr = new USSDStringImpl("Thank You!", null, null);

                        ProcessUnstructuredSSResponse processUnstructuredSSResponse = new ProcessUnstructuredSSResponseImpl(

                                cbsDataCodingScheme, ussdStr);

                        processUnstructuredSSResponse.setInvokeId(invokeId);


                        original.reset();

                        original.setTCAPMessageType(MessageType.End);

                        original.addMAPMessage(processUnstructuredSSResponse);

                        original.close(false);


                        data = factory.serialize(original);


                        response.getOutputStream().write(data);

                        response.flushBuffer();


                        try {

                            session.invalidate();

                        } catch (Exception e) {

                            session.invalidate();

                            logger.error("Error while invalidating HttpSession="

                                    + session.getId());

                        }

                        break;

                    default:

                        // This is error. If its begin it should be only Process

                        // Unstructured SS Request

                        logger.error("Received Dialog CONTINUE but message is not UnstructuredSSResponseIndication. Message="

                                + rawMessage);

                        break;

                    }


                    break;

    

                case ABORT:

                    // The Dialog is aborted, lets do cleaning here

    

                    try {

                        session.invalidate();

                    } catch (Exception e) {

                        session.invalidate();

                        logger.error("Error while invalidating HttpSession=" + session.getId());

                    }

                    break;

            }


        } catch (XMLStreamException e) {

            logger.error("Error while processing received XML", e);

        }


    }

}

 

	A simple HttpServlet class that consumes the MAP messages, process the business logic and sends back response.
	Initiate the EventsSerializeFactory that can serialize/de-serialize the Dialog object. EventsSerializeFactory is further explained in Section 9.3, “EventsSerializeFactory”
	Restcomm USSD Gateway sends the HTTP POST request with XML Payload. The HttpServlet should always have business logic in doPost method.
	De-serialize received payload to Dialog object. Dialog is further explained in Section 9.4, “Dialog”
	Get access to underlying HttpSession. Again this is not mandatory and if your business logic is such that you don’t need tree based menu but simple request-response, you don’t have to store any state in HttpSession.
	If this is new request, the Dialog type is always BEGIN and the first MAP message in this new request will always beProcessUnstructuredSSRequest
	Set the invokeId from ProcessUnstructuredSSRequest in HttpSession so application can send backProcessUnstructuredSSResponse with same invokeId later. Again application don’t have to maintain the invokeId if its directly sending back ProcessUnstructuredSSResponse.
	Create a new UnstructuredSSRequest with custom message and send back to USSD gateway which will in-turn send it to Mobile User who initiated the request. By sending UnstructuredSSRequest application indicates that its waiting for further input from user. The application may receive UnstructuredSSResponse or ABORT in which case application sghould do cleaning of resources.
	Reset original Dialog set message type Continue add UnstructuredSSRequest message. Remember this Dialoginstance is only for serializing our request and shouldn’t be confused with MAP Dialog or HttpSession. Both MAP Dialog and HttpSession lives as long as conversation is alive between USSD gateway and Application for each unique user.
	Serialize new Dialog object to push byte array into HttpResponse
	Send the response back
	Once the user replies back, application gets CONTINUE Dialog with UnstructuredSSResponse. At this time depending on business logic, application can again send new UnstructuredSSRequest and expect back response from user or send final ProcessUnstructuredSSResponse response and close the session.

EventsSerializeFactory

This section provides the details for EventsSerializeFactory

public class EventsSerializeFactory {


    private static final String DIALOG = "dialog";

    private static final String TYPE = "type";

    private static final String TAB = "\t";


    final XMLBinding binding = new XMLBinding();


    public EventsSerializeFactory() {

        binding.setAlias(Dialog.class, DIALOG);

        binding.setClassAttribute(TYPE);

    }


    /**

     * Serialize passed {@link Dialog} object

     * 

     * @param dialog

     * @return serialized byte array

     * @throws XMLStreamException

     *             Exception if serialization fails

     */

    public byte[] serialize(Dialog dialog) throws XMLStreamException {


        final ByteArrayOutputStream baos = new ByteArrayOutputStream();

        final XMLObjectWriter writer = XMLObjectWriter.newInstance(baos);


        try {


            writer.setBinding(binding);

            writer.setIndentation(TAB);


            writer.write(dialog, DIALOG, Dialog.class);

            writer.flush();

            byte[] data = baos.toByteArray();


            return data;

        } finally {

            writer.close();

        }

    }


    /**

     * De-serialize the byte[] into {@link Dialog} object

     * 

     * @param data

     * @return de-serialized Dialog Object

     * @throws XMLStreamException

     *             Exception if de-serialization fails

     */

    public Dialog deserialize(byte[] data) throws XMLStreamException {

        final ByteArrayInputStream bais = new ByteArrayInputStream(data);

        final XMLObjectReader reader = XMLObjectReader.newInstance(bais);

        try {

            Dialog dialog = reader.read(DIALOG, Dialog.class);

            return dialog;

        } finally {

            reader.close();

        }

    }


    /**

     * De-serialize passed {@link InputStream} into {@link Dialog} object

     * 

     * @param is

     * @return de-serialized Dialog Object

     * @throws XMLStreamException

     *             Exception if de-serialization fails

     */

    public Dialog deserialize(InputStream is) throws XMLStreamException {

        final XMLObjectReader reader = XMLObjectReader.newInstance(is);

        try {

            Dialog dialog = reader.read(DIALOG, Dialog.class);

            return dialog;

        } finally {

            reader.close();

        }

    }

}

 

        

• The serialize method serializes Dialog and retruns back byte array.
• The deserialize is overloaded method. Application can either pass byte[] or InputStream and de-serializes the stream of data to Dialog object.

Dialog

This section provides the details for XmlMAPDialog

public class XmlMAPDialog implements Serializable {

    

    .....

    .....


    public XmlMAPDialog() {

        super();

    }


    /**

     * 

     */

    public XmlMAPDialog(MAPApplicationContext appCntx, SccpAddress localAddress, SccpAddress remoteAddress,

            Long localId, Long remoteId, AddressString destReference, AddressString origReference) {

        this.appCntx = appCntx;

        this.localAddress = localAddress;

        this.remoteAddress = remoteAddress;

        this.localId = localId;

        this.remoteId = remoteId;


        this.destReference = destReference;

        this.origReference = origReference;

    }


    @Override

    public void abort(MAPUserAbortChoice mapUserAbortChoice) throws MAPException {

        this.mapUserAbortChoice = mapUserAbortChoice;

    }


    @Override

    public void addEricssonData(IMSI arg0, AddressString arg1) {

        // TODO Auto-generated method stub


    }


    @Override

    public boolean cancelInvocation(Long arg0) throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public void close(boolean prearrangedEnd) throws MAPException {

        this.prearrangedEnd = prearrangedEnd;

    }


    @Override

    public void closeDelayed(boolean arg0) throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public MAPApplicationContext getApplicationContext() {

        return this.appCntx;

    }


    @Override

    public SccpAddress getLocalAddress() {

        return this.localAddress;

    }


    @Override

    public Long getLocalDialogId() {

        return this.localId;

    }


    @Override

    public int getMaxUserDataLength() {

        return 0;

    }


    @Override

    public int getMessageUserDataLengthOnClose(boolean arg0) throws MAPException {

        // TODO Auto-generated method stub

        return 0;

    }


    @Override

    public int getMessageUserDataLengthOnSend() throws MAPException {

        // TODO Auto-generated method stub

        return 0;

    }


    @Override

    public AddressString getReceivedDestReference() {

        return this.destReference;

    }


    @Override

    public MAPExtensionContainer getReceivedExtensionContainer() {

        // TODO Auto-generated method stub

        return null;

    }


    @Override

    public AddressString getReceivedOrigReference() {

        return this.origReference;

    }


    @Override

    public SccpAddress getRemoteAddress() {

        return this.remoteAddress;

    }


    @Override

    public Long getRemoteDialogId() {

        return this.remoteId;

    }


    @Override

    public boolean getReturnMessageOnError() {

        return this.returnMessageOnError;

    }


    @Override

    public MAPServiceBase getService() {

        return null;

    }


    @Override

    public MAPDialogState getState() {

        return this.state;

    }


    @Override

    public MessageType getTCAPMessageType() {

        return this.messageType;

    }


    @Override

    public Object getUserObject() {

        return this.userObject;

    }


    @Override

    public void keepAlive() {

        // TODO Auto-generated method stub


    }


    @Override

    public void processInvokeWithoutAnswer(Long invokeId) {

        this.processInvokeWithoutAnswerIds.add(invokeId);

    }


    @Override

    public void refuse(Reason refuseReason) throws MAPException {

        this.refuseReason = refuseReason;

    }


    @Override

    public void release() {

        // TODO Auto-generated method stub


    }


    @Override

    public void resetInvokeTimer(Long arg0) throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public void send() throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public void sendDelayed() throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public void sendErrorComponent(Long invokeId, MAPErrorMessage mapErrorMessage) throws MAPException {

        this.errorComponents.put(invokeId, mapErrorMessage);

    }


    @Override

    public void sendInvokeComponent(Invoke arg0) throws MAPException {

        throw new MAPException(new OperationNotSupportedException());

    }


    @Override

    public void sendRejectComponent(Long arg0, Problem arg1) throws MAPException {

        // TODO Auto-generated method stub


    }


    @Override

    public void sendReturnResultComponent(ReturnResult arg0) throws MAPException {

        // TODO Auto-generated method stub


    }


    @Override

    public void sendReturnResultLastComponent(ReturnResultLast arg0) throws MAPException {

        throw new MAPException(new OperationNotSupportedException());


    }


    @Override

    public void setExtentionContainer(MAPExtensionContainer arg0) {

        // TODO Auto-generated method stub


    }


    @Override

    public void setLocalAddress(SccpAddress origAddress) {

        this.localAddress = origAddress;

    }


    @Override

    public void setRemoteAddress(SccpAddress destAddress) {

        this.remoteAddress = destAddress;

    }


    @Override

    public void setReturnMessageOnError(boolean returnMessageOnError) {

        this.returnMessageOnError = returnMessageOnError;


    }


    @Override

    public void setUserObject(Object obj) {

        this.userObject = obj.toString();

    }


    /**

     * Non MAPDialog methods

     */


    public void addMAPMessage(MAPMessage mapMessage) {

        this.mapMessages.add(mapMessage);

    }


    public boolean removeMAPMessage(MAPMessage mapMessage) {

        return this.mapMessages.remove(mapMessage);

    }


    public FastList<MAPMessage> getMAPMessages() {

        return this.mapMessages;

    }


    public FastList<Long> getProcessInvokeWithoutAnswerIds() {

        return this.processInvokeWithoutAnswerIds;

    }


    public ErrorComponentMap<Long, MAPErrorMessage> getErrorComponents() {

        return errorComponents;

    }


    public MAPUserAbortChoice getMAPUserAbortChoice() {

        return this.mapUserAbortChoice;

    }


    public MAPAbortProviderReason getMapAbortProviderReason() {

        return mapAbortProviderReason;

    }


    public void setMapAbortProviderReason(MAPAbortProviderReason mapAbortProviderReason) {

        this.mapAbortProviderReason = mapAbortProviderReason;

    }


    public MAPRefuseReason getMapRefuseReason() {

        return mapRefuseReason;

    }


    public void setMapRefuseReason(MAPRefuseReason mapRefuseReason) {

        this.mapRefuseReason = mapRefuseReason;

    }


    public Boolean getDialogTimedOut() {

        return dialogTimedOut;

    }


    public void setDialogTimedOut(Boolean dialogTimedOut) {

        this.dialogTimedOut = dialogTimedOut;

    }


    public Boolean getPrearrangedEnd() {

        return this.prearrangedEnd;

    }


    public void setTCAPMessageType(MessageType messageType) {

        this.messageType = messageType;

    }


    public boolean isRedirectRequest() {

        return redirectRequest;

    }


    public void setRedirectRequest(boolean redirectRequest) {

        this.redirectRequest = redirectRequest;

    }


    public void reset() {

        this.mapMessages.clear();

        this.processInvokeWithoutAnswerIds.clear();

        this.errorComponents.clear();

    }


}

 

 

The post 9. XML Parser API appeared first on Telestax Docs Online.

<appender name="STATS" class="org.jboss.logging.appender.DailyRollingFileAppender">
		...... 
		...... 
		...... 
	</appender>

The post 10. Monitoring appeared first on Telestax Docs Online.