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.

First time in TADHack 2015 / Madrid

Madrid is a great place to be in summer but things get really hot when one takes part in a TADHack event too. Traditionally held in ETSIT UPM, the telecommunication school of the university, TADHack was a groundbreaking and fun experience. It had it all: brilliant young people with fresh ideas eager to spend a weekend over the keyboard, experienced telecomm professionals willing to share their knowledge, a welcoming and friendly hosting team making sure  everything runs smoothly and of course the technical infrastructure of the university. It offered among others a massive 10GB internet connection, probably better than all other locations combined. All that posed no barrier for the participants on top of their already challenging task: to think and implement their own hacks in two days (and one night) time.

I was there, representing telestax to discuss ideas for hacks and help teams interested in Restcomm find their way. Two teams had a prominent presense there and it proved it was for a reason.

Play My Band – The local winner

Winner of the local Madrid TADHack event was the team of Jaime Casero, Carlos Torrenti and Carlos Verdes presenting their Play My Band hack. An outstanding game, based on WebRTC data channel that leveraged Restcomm for easy access to the WebRTC session.


The Play My Band team. A pile of sticky notes on the desk. More features under way!

You can learn more on Play My Band on its official webpage.

Augmented Sightseeing – The global/Madrid winner

Jose Luis Zamorano and his partner were also there. The team participated in TADhack for the first time and made a pleasant surprise. Their Augmented Sightseeing hack, a Restcomm based application for tourism guides with QR scanning, won the global Telestax prize for Madrid. This is what Jose reported after the event:

We had heard about Telco API and played a bit. When we watched some videos from TADHack 2014, we said next time we had to be there. We joined TADHack 2015 Madrid wondering why a Saturday early morning. It was the first hackaton for both of us and we didn’t know what to expect. Very soon we started to create adrenaline and enjoy the hackaton. We had in mind and idea about synchronizing a web app with a voice call behaviour but we were not pretty sure about the case of use. Then, first goal was defining the case of use, normally it should be the other way around, you think the case of use and later on you think about functional and tech details.

The brainstorming resulted in Augmented Sightseeing, a hack voice call synchronized with QR scanning applied for tourism audio/video guides. Augmented Sightseeing calls a phone trough PSTN and says a message which is linked with a QR code related for example with a painting, a monument… It could be extended with GPS position or a photo as a trigger to change the message. Strong points of the idea are user does not need to have a native app but a smartphone with a browser, internet connection and voice service.

The hack was implemented using Telestax Restcomm API. To be honest this API was not our first option. We tried out 4 Telco APIs including Restcomm. We didn’t have so much time to make the analysis although we concluded the tech features were very similar among different vendors but nobody else gave us so much facilities and support as Telestax, that is why we choose Restcomm.

There were very good people and very good ideas in the hackaton so it was a great surprise being awarded with a prize.

We have the feeling only tech people are looking at this technology so far while business is missing a big opportunity. Hopefully, thanks to TADHack, Telestax and rest of sponsors, Telco APIs are raising.


But that was not all for Telestax and Restcomm. Strong and weak points made their presence too. We were really happy to see people enjoying the ease of use and flexibility of the product but also accepted criticism as well as valuable feedback on how to make it better.

TADSlack – How I Used RestComm, and Slack to Win at TADHack 2015

After winning one of the prizes at TADHack London in April, I was quite excited to show up in Lisbon, Portugal for the big TADHack Global event of the year.  I arrived with a bag full of gear, including an Estimote BTLE Beacon, some Tessels, and a lot of ideas.  I spent the first part of Saturday kicking ideas around with a number of the teams at the event, and eventually settled on TADSlack.

What Is TADSlack?

TADSlack combines four technologies I’ve really grown to love:  RestComm Visual Designer,, Slack and of course a little slice of NodeJS. If you use Slack like I do, almost all day every day, you eventually want to leave the interface less and less. They’ve got hundreds of integrations already built, but one of the holes is the ability to make phone calls. I wanted to not only be able to make phone calls, but in the true spirit of Slack (where everything is searchable) I wanted to be able to search the contents of the calls I made.  So the idea boiled down to three simple concepts:  Make a call, record the call, and then make the audio recording searchable. TADSlack was born!

RestComm – Build Voice Apps Without Code

The first thing I had to do was build a voice application that would handle the audio portion of the call, as well as send my backend app a notification when the recording was ready to be indexed.  My RVD app had two modules: (1) A Welcome Module that answered the call, played a simple welcome message, and then dialed the destination number and (2) an External Service module that would send a POST request to my NodeJS server when the call hung up, giving me the public URL of the recording.

Screen Shot of Welcome Module:



Screen Shot of the Index Recording Module


Talk to Scott about the Future of Carriers

Submit this form to request a private discussion with Scott Barstow on this strategic topic. – Media Indexing On Demand

Once I got the call flow working, I needed to send the recording audio off to to be indexed for searching. If you’ve not heard of Clarify, they’re a great new company out of Austin that has an API to index audio and video without transcription. I’ve found the accuracy of their engine to be well above most transcription, and you don’t have to deal with text.  It’s simple to use: You provide Clarify with a publicly accessible URL and whatever metadata about the media you’d like to include, then they index it for you and send you back a webhook notification when it’s ready to be searched.

Putting it all together inside Slack

I had all of the pieces working, but I still had to wire it into the Slack UI.  I had to create two integrations in Slack, an Incoming Webhook Integration and an Outbound Webhook Integration.  The details for setting these up can be found on the Github project I created, but it’s pretty simple to do.  I could then do something like this inside of Slack:

Screen Shot 2015-06-22 at 1.34.06 PM

Once the call hung up, I would get a notification from my server application letting me know that indexing had started, and when it had been completed.Screen Shot 2015-06-22 at 1.36.14 PM

I could then search the contents of the audio I had just recorded, and the results would be displayed inside Slack, like this:


Pretty nifty!

Basic Architecture

Here’s a high level of how all of the pieces fit together.

Screen Shot 2015-06-22 at 1.41.31 PM

What’s Next?

There was one big gap in my hack, and that was the user interface to allow you to drop into the recording audio right at the point of the search term. I have a working prototype of this but could not get to it in time while in Portugal. I intend to integrate this into the project at some point soon. If you’d like to jump in and enhance / make this better, I’ve included a link to the source below and would love to talk more about it with anyone who’s interested.

Download the Source

If you’d like to try out the app, you can get the source for the backend application at the TADSlack Github project. If you’d like to know more about RestComm or any of the other technologies used in my project, please feel free to contact me on Twitter or through this blog post.

Happy Coding!

Global TADHack 2015 -Chicago

As a former TADHack attendee, I was looking forward to attending it again this year! Telecommunication app development is my favorite, and I find it very exciting!

I showed up last weekend with no clear idea on what I will be doing during TADHack 2015. However, I was confident enough that I would come up with a unique idea because of the tremendous amount of available resources for hackers, the API provider representatives both onsite and remotely, the support from fellow hackers and event sponsors, and most importantly, the inspirational environment of hackathons where I see everyone around me hacking and innovating!

Carol Davids, Professor &  Director RTC Lab at Illinois Institute of Technology, explained to us how the 9-1-1 system works today versus the future Next-Generation 9-1-1 (NG-911). That was the trigger for my idea BNG-911 (Before-Next-Generation 9-1-1). It was hard for me to believe that even though the future technology for advanced 9-1-1 services including text to 911 exists, it’s not quite yet implemented to be used in a meaningful way, and it may indeed take many years to install everywhere! That can impact the life of people in scenarios where they cannot call 911, and instead, they can only text. With more investigation on possible solutions that must be compatible with the way that 9-1-1 systems currently operate, I came up with my app idea BNG-911.

Telestax was the ideal platform to implement my web app in less than 24 hours. The tools developed by Telestax make it super easy and intuitive to develop telecommunication tools such as text, SIP calls, voice transcribe service, text-to-speech, and etc. Amit Bhayani was available on site in Chicago TADHack location to support hackers working with Telestax api like myself.

After several iterations on the app, I was able to have it fully functional by the presentation time. The hack was selected to win the Chicago local prize of $1,000, and the pitch was live streamed to all remote locations around the globe!

CHdhmA5UwAAELbp.jpg-large CHeA2DfXAAAzhXR.jpg-large

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

Enter your personal information below: