Restcomm Client iOS SDK Beta 2 is out!

We are proud to announce the second Beta release of Restcomm Client iOS SDK!

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:

  • WebRTC video support. Here’s a screen shot from Restcomm Messenger for iOS calling Restcomm Olympus:
    Webrtc Video Call
  • Simplified media facilities that result in smaller App footprint
  • Various stability fixes and enhancements (please refer to Changelog)
  • UX enhancements for Messenger sample Application

Project home:


Quick Start guide:
Reference Documentation:

If you are interested to get your hands dirty with the 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



TelScale jSS7 6.2.4.GA Released – SS7 for everyone!

jSS7-logoTelestax is pleased to announce the release of TelScale jSS7  6.2.4.GA,  an SS7 stack that can run as a  standalone program or as a service over TelScale JSLEE Server. 

The main highlights of this release are the addition of serializing for 4 extra CAP operations (furnishChargingInformation, connectToResource, romptAndCollectUserInformation, activityTest), updated GSM7 encoding (SMS service) for better message splitting and support for national shift tables.

Below is a list of major features implemented in this release.

  1. Load balancing between M3UA AS is now configurable (Loadshare or Override).
  2. GSMCharsetEncoder now supports 8-bit encoding that is used at SMPP part.
  3. Several new methods are implemented in the GSMCharset to simplify usage in the case of two-byte GSM7 characters (extension coding table).
  4. Support for National Language Shift Table.
  5. National Language Single/Locking Shift configuration added to SS7 Simulator.
  6. XML serializing for CAP error message primitives is included in this release.
  7. XML encoding for CAP operation – furnishChargingInformation, connectToResource, romptAndCollectUserInformation and activityTest
  8. The SS7 Simulator supports additional CAP operations: connectToResource , furnishChargingInformation , promptAndCollectUserInformation and activityTest.
  9. Support for SCCP multi-tenancy SAP selection.
  10. Support for persistence of TCAP ANSI parameters.
  11. The previous releases did not log stats for historical viewing and it was only possible to view real time stats in the GUI console. This release provides you with an option to have stats written to a log file for every refresh period.
  12. TelScale jSS7 Stack 6.2.4.GA-TelScale is switching to a new license 2.2.3 Final.
  13. Big fixes

To see an extended list of features introduced in Telscale jSS7 6.2.4.GA, click HERE

Follow the links below to download documentation:

Contact us for moving to the leading open source SS7 stack with Commercial-Grade Support

Existing customers can download the new version binaries from the Premium Content section in our support portal.

Enterprise Monitoring for Restcomm – Part 2



In a previous post – – we had an overview of what it means enterprise monitoring and Restcomm.

In this post, I will introduce you to the recent development of the the Monitoring Service of Restcomm. The Monitoring Service can be used to collect stats and monitor the health of a server.

Currently the Monitoring Service feature provides the following:

  • List of live calls
  • Status of the live calls

Next in the roadmap I have the following features:

  • list of live SMS or USSD sessions
  • Status of SMS or USSD sessions
  • Global stats, such as number of calls served up to now
  • Registration of remote supervisors – Restcomm will push stats to monitoring server for specific event.

For this blog post, I will use Graylog log management server –, from their web site:
Graylog is a fully integrated open source log management platform for collecting, indexing, and analyzing both structured and unstructured data from almost any source.

Grayog is great because we wont need any other external tools such as logstash, and on top they provide a docker image so we won’t bother to install and setup the application.

First we will have to get the Graylog docker image and run it:

You can find more information here

The Restcomm binary with the Monitoring Service is available from here:

After you download, unzip it and start Restcomm then we are ready to start monitoring.

Next step is to start Graylog. Using docker we need:

Now we need to instruct Graylog to collect from Restcomm. Go to System/Inputs -> Inputs choose “JSON path from HTTP API” and press Launch.

First provide something meaningful for the title.
Important is the “Additional HTTP headers” where you have to specify the following:

Accept: application/json, Authorization: Basic XXXXXXXXXX

The Authorization: Basic token is the administrators password encoded, its the same when using the REST API, for example using the Restcomm Admin UI (hint, start Wireshark capture and login to Admin UI, then check the Authorization header at the HTTP request)

JSON path is a great project that is used to extract elements of a JSON message in a similar way to the XPATH project, you can find more information here:

For the tutorial here we will need the following JSON Path expression:


Last, the URI for JSON resource should be:


Screenshot from 2015-08-07 19:40:13


When the input is ready you save and you can check the received messages, it should look something like this:

Screenshot from 2015-08-07 19:40:21

The screenshot here, shows that Restcomm at that point has 1 live call.

Expand the “result” filed and press to generate a chart:

Screenshot from 2015-08-07 19:42:32

Then you can add the generated chart to a dashboard (you have to create one first).

Screenshot from 2015-08-07 19:53:38

On the screenshot above you can see that at some point we had maximum 2 live calls.

More metrics and features for the Monitoring Service are in the roadmap so stay tuned and make sure you subscribe to Telestax newsletter and follow us on Twitter so you miss nothing.

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

– George

Restcomm Client Android SDK Beta is out!

We are proud to announce the first Beta release of Restcomm Client Android SDK, 1.0.0-Beta!

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

New Restcomm Client Android SDK features:

  • WebRTC audio support
  • Messenger UI improvements
  • Various stability fixes and enhancements (please refer to Changelog)


Quick Start guide:

Reference Documentation:

Anyone in the community interested in getting their hands dirty and contributing to the SDK, please don’t hesitate to drop as a line! Here’s our forum:!forum/restcomm

Restcomm 7.3.1.GA Release on Amazon Cloud


We are pleased to announce the latest iteration of  Restcomm 7.3.1.GA on Amazon Cloud. This version is based on the 7.3.1.GA binary release that was announced HERE.

You can create a new Amazon EC2 instance running Restcomm 7.3.1.GA here:

***Important Notice***


The Restcomm Admin GUI has a new URL


The older url http://RESTCOMM_INSTANCE_IP_ADDRESS:8080/restcomm-management has been deprecated!


Upgrading your current Restcomm Amazon instance to version 7.3.1.GA

Please follow the upgrade steps as detailed HERE


Restcomm Client Android SDK is out!

We are proud to announce the first release of Restcomm Client Android SDK, 1.0.0-Alpha!

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

Restcomm Messenger sample Application

The Android SDK features:

  • VOIP client capabilities that enable full Restcomm integration.
  • RTP media (WebRTC coming in Beta)
  • Easy to use, Twilio-compatible API


Quick Start guide:
Reference Documentation:

Anyone in the community interested in getting their hands dirty and contributing to the SDK, please don’t hesitate to drop as a line! Here’s the roadmap:!topic/restcomm/d88p771M9yE


Restcomm 7.3.1 is here!


We are proud to announce the Restcomm 7.3.1.GA with many new features, bug fixes and updated Restcomm AMI and Docker images.

This new release comes with the latest Sip Servlet platform with the bug fixes and new features it includes.

You can see the changelog for Restcomm 7.3.1.GA at the following link

IMPORTANT note for the management user interface.

In this version the management user interface is deployed in the root context and NOT at /restcomm-management/.

This means that to access the management user interface you should point your browser to http://RESTCOMM_IP_ADDRESS:8080/


Download links:

You can create a new Amazon EC2 instance running Restcomm 7.3.1.GA here:

Also, if you already have an Amazon Restcomm AMI instance running a previous release, your instance will be automatically upgrade to the latest, simply by rebooting the instance.

Your feedback is highly appreciated. If you discover a new bug or you have an idea for a new feature, we would like to hear from you. You can even be part of the Open Source GitHub RestComm project by contributing with 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.


OMNIQUBE launches OMNICORE on Microsoft Azure and TeleStax JAIN-SLEE

In another step consolidating telecommunication and IT, OMNIQUBE, a TeleStax partner, and its team have setup OMNICORE a true Cloud based Carrier Ready service platform for testing and validation of our operator and enterprise services. Deploying the Telestax Open-Source based Platform on top of JBOSS Application Server provides us with a versatile and scalable platform running various network applications. With this platform we can connect to MNOs and/or MVNO/Es using our in house STP (Cisco ITP) deploying multiple SIGTRAN connections. We can fire up multiple service instances and route various traffic to the required instance for both testing and potential production traffic services like SMSC, USSD GW, Intelligent Routing and our HLR/AuC under development.

Besides carriers and MVNO/Es we also target the enterprise providing routing and interworking services truly bridging the gap between Enterprise and Operator. In our setup we have proven interworking of Microsoft Lync 2013 (Skype for Business) with our JAIN-SLEE SIP applications and RESTCOMM SDP for rapid and agile application development for Web, IoT or Mobile Application developers. Options are network routing between various Lync Instances, Self Service Endpoints but we are also working on features like: Network Queueing, Skilled Based Routing and Mobile Busy Detection.

Gradually we now see virtualization maturing creating opportunities for Virtualized Network Functions like SMS, USSD and now even HLR/HSS. All these services can now run virtualized and can take full advantage of (auto) scaling, high availability, optimizing on a global scale and pay as you use.



Azure provides us with a low cost, highly versatile and extremely scalable compute platform for our services running on Centos. Azure also provides with powerful and flexible Virtual Network settings scaling up with multiple compute environments and comprehensive VPN connections. Scaling up one individual platform is easy increasing number of CPUs, memory or selecting SSD discs. Also Web Services, MySQL Databases, Active Directory, Storage and the related Load Balancing and Traffic Management will enable us to scale the platform on demand maintaining availability.

Our setup is done in a flexible way not locking into the Azure domain. It is our goal to be versatile and therefore it should be easy to move to other Cloud Services like Dimension Data, Amazon or dedicated hardware where we have experience with like Cisco UCS, IBM BladeCenter and low cost Dell PowerEdge. We use our proven deployment methods to enable this.

TeleStax TELSCALE Platform

We choose TelScale JAIN-SLEE because of its accessibility, robustness and scalability. Key in our selection is the availability of DIAMETER and a full featured SS7 stack, including MAP. The MAP stack is mandatory for our HLR and Authentication Center, providing a low entry SS7 protocol engine. Compared to other SLEE vendors this is a real advantage having a low entry with the growing number of challengers in the market for Internet Of Things (IoT) with a growing need for Machine To Machine communication for both consumers and businesses. Our test setup in the Azure cloud enables us to continue validating interconnectivity and further validation of our solution developed for HLR and further Lync 2013 integration.


Many enterprises move away from fixed desk phones and implement Microsoft Communication Server on top of their existing Microsoft IT services like Office Enterprise/365. With very limited investment on the desktop side (USB Headset) and a gateway function, full collaboration with chat, voice and video is available using Skype for Business and/or Office365. Challenges remain using portable clients on smartphones and/or tablets going off premise, connecting to a mobile network. Some fixed mobile solutions are feasible on the Lync Server, but both Lync Server and Mobile Network remain unaware of exact Phone/subscriber status on either end. Combining our broad knowledge of MSPL Routing Logic and UCMA Service logic with our network based SLEE Service logic and Carrier Connectivity and understanding SLEE SIP services, enables us to implement hybrid SIP services and enhanced Fixed Mobile convergence.


In our setup, through our ITP, we can configure a number of links routing to our test platforms. The ITP makes sure we don’t have to reconfigure our jSS7 and SLEEs continuously but we can just add a route on the STP. Using GT and SSN routing, but also routing on IMSI (range) we have a flexible setup making sure our test platforms is not polluted and we can create new instances without interference. We can connect to SLEE with regular SIP call control Client where a media server can be invoked for IVR.

Through our own SBC, EDGE Gateway and Microsoft Lync Services, one can connect using SkypeForBusiness or a POTS phone dialing a +3188xxx number. Our SBC will take care of the necessary security and routing logic required for our SIP domain where can involve our asterisk server for simple ‘in lab’ routing and ISDN interconnect.


With this setup it is our goal to validate Azure as a suitable platform to test and potentially run our own services or host/manage our client’s services. We will have a close look at usability and scalability of the platform, including performance, (I/O) latency and usability. Particularly connecting SS7 SIGTRAN signaling directly to the cloud, we must ensure to be compliant to the required (timer) standards. Also we will have a very close look at database performance, clustering, scaling and latency on transaction increase. On success of this validation process, we will take a next step launching a small service from this cloud platform. We are targeting a SS7 MAP interworking application and LYNC fixed mobile enrichment.

Talk to Hans about OmniQube

Submit this form to request a private discussion with Hans Kes on this strategic topic.

Calling All Developers – Let’s Build Some SDKs!

One of the great things about being an open-source company is that we look for ways to bring the community into the product development pipeline.  RestComm has had a full-featured REST API for quite some time now, but we realized at TADHack this year that we have to have better developer tools to make it simple to get building applications quickly.

Language-Specific SDKs

We’re kicking off an initiative starting today to dramatically improve the developer experience on RestComm, and we need your help.  If you’ve got chops in Java, PHP, Python, NodeJS, C#, or Ruby we’d love for you to jump in and help us build SDKs for the RestComm REST API.  We also need you to tell us what’s good and bad about our documentation and other resources along the way.

For each SDK, we’re asking for the following:

  • Coverage of the entire API using appropriate, idiomatic patterns
  • Full test coverage
  • Support for installation using language-specific package managers (Ruby gems, Node NPMs, etc.)
  • Examples that demonstrate usage of the API
  • Documentation of the basics of the API in the README

What’s In It For You?

Fame! Glory! Riches!

Ok, we can’t promise any of those things, but here’s what we can promise.

  • Our undying gratitude and public praise in all of our media channels
  • We’ll send you sweet RestComm swag like T-shirts, coffee mugs, and stickers. Maybe even an autographed picture of Jean! (But only if you’re really good)
  • We hire almost exclusively from the people who work in the community first.  If you’re interested in working on RestComm as a career, a great way to get noticed is to contribute where we need it and do a bang-up job

Are You In?

You’ve got the links. You’ve got the incentives. What are you waiting for?  Fork the repositories listed above and get coding!  If you have any questions, or need or help, reach out to us on our public Google Group or ping us on Twitter.

Thanks to our community for making RestComm the premier open communication platform. We couldn’t do this without you.

SmartDispatch – How I Became a Rockstar at TADHack (Part 2)

Part 1 of this series which introduces the SmartDispatch application is available here.

Assuming you’ve read part 1, you now know what SmartDispatch is and what is it for. So let’s dive into the code! Below, I’ve created a simple diagram that explains how the app works.



  1. User lands on webpage and authenticates using LinkedIn
  2. Webpage launches LinkedIn authentication and retrieves the user info to store in context variable
  3. Webpage uses location info from user to query Agent API based on user location
  4. SIP call to Restcomm instance with context header passed
  5. Restcomm directs call to Agent’s SIP client, records call, and sends information gathered to agent on hangup

Here is how the different parts are built:

1. Setting up the Dashboard & API

The dashboard serves as a way for the user to configure his agents with relevant information. It also acts as an API for the WebRTC Call client to consult to know which agent it should call based on the contextual information. I set up the dashboard and API using NodeJS. Just a few routes are needed:

A. Create user

This route is essentially to create the agent based on the appropriate data format.

B. Display user (JSON API)

This route essentially accepts a URL-encoded parameter (segment) and searches the database based on the segment passed.
For instance, the WebRTC Call Client will send and will receive the information returned from the agent database/API for the first available Belgian agent. Example:

C. Other routes

You can also include other routes such as displaying the /dashboard, remove users, modifying users, etc. My dashboard looks like:


dashboard (1)


2. Setting up the WebRTC Call Client

Again, I used NodeJS and here only a few routes and functions are needed:

A. Authenticate with Linkedin, I use passport for that (more info here)

Don’t forget to set the appropriate permissions in order to access all the profile info you will need. I used:

Then you can set all your context variables to the profile info like so:

B. Set up the getData() function called when authentication is done:

This function sets your context information (agent phone number, DID to call through the WebRTC SDK, and agent email to send the summary to) by passing the location detected from the authenticated LinkedIn user

C. Set up the Voxbone WebRTC-SIP SDK to call

Here’s where you can download the Voxbone WebRTC-SIP SDK which will link the browser to the Restcomm instance’s IP.


In your init() function, you can now pass all the data taken from LinkedIn and the userlist API to build a context variable:
You can then set all parameters of the SIP call that are passed to Restcomm:


3. Setting up Restcomm 

Now that you can send a call with context using a Voxbone phone number to a SIP URI, just link the phone number to your Restcomm’s instance URI (How to configure SIP URI with Voxbone). Here’s what my Restcomm App look like:




Module 1 receives the call echoes the context header to a REST service (see 3a.) then assigns all context variables to Restcomm variables, sends the call to the SIP client of the agent. On hang up, the flow is transfered to Module 2 where you can hook up any service you want to send the emails and SMS .


You make the magic, so play around with Restcomm.


3a. Setting up a context parser

At the time of this write-up Restcomm was not able to parse the JSON of the context object sent in the SIP call into multiple variables. Therefore, I set up an additional REST service that receives the context object from Restcomm (using their Hook URL) and echoes the content of the object into different variable for easy parsing. Hopefully Restcomm will integrate this feature soon!


Code available on the Voxbone Github page.
Restcomm App Available here.

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

Enter your personal information below: