RestComm Multi-tenancy

In our continuous effort to improve Restcomm functionalities, we have introduced multi-tenancy as part of Restcomm 7.4.0 and Restcomm as a Service (RaaS).  Multi tenancy support provides a set of rules that improve user information management and control who can gain access to specific accounts. This set of rules will be also applied by the upcoming OAuth support, so they both OAuth and Multi-tenancy Support will handle this consistency together. The information below will provide an overview of how multi-tenancy is applied to Restcomm.

Restcomm REST API

Restcomm REST API access control is managed by two main entities, credentials and accounts. To better understand how it works, we’ll assume the following diagram as the account hierarchy, where each account and sub account has its own information.



Considering that Primary and Secondary accounts represents different Restcomm users, they will not be able to manage information from each other. So if Primary Account tries to access the REST API using its own credentials but requesting for the list of DIDs of the Secondary Account, the response will be a HTTP 401 error. The ‘curl’ command below represents the given situation.


As mentioned above, there are more possible combinations between credentials and accounts used to request information through the API. But instead list all those possibilities, we can assume the pattern used by the API to control access in a general way, grouped by the result obtained from the API:


  • Request information about the same account used as credential
  • Request information about a sub account of the account used as credential


  • Request information about the parent account of the account used as credential
  • Request information about a account of the same level of the account used as credential
  • Request information about a sub account different than the ones from the account used as credential

This access control is applied to the API’s: Accounts, IncomingPhoneNumbers, Calls, SMS Messages, OutgoingCallerIds, Recordings, Transcriptions and Notifications.

To understand this rules based on the hierarchy presented by the diagram above, we can assume the following for each account:

Primary Account can view and manage Primary Application, DID P, DID A and DID B only.
Subaccount A can view and manage Application A and DID A only.
Subaccount B can view and manage Application B and DID B only.
Secondary Account can view and manage Application S, DID S, DID C and DID D only.
Subaccount C can view and manage Application C and DID C only.
Subaccount D can view and manage Application D and DID D only.

Important!: The Applications API has a different access control, and allows the accounts to manage its own applications only. So, if a request is made to this API using a credential different than the account, the response will be a HTTP 401 error.

Restcomm Admin UI

The user interface follows a similar behaviour to the API. Is known that the AdminUI currently shows only info related to the logged user, but now the local applications displayed under the ‘Restcomm Apps’ option were adjusted to follow the same behaviour. This filter is also applied to the available applications when configuring a DID, as shown by the images below.

Screen Shot 2015-10-05 at 16.40.46

Available applications at DID’s configuration, filtered by logged user.


Screen Shot 2015-10-05 at 16.35.37

Restcomm Apps list, filtered by logged user.


Screen Shot 2015-10-05 at 16.34.53

RVD Projects created by the user.

This is the way that multi tenancy support provides access control between accounts, ensuring that only authorized accounts will be able to see and manage another accounts info.


Telscale Restcomm 7.4.0.GA released

We are happy to announce the release of Telscale Restcomm 7.4.0.GA.

Some of the most notable changes and new features are:

  • Multi-tenancy, create accounts and sub-accounts but with mutli-tenancy their resources, applications, numbers etc, are now isolated
  • Email Tag. You can use the Email tag to send email directly from your RCML application
  • Improvements for the support of secure HTTPS using self-sign or ca certificates
  • Monitoring Service that will provide you metrics for live call, sms and ussd sessions, registered users, completed, failed, no answer calls and more. Please check our blog post on Enterprise Monitoring for RestComm related to that
  • Integration with Dialogic XMS media server

If you would like to see the full changelog for this release please check the link here:

Latest documentation for Restcomm API, RCML, turorials, configuration how-to can be found online at :

Telscale Restcomm customers, please check

For Mobicents Restcomm, please check the github release page:

Mobicents Restcomm docker image has been updated for this release and you can use the “7.4.0” tag to pull the Restcomm 7.4.0.GA docker image. For more information visit

Last, your feedback is highly appreciated. If you discover a bug or you have suggestions for a new feature or anything, we would like to hear from you. Please report Restcomm bugs and new features at or use the public forum!forum/restcomm

You can even be part of the Open Source GitHub RestComm project by contributing patches, documentation or tests, check the RestComm Roadmap.

Visit for more news, tutorials and documentation and stay tuned for more, just make sure you subscribe to Telestax newsletter and follow us on Twitter so you miss nothing.


Enterprise Monitoring for Restcomm – Part 3

In this post, the third in the series of posts in that subject (see previous posts and, I will show how to get the best picture of your application.

The metrics available will provide you insights for your application’s performance and efficiency and help you plan for high availability and disaster recovery.

Currently you will be able to get metrics from the following:

  • Jain Sip Stack for low level metrics such as ServerTransactions, ClientTransactions, Dialogs etc
  • Sip Servlet container metrics for metrics such as number of SIP responses for each response class, number of SIP messages etc
  • Restcomm application for high level metrics such as number of live call sessions, sms sessions etc

Here is a screenshot of the dashboard you will get


You will see how to use these metrics to create useful dashboards using Graylog –

Graylog is an open source analytics platform that combines the best of the breed software and puts them together.

You have several options for how to install Graylog, for example OS packages for your Linux distribution of choice, chef and puppet scripts, virtual appliances as OVA images for virtualbox, vmware and docker. For more details you can check here

I won’t cover the Graylog installation here, but as a piece of advice, the Docker or Virtualbox image is the easiest way to go as a beginner.

Additionally you will need to install the Http Monitor Input Graylog plugin from here:

The Graylog version that I used for this tutorial is 1.2.2. You can check here for the Graylog documentation

Bellow you will find the list of metrics that are available:

  1. SIP Responses sent or received, for example 1xx-processed, 2xx-sent, 5xx-processed etc
  2. SIP Methods sent or receieved, for example bye-processed, invite-sent, ack-sent etc
  3. Active Sip Application Sessions and Sip Sessions
  4. Expired Sip Application Sessions and Sip Sessions
  5. Rejected Sip Application Sessions and Sip Sessions
  6. Sip Application Sessions and Sip Sessions per second
  7. Sip Application Session and Sip Session average alive time
  8. Sip Application Session and Sip Session maximum alive time
  9. Restcomm total calls since startup
  10. Restcomm total incoming calls since startup
  11. Restcomm total outgoing calls since startup
  12. Restcomm number of registered users
  13. Restcomm number of live calls
  14. Restcomm number of incoming live calls
  15. Restcomm number of outgoing live calls
  16. Restcomm number of Completed calls
  17. Restcomm number of NoAnswered calls
  18. Restcomm number of Busy calls
  19. Restcomm number of Failed calls
  20. Restcomm number of NotFound calls
  21. Restcomm number of Canceled calls
  22. Restcomm number of incoming SMS routed to clients
  23. Restcomm number of incoming SMS routed to applications
  24. Restcomm number of outgoing SMS
  25. JVM Metrics such as memory and threads in use

Jain sip stack and Sip Servlets provide JMX for the monitoring metrics but using the JBoss AS7 Http Management interface we can access these metrics over http in a nice json response.

There are two steps that needs to be done to enable the Jain sip stack and Sip Servlets metrics:

  • Add a JBoss management user. You can do this using the “” script which is located at $SIP_SERVLETS_HOME/bin (or $RESTCOMM_HOME/bin). For example you can create new user: adminUser adminPassword123$
    Username will be “adminUser” and password “adminPassword”
  • Edit the standalone-sip.xml file located at $SIP_SERVLETS_HOME/standalone/configuration/standalone-sip.xml ($RESTCOMM_HOME/standalone/configuration/standalone-sip.xml) and edit JBoss Management interface ip address:
    <interface name=”management”>
    <inet-address value=”${}”/>
    This IP Address must be reachable from the Graylog server.

Now the Restcomm metrics are provided from the brand new Monitoring Service which is part of the REST API and you need no additional configuration. You will need a Restcomm management user that is able to read the monitoring service metrics. Here I will use the default administrator user, “”.

Make sure you have successfully reset the administrators password the first time by login to the Restcomm Admin UI (http://RESTCOMM_IP_ADDRESS:8080) .

For easier setup I have provided Graylog content packs for the Inputs and Dashboard, that you can import and have everything set out of the box. You will only need to edit each Input to change the SipServlets (Restcomm) IP Address and username/password.

You can find the Graylog content packs here:

To import the content packs, login to Graylog and go to System -> Content packs -> Import Content pack, then upload the relevant file. After you upload both files, you will have the content packs ready to be applied, so click one content pack and press Apply

Import And Apply Content Pack

Next step is to edit the imported Graylog inputs in order to provide the proper IP Address of Sip Servlets server, or Restcomm, and username/password to be used. Go to System -> Inputs and edit one by one the three imported inputs. Additionally you can change the interval between requests for each of the inputs.

Edit Input 1/2

Edit Input 2/2

Now you can check the Dashboard that will be available after you imported the Restcomm Dashboard content pack.


Last, the imported input content packs will provide you a lot of other metrics that you can add to the existing dashboard or create a new one.

There are still more to come on the enterprise monitoring topic so stay tune. Subscribe to receive our newsletter, follow us on Twitter and Facebook.

You can use the Restcomm public forum –!forum/restcomm – to send any suggestion, feature request or questions.


New Telscale jDiameter-6.2.1.GA Release Is Now Available

We are pleased to announce the latest iteration of Telscale jDiameter-6.2.1.GA release. This version is derived from the Mobicents Diameter Community version, with emphasis on stability, reliability and commercial grade support for real-world carrier grade deployments.

Release Notes:

  •  Update to latest SCTP library version (1.6.0.FINAL)
  •  Fixes and Enhancements in SCTP transport
  •  Fix to an issue where peer table could grow indefinitely, trying to reconnect to a peer

Existing Telestax customer can download the release HERE

Contact us for Diameter stack and products with CommercialGrade Support

Agenda for RestConn 2015

Check out the agenda for the most exclusive VIP event for RestComm Rock Stars.

It will take place in Lisbon on 19-22 November. Right after TADSummit (17-18 November) which is the most important RTC app development event of the year. Telestax is a founding member and a proud sponsor of TADSummit.

Get ready for RestConn! Don’t miss the chance to meet the Telestax’ team and the top open source RTC contributors in the world.

Fill out this form to register for RestConn 2015. Block the dates and book your flights. Ask your closest TeleStax friend for a pass. Invitation only.


Restcomm Client iOS SDK Beta 3 is out!

We are proud to announce the third Beta release of Restcomm Client iOS SDK, packed with brand new features.

RestComm Client for iOS allows you to leverage the telecommunication features of RestComm. It offers a simple yet efficient Objective-C API that you can use to add rich communications capabilities to your iOS Apps.

Features for this release:

  • Added support for custom SIP headers. You can now send custom SIP headers when using [RCDevice connect] and [RCDevice sendMessage] APIs to make calls and send text messages.
  • Added support for DTMF tones. You can now send DTMF digits using the [RCConnection sendDigits] API
  • Introduced reachability facilities so that both wifi as well as cellular networks can be utilized for data transport and Client SDK signalling/media facilities can handle connectivity changes gracefully. Also, Client library now notifies application of any connectivity change events it might need to consume.
  • Added support for registrar-less calls
  • Added support for Video mute (i.e. RCConnection.muteVideo)
  • Reworked logging facilities from the ground up. Introduced Twilio compatible API to configure them (through RestCommClient singleton)
  • Fixed some issues in the DNS resolver; domain names can now be used throughout the Client APIs
  • Introduced brand new Messenger sample application with new UI and improved capabilities. Here are some screenshots to get an idea:beta3-screenshots
  • Simplified media/signalling interaction during call setup. This helped to address various crashes
  • Improved Client library error reporting
  • Fixed some issues with Xcode 7
  • Did various stability fixes and enhancements (please refer to Changelog for more information)

Project home:


Quick Start guide:
Reference Documentation:

If you are interested to get your hands dirty with the new Messenger sample Application and see the SDK in action, you can install the .ipa directly, from:

As always, feel free to jump in and play with the SDK code and contribute. If you have any questions please post at the Restcomm forum:!forum/restcomm



Restcomm Is Getting a Facelift with SIP Presence API

SIP Presence is a valuable feature that can help hence Restcomm monitoring and usage. With that in mind, we are pleased to announce that we shall be adding SIP Presence API as part of the next iteration of Restcomm. Below is an overview of the SIP Presence API.

This new feature will be part of the Clients API  and will have the following attributes:

  • latest_appearance” (for responses in JSON format) or
  • LatestAppearance” (for responses in XML format).

The “latest_appearance attribute has the following values

  • value = “offline” – When a client has not contacted Restcomm
  • value = “date” – The date will have the format “EEE, d MMM yyyy HH:mm:ss Z” and the date is set when the Client contacts Restcomm

The presence information can also be accessed through an exclusive Client API path. You may append the word “presence” at the end of the Client API URL as seen in the example below

Clients API with all the informations about one client:

Clients API with only the presence information about one client (Presence API):

The presence attribute will be updated every time the client sends SIP messages like REGISTER, INVITE, MESSAGE, INFO and BYE to Restcomm server. To get more information on how to access the Clients API, click here.

The video below shows presence in action. Enjoy it!

TeleStax is opening RestConn T-shirt Design Contest

Design the Restconn T-shirt and win invitation and travel expenses paid for the exclusive VIP event for RestComm Rock Stars in Lisbon 19-22 November.


  1. Go to Telestax’ Google + page
  2. In the latest posts find the RestConn T-shirt Design Contest post
  3. Design your own RestConn T-shirt
  4. Publish in in a comment below the post
  5. Invite your friends to vote for it

The design with highest vote rate will win the contest.

Deadline is 18 October at 00:00h UTC. The winner will be announced on Monday, 19 October.


Announcing the Release of TelScale SMSC 6.2.2.GA

SMSCTeleStax is pleased to announce the latest release of TelScale SMSC 6.2.2.GA. This release is an exciting milestone in our continued strive to produce quality software that will contribute to our customer’s success.
This latest release comes packed with new features that will ensure better user experience.
  • Lightweight pass-through mode : Gateway can be configured for sending of only SMPP originated datagramm and transactional messages and does not need to install any database.
  • Message processing rules : Introduces of message processing (mproc) rules. Each rule contains a set of conditions (like destination address mask). If an incoming message fits to the conditions then rule actions will be applied to the message (like adding a prefix into a destination address or networkId changing). There is a default implementation of mproc rules which covers some cases. But users can implement their own custom set of mproc rules by implementing of java interfaces exposed by SMSC.
  • Diameter rejections : When Diameter server rejects an incoming message then SMSC Gateway will send those rejects as responses back to an message originator
    (for SMPP and MO originated messages). So the message originator will know if the message is accepted or not.
  • Fixing of GSM7 messages encoding issues : Fixed several issues of GSM7 encoding errors in case of two-septets characters (like “[” or “]”) are present or in the case when the last part of a splitted message is short.
  • GSM7 encoding at SMPP part : Gateway  supports now GSM7 encoding at SMPP part (in addition to UTF-8 and Unicode encoding)
  • Preconfigured HLR address : There is now a possibility of using a special pre-configured HLR address instead of MSISDN for SCCP CalledPartyAddress in SRI request.
  • National Language Shift Tables : SMSC Gateway now supports National Language Shift Tables which are used in encoding of GSM7 characters.
  • Message restrictions for ESMEs : SMSC Gateway now supports minimal/maximal message length and rate per a second (a minute, a hour, a day) limits per ESME.
  • GSM message classes : SMSC Gateway now supports dest_addr_subunit parameter at SMPP part. This parameter specifies GSM message classes.
  • New license library : Switched to license library 2.2.3, which is by default off-line.

Following is the comprehensive list of fixes done in SMSC 6.2.2.GA

** Bug

* [SMSC-204] – Docs: Remove of mentioning of cassandra.cql from SMSC GW Intsallation Guide
* [SMSC-205] – Needed to update InSystem field for FAS mode when a message has beed invoked form a database
* [SMSC-210] – Delivery receipts for the several permanent undelivered messages contain the content of the first message
* [SMSC-214] – Improper logger spelling
* [SMSC-216] – SS7 GUI shows Service running only for jSS7 but when packaged with SMSC it always shows down
* [SMSC-217] – Double logging issue
* [SMSC-218] – Docs: adding “SCTP libraries” into “SMSC GW installation Guide”
* [SMSC-219] – Add “TelScale_SS7Stack_Release_Notes” and “TelScale_SS7Stack_Installation_Guide”
* [SMSC-222] – Too long time duration to restore of functionality after long time shutdown
* [SMSC-223] – Exception when GSM7 encoding of the short message with UDH
* [SMSC-229] – SMSC tries to store receipts into SLOT_MESSAGES_TABLE_2000_01_01 table
* [SMSC-246] – Docs : Add new chapter explaining how to use TelScale-smpp-simulator tool
* [SMSC-249] – Bad processing the case when there are very many messages to the one dest
* [SMSC-250] – BIND request sent by SMSC doesn’t respect System Type parameter
* [SMSC-252] – Big message count can be stored into one due_slot
* [SMSC-253] – Reduced sending rate when very many messages to the one dest address – SMPP
* [SMSC-258] – NullPointerException when receipt creating after ValidityPeriod expiring filter

** New Feature
* [SMSC-177] – GSM7 Bit SMS with special character and length of 140 chars throws exception
* [SMSC-265] – SMSC should allow Custom MProc Rule
* [SMSC-186] – A special mode when all generated by SMSC GW messages will be routed to originated ESMEs
* [SMSC-179] – SMSC GW: lightweight pass-through mode
* [SMSC-191] – Old style home routing functionality
* [SMSC-194] – Message splitting procedure must care on GSM7 extention table characters
* [SMSC-198] – Using in CalledPartyAddress (SRI) a preconfigured HLR address instead of MSISDN
* [SMSC-199] – Docs: add description for HLR addressing of SRI messages in HR mode
* [SMSC-200] – MessageProcessing (MProc) functionality just after a message has come to SMSC GW
* [SMSC-201] – Converting of national -> international numbers for incoming SS7 messages
* [SMSC-202] – Different networkId for incoming / outgoing messages at SMPP ESME / SIP
* [SMSC-207] – PotentialVersionIncompatibility response -> switching to MAP V1 message problems
* [SMSC-209] – GUI for MapVersionCacheMBean has to be updated
* [SMSC-211] – NetworkId of originated ESME will be assigned to a delivery receipt (optional)
* [SMSC-213] – National Language Shift Table support
* [SMSC-224] – Splitting messages for specified length in SMPP-Simulator
* [SMSC-225] – Adding support for GSM7 encoding at SMPP part
* [SMSC-226] – GUI update after introducing of GSM7 style encoding at SMPP part
* [SMSC-227] – Docs: introducing of GSM7 style encoding at SMPP part
* [SMSC-228] – min-message-length / max-message-length ESME options
* [SMSC-230] – GUI: mproc and orignetworkidforreceipts
* [SMSC-231] – Docs: mproc and orignetworkidforreceipts
* [SMSC-232] – GUI: adding min-message-length / max-message-length ESME options
* [SMSC-233] – Docs: adding min-message-length / max-message-length ESME options
* [SMSC-234] – GUI: National Language Shift Table support
* [SMSC-235] – Docs: National Language Shift Table support
* [SMSC-237] – Support for dest_addr_subunit at SMPP part
* [SMSC-238] – GUI: for skip-unsent-messages command
* [SMSC-239] – Docs: “smsc skip-unsent-messages” command and a new fields in “smsc stat get”
* [SMSC-240] – Docs: update a chapter for manual’s for CDR format
* [SMSC-241] – GUI: for hrhlrumber parameter
* [SMSC-242] – Docs: for hrhlrumber parameter
* [SMSC-245] – Switching to a licence lib 2.2.3.Final
* [SMSC-247] – Response to an originator after a diameter response (MO/SMPP orig)
* [SMSC-248] – Adding SMSC-Address 2017 parameter into diameter request
* [SMSC-251] – Review SMSC Docs for Improvements
* [SMSC-256] – Docs: adding a manual chapter for smsc-diameter interconnection
* [SMSC-260] – mproc rules: checking conditions based on last updated values
* [SMSC-261] – SMSC Re-preparing already prepared query
* [SMSC-267] – Add the throttling capability in smpp-load test tool
* [SMSC-268] – Update manuals for Customized MProc Rule

** Task
* [SMSC-144] – Document and blog with examples about the different send modes – datagram, forward and store, store and forward
* [SMSC-206] – Docs: add a chapter that describes all aspects of SMSC message routing

TelScale SMSC Gateway 6.2.2.GA has been load tested and results can be seen at

You can download the binary version HERE

Telscale SMSC Gateway Processes 1 Million SMS in Record Time

Telestax is pleased to announce the result of our load test performed using the latest iteration of Telscale SMSC Gateway. The load test was performed on an Amazon cloud server with the follow specifications


Amazon Cloud Server specification

Model vCPU Mem (GiB) SSD Storage (GB) Dedicated EBS Throughput (Mbps)
m4.2xlarge 8 32 EBS-only 1,000

Server configuration

  • Java version JDK version 7
  • Telscale version Telscale-smsc-
  • Cassandra apache-cassandra-2.0.17-src.tar.gz
  • JAVA_OPTS=”-Xms12g -Xmx12g -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000″


Test Result

The Cassandra and Telscale SMSC gateway ran on the same server.

Using the integrated SMPP load test tool, 1 Million SMS messages were sent to the Telscale SMSC server.

Processing was finished in 16 mins and 28 seconds

Processing an average of  1000 messages per second



Result after successful load test


As you can see from the build result above, the whole process took a little over 16 minutes. The throughput of 1012.891 per second.

CPU and Memory Usage

The CPU usage peaks at about 60 percent at the height of the load with constant traffic from the SMPP Load test.

The CPU and memory usage is shown in the screenshot below.






Sign up for Telestax news, case studies and product updates:

Enter your personal information below: