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

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

Restcomm USSD Gateway supports TDM hardware offered by major vendors in the market, namely Intel family boards (Dialogic) and Zaptel/Dahdi (Digium, Sangoma). TeleStax also has in-house SS7 cards also known as Restcomm SS7 Cards. Restcomm SS7 cards have MTP2/3 support on-board and therefore the processing load on the server hosting the Restcomm USSD Gateway platform will be low when you use these SS7 cards.

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

The Restcomm USSD Gateway makes use of HTTP protocol between the gateway and the third-party applications (or Value Added Service Modules). Restcomm USSD Gateway receives the USSD request from the subscriber’s handset/device via the GSM Signaling network and then translates these requests to HTTP depending on the rules configured in the Gateway to route to a corresponding Value Added Service (VAS) or third-party application. The HTTP callback mechanism allows the third-party Application to be agnostic to Operating System, Programming Language and Framework.

This guide will assist you in installing Restcomm USSD Gateway. For more details on configuring and using the platform, please refer to the Restcomm USSD Gateway User Guide.

The post USSD Installation Guide appeared first on Telestax Docs Online.

Restcomm jSS7 Stack (Java SS7) is the only Open Source Java based implementation of the SS7 protocol stack. It provides implementation for MTP2, MTP3, ISUP, SCCP, TCAP, CAMEL (Phase I and Phase II) and MAP protocols for a dedicated equipment and also has in-built support for SIGTRAN (M3UA) over IP. Restcomm jSS7 Stack strictly adheres to the standards and specifications defined by the International Telecommunications Union (ITU).

The platform offers developers with a flexible API set that hides the lower layer details (legacy SS7 links or SIGTRAN) and therefore makes it simple and easy to develop SS7 applications as well as to migrate your applications from TDM equipments to M3UA. Restcomm jSS7 Stack is based on an easily scalable and configurable load-balancing architecture.

Restcomm jSS7 Stack supports TDM hardware offered by major vendors in the market, namely Intel family boards (Dialogic) and Zaptel/Dahdi (Digium, Sangoma). Though for production we recommend Dialogic boards with MTP2 and MTP3 on-board only.

If you intend to use only M3UA you can install the jSS7 Stack on any Operating System that supports Java. However if you wish to use SS7 cards, the native libaries for these are only compiled for Linux at the moment.

Restcomm jSS7 Stack comes with JSLEE TCAP, MAP, CAP and ISUP Resource Adaptors (RA) that enable developers to build SS7 applications with ease. Developers only require an understanding of Resource Adaptors and can focus on building applications quickly and efficiently rather than worry about the SS7 stack. If you wish to use JSLEE Resource Adapters, the Command Line Interface (CLI – Shell Management tool) or the GUI for run-time configuration, then you must have JBoss Application Server installed and running. However if you do not wish to use the Resource Adaptors or CLI then Restcomm jSS7 Stack can work as a standalone library.

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

This guide will assist you in installing Restcomm jSS7 Stack. For more details on configuring and using the platform or for information regarding the supported protocols and compliant standards, please refer to the Restcomm jSS7 Stack User Guide.

Restcomm jSS7 Stack’s core requirement is Java. The following table details the Hardware, Operating System and Software requirements for a clean installation of Restcomm jSS7 Stack.

You do not require any specific hardware if you intend to use only SIGTRAN (M3UA). But if you wish to use legacy SS7 links, then you must have relevant SS7 cards installed along with their native libraries.

Restcomm jSS7 Stack supports dahdi based SS7 cards like diguim and sangoma as well as dialogic cards. Since dahdibased SS7 crads do not have MTP2/MTP3 support on board they rely on external software to provide these services. Butdialogic based SS7 cards have on board support for MTP2/MTP3 and recommended.

This guide does not provide installation instructions for SS7 hardware. You must refer to respective vendor documentation for installing and configuring the hardware cards. The following external links point to information that will assist you in setting up the hardware.

[usr]$ git clone https://github.com/mobicents/jss7
[usr]$ cd jss7
[usr]$ git checkout

The post jSS7 Installation Guide appeared first on Telestax Docs Online.

This is a quick user guide for Restcomm – Docker. You will learn how to install and start using Restcomm in a docker container.

 Prerequisites

• Install docker on your sever : https://docs.docker.com/engine/installation/
• Get a free API KEY VoiceRss account as explained  HERE
• Ensure firewall is correctly configured (Selinux can be a problem on some systems)
• SElinux has been known to cause “permission denied” issues on some Linux system, you migtht want to disable or set SELinux to permissive mode. (some basic commands : getenforce, will show the type of permission you currently have )

Supported Tags

• For latest build use tag :  __mobicents/restcomm:latest__
• For version 7.4.0 use tag:  __mobicents/restcomm:7.4.0__
• For version 7.3.1 use tag:  __mobicents/restcomm:7.3.1__
• For version 7.3.0 use tag:  __mobicents/restcomm:7.3.0__

Install and Run Restcomm Docker

• Get your “ETHERNET_IP” by running ifconfig
• Fill out the STATIC_ADDRESS variable as shown below
• Start Restcomm as shown below:
• This will start Restcomm in secure mode (https)

docker run  -i -d --name=restcomm-myInstance -v /var/log/restcomm/:/var/log/restcomm/ -e STATIC_ADDRESS="YOUR_ETHERNET_IP" -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_locally.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

Text-to-Speech with VoiceRSS

• The above command comes with a community version of VoiceRSS key. This version has limited features. You may get a free VoiceRSS API key from http://www.voicerss.org/from
•  See the documentation about adding your own VoiceRSS API Key https://docs.telestax.com/restcomm-docker-advanced-configuration/

Quick test

• Get the Docker IP address by running ifconfig command
• docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500 inet 172.17.42.1

1. Go to https://DOCKER_IP_ADDRESS/olympus
2. Press “Sign in” (username alice or bob and password 1234)
3. Your browser will ask for permission to share microphone and camera, press allow
4. Go to “Contact”, click on the “+1234” and press the “Audio Call” button (phone icon)
5. You should hear the “Welcome to RestComm, a Telestax Sponsored project” announcement
6. You can also make a calll to the “+1235″ to test your Text-to-Speech configuration

Accessing the Admin UI

• Go to https://DOCKER_IP_ADDRESS
• Username = administrator@company.com
• Password = RestCom
• Change the default password

Basic Docker commands

• To Get a list of running containers: sudo docker ps
• To stop container: sudo docker stop RESTCOMM_Container_ID
• To start container: sudo docker start RESTCOMM_Container_ID
• To remove container: sudo docker rm RESTCOMM_Container_ID

To execute a command at the container

• docker exec RESTCOMM_Container_ID [command]
• Example : docker exec RESTCOMM_Container_ID ps -ef | grep java

To get bash console (for debugging only)

You can start the container and get a bash console to manually setup Restcomm and test it using the following command:

docker run --name=restcomm-myInstance --entrypoint=/bin/bash -it -p 80:80 -p 5060:5060 -p 5082:5082 -p 5060:5060/udp -p 65000-65535/udp mobicents/restcomm:latest

Important Notice for RestComm networking

When using a SIP client that is not running on the same local machine as the RestComm docker container, call-setup through SIP/SDP/RTP will fail as the docker container runs on a different network segment. You must set the STATIC_ADDRESS environment variable to address this issue as shown below:

docker run  -i -d --name=restcomm-myInstance -v /var/log/restcomm/:/var/log/restcomm/ -e STATIC_ADDRESS="YOUR_ETHERNET_IP" -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_locally.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

 Known Issue on Firefox when running Restcomm Olympus

It is possible that you will not be able to log in to olympus the first time that you will try to connect using Firefox.
To fix this problem please follow the solution provided by [__Faisal Mq__](http://stackoverflow.com/users/379916/faisal-mq)
on [__http://stackoverflow.com/__](http://stackoverflow.com/questions/11542460/secure-websocket-wss-doesnt-work-on-firefox).

• When you would try to open up wss say using wss://IP:5063, Firefox will keep on giving you error until you open up a separate
  Firefox tab and do try hitting URL [https]://IP:5063 and Confirm Security Exception
  (like you do on Firefox normally for any https based connection). This only happens in Firefox.

The post Restcomm – Docker Quick Start Guide appeared first on Telestax Docs Online.

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>

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

Applications 

An Application instance resource represents a RCML set of instructions used by a RestComm interpreter to process an on-going call, SMS or USSD.

RestComm stores only part of the metadata for this Application, which contains as one of its attributes the URL with the address of the application server where the RCML can be retrieved.

Currently there are 3 types of Applications that are supported: Voice, SMS and USSD. Each type of Application will be used by its specific interpreter.

Considering the access control executed by multi-tenancy, each Application can be created, read, updated or deleted by its owner solely. Any attempt of access to an Application using an account different than its owner will be denied.

Applications Resource URI

2012-04-24/Accounts/{AccountSid}/Applications/{ApplicationSid}

Resource Properties

Supported Operations

HTTP GET

Returns the representation of an Application resource, including the properties described on the table “Resource Properties”.

HTTP POST and PUT  

Modifies an Application resource and returns the representation, including the properties described on the table “Resource Properties”. The table below describes a list of optional parameters.

Request Parameters

You may specify one or more of the following parameters to update this Application’s respective properties:

HTTP DELETE

Remove the Application from RestComm’s database. This Application will not be displayed anymore at the list of available applications while using AdminUI, consequently, not possible to be assigned to a RestComm Number or Client.

If successful, returns an HTTP 204 response with no body.

Applications List Resource URI

2012-04-24/Accounts/{AccountSid}/Applications

Supported Operations

HTTP GET

Returns a list of Applications resource representations, each representing a application given to your account.

List Filters

Given the rules of multi-tenancy, the list of applications is automatically filtered using the informed account to authenticate, returning all the applications owned by this account. No additional filters are currently supported.

HTTP POST

Create a new Application resource with the information provided by the required and optional parameters described by the tables below.

Required Parameters

Your request must include exactly the following parameters:

Optional Parameters

Your request may include the following parameters:

HTTP PUT

Not supported.

HTTP DELETE

Not supported.

Create an Application

curl -X POST http://ACae6e420f425248d6a26948c17a9e2acf:f8b593f84593130c39700c11ee996c0e@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications -d "FriendlyName=Application FooBar" -d "ApiVersion=2012-04-24" -d "HasVoiceCallerIdLookup=false" -d "RcmlUrl=http://127.0.0.1:8080/restcomm-rvd/services/apps/foobar/controller" -d "Kind=voice"

The output of the command will be similar to the one below

<RestcommResponse>
  <Application>
    <Sid>APdc46145309d14e97b62230cd3f269ed4</Sid>
    <DateCreated>Wed, 27 Jan 2016 11:23:54 -0200</DateCreated>
    <DateUpdated>Wed, 27 Jan 2016 11:23:54 -0200</DateUpdated>
    <FriendlyName>Application FooBar</FriendlyName>
    <AccountSid>ACae6e420f425248d6a26948c17a9e2acf</AccountSid>
    <ApiVersion>2012-04-24</ApiVersion>
    <VoiceCallerIdLookup>false</VoiceCallerIdLookup>
    <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/APdc46145309d14e97b62230cd3f269ed4</Uri>
    <RcmlUrl>http://127.0.0.1:8080/restcomm-rvd/services/apps/foobar/controller</RcmlUrl>
    <Kind>voice</Kind>
  </Application>
</RestcommResponse>

Update a Application

curl -X POST http://ACae6e420f425248d6a26948c17a9e2acf:f8b593f84593130c39700c11ee996c0e@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/APdc46145309d14e97b62230cd3f269ed4 -d "FriendlyName=Application X"

The output of the command will be similar to the one below

<RestcommResponse>
  <Application>
    <Sid>APdc46145309d14e97b62230cd3f269ed4</Sid>
    <DateCreated>Wed, 27 Jan 2016 11:23:54 -0200</DateCreated>
    <DateUpdated>Wed, 27 Jan 2016 12:50:18 -0200</DateUpdated>
    <FriendlyName>Application X</FriendlyName>
    <AccountSid>ACae6e420f425248d6a26948c17a9e2acf</AccountSid>
    <ApiVersion>2012-04-24</ApiVersion>
    <VoiceCallerIdLookup>false</VoiceCallerIdLookup>
    <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/APdc46145309d14e97b62230cd3f269ed4</Uri>
    <RcmlUrl>http://127.0.0.1:8080/restcomm-rvd/services/apps/foobar/controller</RcmlUrl>
    <Kind>voice</Kind>
  </Application>
</RestcommResponse>

Delete a Application

curl -X DELETE http://ACae6e420f425248d6a26948c17a9e2acf:f8b593f84593130c39700c11ee996c0e@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/APdc46145309d14e97b62230cd3f269ed4

No output for DELETE operation.

Get a List of available Applications

curl -X GET http://ACae6e420f425248d6a26948c17a9e2acf:f8b593f84593130c39700c11ee996c0e@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications.json

The output of the command will be similar to the one below

[
  {
    "sid": "AP73926e7113fa4d95981aa96b76eca854",
    "date_created": "Wed, 23 Sep 2015 06:56:04 -0300",
    "date_updated": "Wed, 23 Sep 2015 06:56:04 -0300",
    "friendly_name": "rvdCollectVerbDemo",
    "account_sid": "ACae6e420f425248d6a26948c17a9e2acf",
    "api_version": "2012-04-24",
    "voice_caller_id_lookup": false,
    "uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/AP73926e7113fa4d95981aa96b76eca854.json",
    "rcml_url": "/restcomm-rvd/services/apps/PR7addb947898443329cf50913103f77a2/controller",
    "kind": "voice"
  },
  {
    "sid": "AP81cf45088cba4abcac1261385916d582",
    "date_created": "Wed, 23 Sep 2015 06:56:17 -0300",
    "date_updated": "Wed, 23 Sep 2015 06:56:17 -0300",
    "friendly_name": "rvdESDemo",
    "account_sid": "ACae6e420f425248d6a26948c17a9e2acf",
    "api_version": "2012-04-24",
    "voice_caller_id_lookup": false,
    "uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Applications/AP81cf45088cba4abcac1261385916d582.json",
    "rcml_url": "/restcomm-rvd/services/apps/PR2cbed2a2a56947cdbeaa8b0af8a6c02d/controller",
    "kind": "voice"
  }
 ]

The post Restcomm API – Applications appeared first on Telestax Docs Online.

Using the RestComm API, you can send Emails through a simple request.

• Email resource URI. /2012-04-24/Accounts/{AccountSid}/Email/Messages

Resource Properties

HTTP POST. Sends a new Email  message and returns the representation of the Email message resource, including the properties above. Below you will find a list of required and optional parameters.

Request Parameters

For the necessary configuration please refer to this post

curl -X POST http://ACae6e420f425248d6a26948c17a9e2acf:77f8c12cc7b8f8423e5c38b035249166@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Email/Messages -d "To=email@hotmail.com" -d "From=email@gmail.com" -d "Body=This is a test from RestComm" -d "Subject=Test Email"

Example POST Response – XML and JSON

XML POST Response

curl -X POST http://ACae6e420f425248d6a26948c17a9e2acf:77f8c12cc7b8f8423e5c38b035249166@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Email/Messages -d "To=email@hotmail.com" -d "From=email@gmail.com" -d "Body=This is a test from RestComm" -d "Subject=Test Email"
<RestcommResponse>
  <EmailMessage>
    <DateSent>2016-02-07T23:43:03.910Z</DateSent>
    <AccountSid>ACae6e420f425248d6a26948c17a9e2acf</AccountSid>
    <From>email@gmail.com</From>
    <To>email@hotmail.com</To>
    <Body>This is a test from RestComm</Body>
    <Subject>Test Email</Subject>
  </EmailMessage>

JSON POST Response

curl -X POST http://ACae6e420f425248d6a26948c17a9e2acf:77f8c12cc7b8f8423e5c38b035249166@127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Email/Messages.json -d "To=email@hotmail.com" -d "From=email@gmail.com" -d "Body=This is a test from RestComm" -d "Subject=Test Email"

{
  "date_sent": "2016-02-07T23:54:41.293Z",
  "account_sid": "ACae6e420f425248d6a26948c17a9e2acf",
  "from": "email@gmail.com",
  "to": "email@hotmail.com",
  "body": "This is a test from RestComm",
  "subject": "Test Email"
}

The post Restcomm API – Email Messages appeared first on Telestax Docs Online.

Restcomm provides an additional interface to communicate with an RCML/RVD application by means of custom SIP headers. The idea is that all custom SIP headers in a SIP message are detected and converted to HTTP parameters in the request to the RCML application using a convention. The RCML application can consume this parameters. Furthermore, RVD converts these parameters to RVD variables and makes them available to its modules.

Consuming SIP headers from an RCML application

The following conventions are followed:

• Any SIP header starting with X- prefix is custom.
• HTTP parameters are created out of each custom SIP header by adding the SipHeader_ prefix to its name.

Example mappings from SIP header names to HTTP parameter names:

X-My-Header -> SipHeader_X-My-Header

Thus the SipHeader_X-My-Header will be available as typical GET or POST parameter in the RCML application.

Consuming SIP headers from an RVD application

RVD will take the previous convention one step further and create an RVD variable out of the parameter. Thus, the mapping from a custom SIP header to an RVD variable will be the following:

X-My-Header -> $core_x_my_header

So, if X-My-Header SIP header arrives at Restcomm, RVD will have a variable named $core_x_my_header available in its modules.

Note the following:

• All characters are converted to lower case. This happens because although SIP headers are  not case insesitive while RVD variables are.
• All non alpha numeric characters i.e. [^A-Za-z0-9_],  are converted to `_’  (underscore). That happens because RVD has some additional restrictions for naming variables. Here is the regular expression that is used for invalid characters to underscore:

The post Accessing custom SIP headers from an RCML/RVD application appeared first on Telestax Docs Online.

Diagram is a shiny new feature of RVD added in latest Restcomm release (7.5.0). It’s a new, graphical, tree-like view of a project’s call flow where modules are depicted as tree nodes and connections between modules are drawn as arrows. With a single look one can get a pretty good idea of what an application does.

To enable the diagram view, just hit the Diagram button at the project menu bar:

A new section will appear under the menu. Here is the diagram for the sample IVR Clinic application:

Points worth mentioning:

• Nodes are displayed by their labels.
• Links between modules are displayed using arrows. Typical RVD elements that produce links are Collect, and External Service

Arrows – Continue To

In general, wherever RVD contains a ContinueTo field that links to another module an arrow is displayed. Depending on the type of the element, a different piece of information is displayed on the arrow.

• For Collect menu elements descriptions like “Press 1”, “Press 2” etc. are displayed.
• For Collect elements that capture digits in variables the name of the variable is displayed. For example: ‘app_phone’ = <collect>. app_phone is the name of the variable.
• For External Service elements with mapped routing enabled the service response value that leads to a destination module is displayed. For example, for a service returning values ok|error to indicate success or failure, typical arrow descriptions would be “ES Result = ok” or “ES Result = error”.

Diagrams are not updated for any single operation a user makes. Instead a per-save update policy is followed requiring a user to Save in order to see the updated graphical representation of a project.

No support for deprecated dynamic routing

No support is provided for External Services with dynamic routing feature used. Dynamic routing is a deprecated feature that made it impossible for the application to know the possible service outcomes at design time. You can learn more on how to fix projects with dynamic routing so their diagram is properly displayed  here.

Known issues in Chrome

An issue was discovered in Chrome that will prevent proper display of Diagrams. The issue passed under our radars and is already included in the 7.5.0 Restcomm release. We apologize for any inconvenience and working on fixing this ASAP. The fix will be probably included in the regularly updated Docker release of Restcomm first.

Here is the related github issue.

Future plans

Future plans on tightening the integration between the new graphical and the old view of a project are already under way. We’re considering the following:

• Real-time diagram update
• Diagram based navigation (show module by clicking on the diagram)
• Linking between modules using drag & drop operation on the diagrams

Stay tuned!

The post Restcomm RVD – Introducing Diagrams appeared first on Telestax Docs Online.

This tutorial focuses on how to use Telscale Loadbalancer to distribute SIP traffic between two Restcomm Servers. The diagram below shows the network topology.

Requirements

• Basic knowledge of Restcomm

Step 1 – Install and Configure Telscale Load Balancer

The Telscale-loader balancer is package with Restcomm.

• You must copy the load balancer binary from the $RESTCOMM_HOME/tools/sip-balancer to the install directory of your server.
• In this example, the sip-balancer directory has been copied to /opt/telestax/sip-balancer
• You will see the following files in the sip-balancer directory:

ocs  lb-log4j.xml  logs  lb-configuration.properties  
license_pubkey.der  sip-balancer-jar-with-dependencies.jar  telestax-license.xml

open and edit the  file lb-configuration.properties file

• change the host parameter to the IP address of the load balancer server

# The binding address of the load balancer
host=192.168.1.10

• change the externalPort  variables to 5080 .
• Ports 5080 is the default port used by Restcomm

# The SIP port used where client should connect
externalPort=5080

• Leave the rest of the variables as default, save and exit the lb-configuration.properties file
• Start the load balancer (as shown below) whilst you are in the directory /opt/telestax/sip-balancer

java -Dtelscale.license.dir=./license -Dtelscale.license.key.location=./license -DlogConfigFile=./lb-log4j.xml -jar ./sip-balancer-jar-with-dependencies.jar -mobicents-balancer-config=lb-configuration.properties

• If the server is successfully started, you will see an output similar to the one below:

********truncated************
tStore=null javax.net.ssl.trustStorePassword=null
2016-02-25 01:05:23,104 INFO main - the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
2016-02-25 01:05:23,334 INFO main - Sip Balancer started on external address 192.168.1, external port : 5080, internalPort : 5085
2016-02-25 01:05:23,436 INFO main - HTTP LB listening on port 2080
2016-02-25 01:05:24,285 INFO RMI TCP Connection(4)-192.168.1.10 - Balancer algorithm org.mobicents.tools.sip.balancer.CallIDAffinityBalancerAlgorithm loaded succesfully for cluster version = 0

Step 2 – Configure Restcomm Servers to Point to the Load Balancer

Restcomm Server 1

• Open and edit the file  $RESTCOMM_HOME/bin/restcomm/proxy.conf as shown below

# Proxy variable declarations
ACTIVE_PROXY='true'                     # values: TRUE or FALSE
TP_LOGIN=''                         # Username
TP_PASSWORD=''                      # Password
INSTANCE_ID=''                      # EC2 Instance id (will be used as endpoint - VI or accountId - BW)
SITE_ID=''                          # Only for BW integration
PROXY_IP='192.168.1.10'                         # Public IP Address of the Telestax Proxy
PROXY_PRIVATE_IP='192.168.1.10'    # Private IP Address of the Telestax Proxy

• Open and edit the file  $RESTCOMM_HOME/bin/restcomm/restcomm.conf as shown below

# Network configuration
NET_INTERFACE='eth1'
PRIVATE_IP='192.168.1.11'
SUBNET_MASK='255.255.255.0'
NETWORK='192.168.1.0'
BROADCAST_ADDRESS='192.168.1.255'
# PUBLIC IP ADDRESS
STATIC_ADDRESS=''

• Start Restcomm and you will see the following in the startup console

02:38:52,455 INFO  [org.mobicents.ha.javax.sip.LoadBalancerHeartBeatingServiceImpl] (Timer-2) Keepalive: SIP Load Balancer Found! /192.168.1.11:5065:2080:2000

• In the load balancer console, you will see the output below.

2016-02-25 01:05:24,287 INFO RMI TCP Connection(4)- 192.168.1.11 - NodeExpirationTimerTask Run NSync[SIPNode hostname[telscalerestcomcore01] ip[192.168.1.11] httpPort[8080] sslPort[8443] wsPort[5082] tcpPort[5080] udpPort[5080] version[0] ] added

Restcomm Server 2

• Repeat Step 2 for Restcomm Server 2 using the IP address 192.168.1.12

Step 3 – Making a Call to the Load Balancer from Restcomm

Make a call to the SIP IP address of the load balancer sip:1234@192.168.1.10:5080

The load balancer will distribute the call evenly between the two Restcomm servers. The first call will go to 192.168.1.11 and the next call will go to 192.168.1.12.

The post Restcomm – Configuring Load-balancer appeared first on Telestax Docs Online.

When working with the binary version of Restcomm, the default database is hsqlDB. This is of course not suitable for production but it is provided as a way for you to conveniently and quickly start up Restcomm.  For those who wish to run Restcomm on a local server or on another cloud based system, the following tutorial will show you how to get started with Restcomm and Mysql.

Requirements

• Install Mysql
• Download the latest version of Restcomm Telscale as explained HERE

Step 1 – Adding the Mysql JDBC connector to JBoss Datasource

• Edit $RESTCOMM_HOME/standalone/configuration/standalone-sip.xml file
• Under the datasource tag add the following:
• Make sure you are using the correct IP address and port default port 3306. In the example below the local IP is 192.168.1.3:3306
• Use the correct username and password for the Mysql access
• Set the Mysql enabled=”true” and make sure you set the default dummy datasource to “false”

<datasource jndi-name="java:/MysqlDS" pool-name="MysqlDS" enabled="true">
                    <connection-url>jdbc:mysql://192.168.1.3:3306/restcomm</connection-url>
                    <driver>mysqlDriver</driver>
                    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
                    <pool>
                        <min-pool-size>100</min-pool-size>
                        <max-pool-size>200</max-pool-size>
                    </pool>
                    <security>
                        <user-name>root</user-name>
                        <password>myPWD</password>
                    </security>
                    <statement>
                        <prepared-statement-cache-size>100</prepared-statement-cache-size>
                        <share-prepared-statements/>
                    </statement>
                </datasource>

• In the datasource under the drivers tag, add the following:
• save and exit the standalone-sip.xml file

                    <driver name="mariadb" module="org.mariadb.jdbc">
                        <xa-datasource-class>org.mariadb.jdbc.MySQLDataSource</xa-datasource-class>
                    </driver>

Step 2 – Configuring the mybatis.xml file to use Mysql

• Edit the file $RESTCOMM_HOME/standalone/deployments/restcomm.war/WEB-INF/conf/mybatis.xml
• Change the environments id to id=”mariadb”
• Add the MariaDB configuration environment tag as shown below

<environment id="mysql">
                <transactionManager type="JDBC" />
                <dataSource type="JNDI">
                  <property name="data_source" value="java:/MysqlDS" />
                </dataSource>
        </environment>

• Save and exist the mybatis.xml file

Step 3 – Download Mysql Java Client Driver

• Download the latest mysql java connector client driver jar file from HERE.
• Go to the directory $RESTCOMM_HOME/modules
• Run the following command to create a new directory structure:  mkdir -p ./org/mysql/jdbc/main
• Go to the newly created directory structure $RESTCOMM_HOME/modules/org/mysql/jdbc/main
• Copy the downloaded mysql-connector-java-5.1.38-bin.jar to the $RESTCOMM_HOME/modules/org/mysql/jdbc/main
• In the $RESTCOMM_HOME/modules/org/mysql/jdbc/main create a new xml file called module.xml
• The content of the module.xml should be similar to the one below. Notice the path name of the java client must matches the one you download
• You should now have 2 files in the $RESTCOMM_HOME/modules/org/mysql/jdbc/main directory.

<?xml version="1.0" encoding="UTF-8" ?>
<module xmlns="urn:jboss:module:1.1" name="org.mysql.jdbc">
    <resources>
        <resource-root path="mysql-connector-java-5.1.38-bin.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

Step 4 – Start Mysql and Create the restcomm Database.

•  Start mysql service if it is not already started  – sudo /etc/init.d/mysql start
• Go to the directory $RESTCOMM_HOME/standalone/deployments/restcomm.war/WEB-INF/scripts/mariadb
• (Note the scripts/mariadb contains the same files needed by mysql)
• There will be an init.sql file and an sql directory
• Create the restcomm database from the init.sql as follows:
• mysql -u root -p < init.sql
• log into mysql and make sure the restcomm database is created :  show databases;

Step 5 – Edit the restcomm.xml file to point the DAO to mysql

• Edit the file $RESTCOMM_HOME/standalone/deployments/restcomm.war/WEB-INF/conf/restcomm.xml
• Find the dao-manager tag and change the sql-files path to mariadb as shown below
• (Note the scripts/mariadb  contains the same files needed by mysql)

<dao-manager class="org.mobicents.servlet.restcomm.dao.mybatis.MybatisDaoManager">
		<configuration-file>${restcomm:home}/WEB-INF/conf/mybatis.xml
		</configuration-file>
		<data-files>${restcomm:home}/WEB-INF/data/hsql</data-files>
		<sql-files>${restcomm:home}/WEB-INF/scripts/mariadb/sql</sql-files>
	</dao-manager>

Start Restcomm as explained in the quick user guide HERE

The post Restcomm – Install and Configure Restcomm to use Mysql appeared first on Telestax Docs Online.

This tutorial will show you how to configure two Restcomm instances to use the same Mysql Server instance.

Requirements

• Install Mysql
• Download the latest version of Restcomm Telscale as explained HERE

Step 1 – Configure Restcomm Server 1 to use Mysql Database

Configure the first Restcomm Server1 to use Mysql as explained in the documentation HERE

• On Restcomm server1 with IP (192.168.1.11) grant access to the Mysql Server so that Restcomm Server2 (192.168.1.12) will be able to access the restcomm.
• On Restcomm server1 access the mysql server;
• mysql -u root -p
• enter the root password
• make sure restcomm database is created :  show databases;
• grant access to servers from the same subnet as shown below
• ALTER USER PRIVILEGES ON *.* TO ‘root’@’192.168.1.%’ IDENTIFIED BY ‘rootUserPWD’ WITH GRANT OPTION;

Step 2 – Configure Restcomm Server2 to use Mysql Database running on 192.168.1.11

Configure Restcomm Server2 as explained in the documentation HERE:

• In step 1 of the documentation above, you have to edit $RESTCOMM_HOME/standalone/configuration/standalone-sip.xml
• change the IP address to point to the Mysql instanced running on Restcomm Server1 as follows: <connection-url>jdbc:mysql://192.168.1.11:3306/restcomm</connection-url>
• See full snapshot below:
• Complete steps 2 – 5 as explained in the documentation Install and configure Restcomm to use Mysql

<datasource jndi-name="java:/MysqlDS" pool-name="MysqlDS" enabled="true">
                    <connection-url>jdbc:mysql://192.168.1.11:3306/restcomm</connection-url>
                    <driver>mysqlDriver</driver>
                    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
                    <pool>
                        <min-pool-size>100</min-pool-size>
                        <max-pool-size>200</max-pool-size>
                    </pool>
                    <security>
                        <user-name>root</user-name>
                        <password>myPWD</password>
                    </security>
                    <statement>
                        <prepared-statement-cache-size>100</prepared-statement-cache-size>
                        <share-prepared-statements/>
                    </statement>
                </datasource>

• Once you have completed the 2 steps above, Restcomm Server1 and Server2 will  use the same Mysql database running on 192.168.1.11

The post Restcomm – Using a Single Mysql Database for 2 Restcomm Servers appeared first on Telestax Docs Online.

It is possible to run Restcomm in a cluster mode where two Restcomm instances can use the same Mysql server as explained HERE. In this tutorial, you will learn how to configure two Restcomm instances to share the same workspace. This means, any application created with Restcomm Visual Designer on any Restcomm server will be available and visible on both Servers. In order to be able to call these applications, you will need to point Restcomm to the same database (as explained HERE) and the same RVD workspace.

Requirements

• Install NFS on your Linux Server
• Basic Knowledge of Restcomm
• This tutorial use a Redhat Linux Server

Step 1 – Make sure NFS is started and export Server1 RVD Workspace

• On Restcomm server1, create a new directory /opt/telestax/restcomm-shared-workspace
• Edit the /etc/exports file and add the line below:

/opt/telestax/restcomm-shared-workspace   192.168.1.12(rw,sync,no_root_squash,no_subtree_check)

• The above will share the restcomm-shared-space directory and give read-write access to any NFS client from server (Restcomm Server2) 192.168.1.12
• Save the changes above and run the command below for changes to take effect.
• sudo service nfs reload
• Log into the (Restcomm server2) 192.168.1.12 and make sure the NFS exported directory is visible. Run the command below.
• showmount -e 192.168.1.11
• You will see an output like the one below
• Export list for 192.168.1.11: – /opt/telestax/restcomm-shared-workspace 192.168.1.12

Step 2 – Mount the Shared directory on Restcomm server2

• On Restcomm Server2, create a new directory /opt/telestax/restcomm-mount-shared-workspace
• mkdir -p /opt/telestax/restcomm-mount-shared-workspace
• mount the shared directory on Server1 to the new directory you created above
• mount -t nfs 192.168.1.11:/opt/telestax/restcomm-shared-workspace  /opt/telestax/restcomm-mount-shared-workspace
• create a test file in the /opt/telestax/restcomm-mount-shared-workspace
• touch testfile.txt
• This file will also be visible in the opt/telestax/restcomm-shared-workspace of Restcomm Server1
• Make sure the NFS share directory will automount on server restart. Add the line below to the /etc/fstab file

192.168.1.11:/opt/telestax/restcomm-shared-workspace  /opt/telestax/restcomm-mount-shared-workspace nfs defaults 0 0

Step 3 – Change the default RVD workspace on Restcomm Server1 to use the NFS directory

• Rename default RVD workspace to workspace-old as shown below
• mv $RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace   $RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace-old
• Create a new symbolic link directory that points to the NFS shared directory(replacing the default workspace directory)
• sudo ln -s /opt/telestax/restcomm-shared-workspace   /opt/telestax/$RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace
• Copy the content of the directory workspace-old to workspace.(This content will be visible to both servers)

Step 4 – Change the default RVD workspace on Restcomm Server2 to use the NFS directory

• Rename default RVD workspace to workspace-old as shown below
• mv $RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace   $RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace-old
• Create a new symbolic link directory that points to the NFS mount shared directory(replacing the default workspace directory)
• sudo ln -s /opt/telestax/restcomm-mount-shared-workspace   /opt/telestax/$RESTCOMM_HOME/standalone/deployments/restcomm-rvd.war/workspace
• Note the difference above that the directory is the restcomm-mount-shared-workspace.

The post Restcomm – Single RVD Workspace for two Restcomm Instances appeared first on Telestax Docs Online.

Given the new Applications REST API available since the previous RestComm release (7.4.0), some modifications were done to better integrate RVD Projects with Application entities. So the native application server RVD will continue providing the RCML requested by RestComm’s interpreters, but now using the Application entities.

The list below contains a description of the main modifications:

1. RVD Workspace Migration: RestComm bootstrap updates RVD workspace naming convention, Applications, IncomingPhoneNumbers and Clients;
2. Integration of Applications with other entities: AdminUI allows to set both Applications or URLs to RestComm Numbers or Clients;
3. User Interface and internal modifications: AdminUI and RVD UI obtain now the list of available applications using Applications REST API.

The following parts of this document are organised by following the 3 items mentioned above.

1. RVD Workspace Migration

The migration executed on RestComm’s bootstrap is a sequence of steps executed to adapt the filesystem and database with the new structure.

The steps executed by the migration algorithm are:

1. Backup RVD Workspace directory; (IMPORTANT: To backup database structures execute this script.)
2. Synchronize RVD Project with Applications API (create the Application or update the existing one);
3. Rename the directory of the project inside RVD Workspace using the application SID obtained from step 2;
4. Update IncomingPhoneNumbers replacing the voice, SMS and USSD URLs that points to the application by its respective application SID;
5. Update Clients replacing the voice URL that points to the application by its respective application SID;
6. If the current project is the last one, store the result of the migration and continue with RestComm bootstrap, otherwise, get next RVD project and go to step 2.

1.1 Configuration

The configuration required to run the migration algorithm on RestComm’s bootstrap is placed inside $RESTCOMM_HOME/standalone/deploy/restcomm.war/WEB-INF/conf/restcomm.xml. The parameters to be configured inside this file are “rvd-workspace-migration-enabled” and “default-email-address“, as described below:

1.2 Execution

The default value of the parameter “rvd-workspace-migration-enabled” is “true” for the release that introduced this feature, and should be “false” for the next ones.

After the execution of the migration, a file named “.version” will be created inside RVD’s workspace directory storing the result of the migration and the version of RestComm that managed its execution. The following box represent the content of this file:

{"status":true,"version":"7.6.0"}

Once this file is present inside RVD’s workspace and holds the current version of RestComm, the migration will not be executed in the next bootstrap of this version, even if the parameter “rvd-workspace-migration-enabled” still configured with the value “true“. This strategy was created to allow only one automatic attempt of migration per RestComm version.

If the migration failed and it’s necessary to run another attempt, make sure to remove the file “.version” from RVD workspace and keep the value of the parameter “rvd-workspace-migration-enabled” as “true“, and then restart RestComm. For more information see the Troubleshooting at session 1.4 of this document.

1.3 Logs

During the execution of the process, RestComm will use 4 different resources to store the progress of the migration: specific log file, generic log file, RestComm Notifications and e-mail messages.

The following table shows detailed information about each log resource.

1.4 Troubleshooting

While the migration is executed, some errors can be easily predicted/handled, but another ones require manual intervention due to the diversity of operations executed by the algorithm.

Given that, it’s important to emphasise that the migration needs to be executed with success, indifferent of the number of attempts. This process is required for several new features implemented across the platform.

To help with manual troubleshooting of possible issues, a set of error codes was created describing each situation with is consequences and how to work around it. If some error occur, it can just skip the project that raised the problem or abort the migration, always storing details inside the log files.

The following table have details about troubleshooting to each error code, also guiding which situation is recommended to execute the algorithm again.

Based on the table above, if a new attempt of execution is recommended, follow the steps below:

1. Stop RestComm;
2. Make sure the parameter “rvd-workspace-migration-enabled” remains with the value “true” inside the configuration file “restcomm.xml“;
3. Remove the file “.version” inside RVD workspace directory;
4. Double check the recommendations provided by the column “Comments” in the previous table;
5. Start RestComm.

To get more information about the configuration and execution of the algorithm, please make sure to read sections 1.1 and 1.2 of this document.

Important: In a new attempt of execution, the projects that were successfully migrated will be skipped to keep it consistent.

If a manual intervention is required with the database, check REST API documentation for Applications, IncomingPhoneNumbers and Clients.

2. Integration of Applications with other entities

With the consistency provided by the efforts to improve the way we use Application entities, AdminUI was adapted to manage IncomingPhoneNumbers and Clients configuration with both URL or Applications in a more elegant way.
By selecting the option URL in the first dropdown menu, the text field in the right will allow to inform an external provider for the RCML and also the HTTP method to be used.

If the option Application is selected, use the button in the right side to browse Applications inside RectComm database and assign them to this IncomingPhoneNumber/Client.

3. User Interface internal modifications

Some minor and abstract changes were made to better fit the list of Applications inside AdminUI and RVD UI.

Before the modification, RVD was the provider of the list of available Projects to AdminUI and RVD UI, but now both UIs are using Applications REST API to get the complete list of applications from RestComm.

This modification allows us to use a RestComm Applications created using a application server different than RVD in a transparent way to the final user, bringing more flexibility to RestComm.

The post RVD Workspace Upgrade appeared first on Telestax Docs Online.

This is a quick user guide for Restcomm – Docker. You will learn how to install and start using Restcomm in a docker container.

 Prerequisites

• System requirements: There are not any particular minimum requirements to properly run RestComm. Mostly depends on the use-case scenario and needs in resources. For a local development environment (not production) a medium station (i3,4Gb) should be enough (known issue).
• Install docker on your sever : https://docs.docker.com/engine/installation/
• Get a free API KEY VoiceRss account as explained  HERE
• Ensure firewall is correctly configured (SELinux can be a problem on some systems)
• SELinux has been known to cause “permission denied” issues on some Linux system, you might want to disable or set SELinux to permissive mode. (some basic commands : getenforce, will show the type of permission you currently have )

Supported Tags

• Tag “latest”. Points to the latest binary from the Continuous Delivery server. Uses the master development branch : restcomm/restcomm:latest.
  *We don’t advice to use “latest” tag for production as it is constantly changing, and as well new features and fixes may not be documented.
• Tag “stable”. Points to the latest/current GA release (current: 7.6.0.GA) use tag :  restcomm/restcomm:stable
• Tags “7.6.0” or “7.5.0” etc, are pointing to a specific GA release. For example:  restcomm/restcomm:7.6.0
  restcomm/restcomm:7.5.0
  etc.

To pull the “latest” image from the RestComm docker hub repository please use:

docker pull restcomm/restcomm:latest

Install and Run Restcomm Docker

• Get your “ETHERNET_IP” by running ifconfig
• Fill out the STATIC_ADDRESS variable as shown below
• Start Restcomm as shown below:
• This will start Restcomm in secure mode (https)

docker run  -i -d --name=restcomm-myInstance -v /var/log/restcomm/:/var/log/restcomm/ -e STATIC_ADDRESS="YOUR_ETHERNET_IP" -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_locally.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-65050:65000-65050/udp restcomm/restcomm:latest

Text-to-Speech with VoiceRSS

• The above command comes with a community version of VoiceRSS key. This version has limited features. You may get a free VoiceRSS API key from http://www.voicerss.org/from
•  See the documentation about adding your own VoiceRSS API Key https://docs.telestax.com/restcomm-docker-advanced-configuration/

Quick test

• Get the Docker IP address by running ifconfig command
• docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500 inet 172.17.42.1

1. Go to https://DOCKER_IP_ADDRESS/olympus
2. Press “Sign in” (username alice or bob and password 1234)
3. Your browser will ask for permission to share microphone and camera, press allow
4. Go to “Contact”, click on the “+1234” and press the “Audio Call” button (phone icon)
5. You should hear the “Welcome to RestComm, a Telestax Sponsored project” announcement
6. You can also make a calll to the “+1235″ to test your Text-to-Speech configuration

Accessing the Admin UI

• Go to https://DOCKER_IP_ADDRESS
• Username = administrator@company.com
• Password = RestComm
• Change the default password

Basic Docker commands

• To Get a list of running containers: sudo docker ps
• To stop container: sudo docker stop RESTCOMM_Container_ID
• To start container: sudo docker start RESTCOMM_Container_ID
• To remove container: sudo docker rm RESTCOMM_Container_ID

To execute a command at the container

• docker exec RESTCOMM_Container_ID [command]
• Example : docker exec RESTCOMM_Container_ID ps -ef | grep java

To get bash console (for debugging only)

You can start the container and get a bash console to manually setup Restcomm and test it using the following command:

docker run --name=restcomm-myInstance --entrypoint=/bin/bash -it -p 80:80 -p 5060:5060 -p 5082:5082 -p 5060:5060/udp -p 65000-65050:65000-65050/udp restcomm/restcomm:latest

 Excessive demand on memory when exposing a big range of ports

Due to a known issue on Docker, exposing a big range of ports produce a big need in RAM. On RestComm the issue arises when a big range of RTP ports is exposed. For a system with 4Gb of RAM a range of 50 ports is a good approach (e.g -p 65000-65050:65000-65050/udp).
*We are expecting that this issue will be solved soon from Docker team.

IMPORTANT
As a workaround and if a bigger range of port please use host mode for docker RUN command: “docker run –– net host…”
More information HERE

docker run  --net  host -i -d --name=restcomm-myInstance -v /var/log/restcomm/:/var/log/restcomm/ -e STATIC_ADDRESS="YOUR_ETHERNET_IP" -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_locally.sh" restcomm/restcomm:latest

Important Notice for RestComm networking

When using a SIP client that is not running on the same local machine as the RestComm docker container, call-setup through SIP/SDP/RTP will fail as the docker container runs on a different network segment. You must set the STATIC_ADDRESS environment variable to address this issue as shown below:

docker run  -i -d --name=restcomm-myInstance -v /var/log/restcomm/:/var/log/restcomm/ -e STATIC_ADDRESS="YOUR_ETHERNET_IP" -e ENVCONFURL="https://raw.githubusercontent.com/RestComm/Restcomm-Docker/master/scripts/restcomm_env_locally.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-65050:65000-65050/udp restcomm/restcomm:latest

 Known Issue on Firefox when running RestComm Olympus

It is possible that you will not be able to log in to olympus the first time that you will try to connect using Firefox.
To fix this problem please follow the solution provided by Faisal Mq (stackoverflow).

• When you would try to open up wss say using wss://IP:5063, Firefox will keep on giving you error until you open up a separate Firefox tab and do try hitting URL [https]://IP:5063 and Confirm Security Exception (like you do on Firefox normally for any https based connection). This only happens in Firefox.

The post Restcomm – Docker Quick Start Guide appeared first on Telestax Docs Online.