The beauty of professional open source collaboration

The benefits of open source software collaboration over proprietary black box enterprise products have been well understood and popularized. However less has been said about the benefits of professional open source software collaboration. The keyword professional is important because it distinguishes care-free open source community development, forking and experimentation from commercial grade software covered by legally binding warranty, indemnification and liability terms.

Telestax is a proud user and supporter of both community open source collaboration as well as professional open source collaboration. Telestax is the main sponsor of Restcomm – the #1 Open Source Cloud Communications Platform. The company also offers a suite of commercial grade products under the Telscale brand, which are based on the Restcomm source code. While Restcomm projects are licensed under AGPL. Telestax has the exclusive rights to license derivative Telscale products under terms suitable for a range of commercial applications.

As a company policy, Telestax makes the source code of its Telscale products available to customers. In the spirit of open source, Telestax encourages customers to collaborate with both the Restcomm community and with the Telestax engineering team. Each has different benefits:

  • Participation in the Restcomm community projects, mailing lists, IRC, Stack Overflow and other public forums allows our customers to understand the underlying technology and influence roadmap direction.
  • Participation in the Telscale development effort allows customers to develop operational expertise and confidence in their ability to properly use the software, diagnose issues, suggest fixes and improvements that help the production deployments of their applications.
Collaboration between users and contributors in the Restcomm community has been well documented and effective for years. There are hundreds of registered individual contributors and others who are covered by blanket corporate contributions.

The following diagram illustrates the approximate code contribution model based on the original blog by Vincent Driessen:

professional open source collaboration

Photo courtesy of Vincent Driessen

The rest of this article will cover the professional collaboration practices between Telestax customers and the core engineering team on Telscale products. There are several common types of requests from customers related to the  Telscale code base:
  1. Bug fixes – customer identifies a bug in the code and provides a test case to reproduce it. In this case the Telestax engineering team reviews the test to ensure that it properly uses the APIs. If the customer also provided a patch, the Telestax team reviews the patch to ensure that it indeed corrects the behavior of the product without introducing undesired side effects. If patch was not provided, the Telestax team writes it. If all looks fine and regression tests pass, the patch is applied and rolled into the next upcoming maintenance product update. All customers benefit from this fix.
  2. New features – customer requests a new feature or enhancement to the Telscale product. This can split into two routes:
  3. New features or enhancements that are aligned with the product roadmap and would benefit majority of customers. In this case we engage in a constructive design discussion about the best way to meet the requirement. Once we agree on design and main goals for the improvement, the customer can choose to either implement entirely with their resources or engage Telestax to help. We referrer to the latter as funded roadmap development. Depending on the agreed terms, Telestax or a certified partner does some portion of the development, testing and release work.
  4. New features or enhancements that are custom, outside the product roadmap. Such features either break API contracts or introduce behavior that will not benefit the majority of customers. For this type of requests Telestax does not accept modifications to the code base. Instead we work with the customer to design a clean API or SPI (service provider interface) in the code that Telestax will maintain as part of the Telscale product  and would allow the customer to build their desired extension in a way that it can achieve the desired behavior only by interacting with the newly designed interface without any further modifications to the Telscale source code. This approach allows 1) the customer to achieve their own goals without having to maintain a complete fork of the product; 2) no other customers are affected by the particular extension.
The collaboration categories above are the most typical ones and they borrow heavily from the best practices that we use for open source community projects. We make a best effort to port to the upstream open source code base any modifications made to the Telscale code as soon as possible. Sometimes this can take a while due to security or other commercial concerns.
Hope this article clarifies some of the common questions on the Telestax Professional Open Source Collaboration practices.  If you have additional questions, please feel free to ask in the comments section below or submit a private inquiry via this contact form.

Docker image for Mobicents Restcomm 7.3.0


Continuing our effort to make Restcomm available and easy to deploy in more and more platforms, we are pleased to announce the Docker image for Mobicents Restcomm 7.3.0 so now you have even more options for Restcomm deployment.

Using the Restcomm docker image you will be able to work with Restcomm without need to spend time on configuration and setup since most of that have been taken care by the image. Restcomm update will also be easier since all you will have to do is to update the docker image and the scripts will take care to update the application.

On top, the Restcomm docker image provides options to persist the database, the recording and cache files, the visual designer workspace and the Restcomm and Media Server log files so you can keep the container stateless. Additionally you will be able to provide your VoiceRSS key so text-to-speech service will be available in your applications.

Currently the Restcomm image uses Mobicents-Restcomm-JBoss-AS7- and will be updated to the 7.3.0.GA in the next days when the testing phase of the 7.3.0 release is done. The plan is to provide multiple tags for the Restcomm docker image so you will be able to use either the latest (SNAPSHOT) version or one of the GA releases. For example restcomm:latest will give you the latest (SNAPSHOT) version or restcomm:7.3.0 will give you the 7.3.0.GA version.

The Restcomm docker image page at provides all the instructions for you to get started.

We’d love to hear from you about new features, issues or advices.

Stay tuned for more and make sure you subscribe to Telestax newsletter and follow us on Twitter so you miss nothing.

– George

TelScale USSD Gateway 6.2.0.GA is now available!

ussd-gateway-logoTeleStax is proud to announce the latest stable release of TelScale USSD Gateway, version 6.2.0.GA, a robust and carrier proven USSD Gateway built on a modern extensible middleware platform. We’ve done our best to bring new features to TelScale USSD Gateway while still maintaining the stability, security and simplicity that you have come to expect from TeleStax.

With release of 6.2.0.GA, 6.1.x comes to end of life cycle. 6.2.0.GA is based on TelScale jSS7 6.2.x releases. Below are major improvements

  1. Switched over to new JSS7, MAP RA and license library
  2. GUI now displays monitoring statistic information. For various graphs exposed please look at recent load test post here
  3. USSD Push handles user object’s. Application can send String values with every request to gateway and the corresponding HTTP response will carry this value for application to match request with response.

Want to learn more about TelScale USSD Gateway?

Apart from these new features there are various fixes and performance improvements. Couple of points to keep in mind if you are migrating from older USSD Gateway are

  1. Encoding of destinationReference and originationReference: “nai” and “npi” has been changed from numerical to literal values as shown in the example below:
    <destinationReference number=”3344322300008002″ nai=”international_number” npi=”land_mobile”/> <originationReference number=”3224628968300″ nai=”international_number” npi=”ISDN”/>
  2. Encoding of GlobalTitle: short interface name is used for type as shown in the example : <gt type=”GlobalTitle0100″ tt=”0″ es=”0″ np=”1″ nai=”4″ digits=”83794700299″/>

If you are an existing Customer, you can download the latest binaries and comprehensive documentation from the Premium Content section in your TeleStax Support Portal Account.

Contact TeleStax Sales to learn more about or purchase TelScale USSD Gateway with Commercial-Grade support. You can find the Product Data Sheet in our website.

Restcomm is HP Helion ready !




We are proud to announce that now Restcomm gets HP Helion Ready certified and is available as part of HP Helion Ready ISV Solution Catalog

HP Helion uniquely combines OpenStack® and Cloud Foundry to deliver a cloud platform based on open standards, and enterprise-grade security, reliability and manageability. HP Helion helps customers build and manage hybrid cloud services at enterprise scale. The HP Helion Ready badge signifies that our software can be confidently deployed by customers with HP Helion OpenStack and HP Helion Development Platform and will be fully supported by us. For more information about the HP Helion Ready Program, visit Read our support policy here and

In the following video, you can watch Restcomm show case running at HP Helion openstack.

Working closely with the HP Helion team, we made it happen and you can now start working with Restcomm and HP Helion.  The deployment and setup of Restcomm at HP Helion is simple and straight forward, and the HP Helion documentation will get you covered for anything you might need.

Restcomm HP Helion Ready means that now you have more options for Restcomm deployment, especially if you are building a hybrid cloud at enterprise scale.

Want to deploy Restcomm on HP Helion ?

Submit this form to receive more information about Restcomm and HP Helion

Stay tuned form more and make sure you subscribe to Telestax newsletter  and follow us on Twitter (@telestax) so you miss nothing.

TelScale USSD Gateway achieves 700+ USSD messages/sec

ussd-gateway-logoTelScale USSD Gateway is a robust and carrier proven Gateway built on a modern extensible middleware platform. TelScale USSD Gateway provides core features for mobile subscriber to send USSD messages (over GSM network via SIGTRAN or legacy E1 links).

Test Scenario

We recently load tested SNAPSHOT version of upcoming release 6.2.0.GA and achieved stunning performance of 700+ USSD messages/sec on below mentioned hardware specs

  • Intel® Core™ i7-5600U CPU @ 2.60GHz × 4
  • Total RAM – 16 GB, assigned to USSD Gateway – 4GB
  • Ubuntu 14.04 LTS

Below diagram explains flow of the test. HTTP Application was deployed in same JBoss Server as Gateway.


Each (TCAP) Dialog had 4 USSD messages exchanged.

MAP Client (packaged with TelScale jSS7) was used for generating load (acting as HLR). Client was also started in same machine as Gateway Server.

Want to learn more about TelScale USSD Gateway?


Achieved 700+ USSD requests / sec !

Statistics Graphs

Bellow are the statistics graphs captured from USSD Gateway management console

Pull / Push Dialogs Established every 5 seconds


Above diagram shows Pull/Push (TCAP) Dialogs established every 5 seconds.

Cumulative Dialogs established over test period


Test was simulated to do 100K PULL requests to Gateway

Dialogs Per Second




All kinds of USSD Requests every 5 seconds



Above graph shows various requests exchanged in time frame of 5 seconds. In our case each dialog has 2 Process_Unstructured_SS and 2 Unstructured_SS. On an average it will come to 700+ requests / sec.


Wireshark Trace

If you want to see the trace result of the SS7/HTTP traffic, you can access the pcap files HERE. Below is the statistics of MAP messages (in this case USSD requests per sec)





Video Tutorial

If you want to learn more about testing Gateway, please see the video tutorial below



TelScale jSS7 6.2.3.GA Released – SS7 for everyone!

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


This update (jSS7 6.2.2.GA) adds the following features:

  1. New MAP Operation implemented – AuthenticationFailure
  2. Serialization for MAPErrorMessage classes
  3. Extra functionality into SS7 Simulator for USSD GW testing. Simulator can now also act as HLR for testing USSD Push scenario
  4. Serialization for ProblemImpl class


To see an extended list of features introduced in Telscale jSS7 6.2.3.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.

How to Quickly Deploy Restcomm on Google Cloud


Those who are familiar with Restcomm already know that getting started in the cloud can be done in a matter of minutes thanks to Restcomm on Amazon Cloud. That said, Amazon is not the only Cloud Service Provider out there. That is why we shall be looking at other ways to deploy Restcomm on the cloud. The tutorial below will show you how to proceed and get started running Restcomm on Google Cloud aka Compute Engine.



  • Basic Knowledge of Telscale Restcomm or Mobicents Restcomm
  • Google Cloud Compute Engine as explained HERE
  • Java JDK 7 or higher as explained HERE
  • Install screen (yum install screen)
  • Minimum compute engine “Machine-type” g1-small (1 vCPU, 1.7 GB memory) On a production server, increase the machine type to account for higher traffic.

Read more HERE



How I Became a Rockstar at TADHack (Part 1)

I walked in the 2015 TADHack London hackathon with the only goal in mind to create something using a Voxbone (the company I work for) product and Telestax’s Restcomm AMI. I ended up winning a prize and became a “telco dev rockstar” for a day, all thanks to these two main technologies I used for this hack.

This 4-to-5 parts series will cover how I built this hack with close-ups on each technology and API I used. I’ll try to keep it short!


Smart Dispatch

The idea behind the hack was to build an intelligent click-to-call for webpages (embeddable with a small script) that directs the call to the appropriate sales agent based on context. When the call is over, the information (context) gathered from the call is forwarded to the agent’s email/sms along with a link to the voice recording of the call. I called it Smart Dispatch.

How did I get information about the caller? In order to place the call, the client has to log in with LinkedIn and the information on profile is used as the context and sent over the email and sms when the call is over.

How is the call properly dispatched? I created a management platform for the companies embedding the click to call to link their agents to a particular segment pulled from LinkedIn. For example, if the user calling in has ‘Spanish’ as a language (on its LinkedIn profile), then the agent linked to the ‘Spanish’ segment will receive the call. This can be done for country, industry, or even particular companies (for account managers that want to receive calls only from their customers.)

Please find below the video presentation

Here’s a link to my slides:


Here’s a link to a demo of SmartDispatch (coming soon)


Below I break down the app with the different technologies I used as an overview. Tutorials for each of them will follow in the next parts.

Want to learn more about Restcomm ?

Submit this form to receive more information about Restcomm.

  1. Creating the click-to-call with the Voxbone WebRTC-SIP SDK

Voxbone is a SIP trunk provider and sells DIDs (phone numbers) from all over the world. They provide a WebRTC-to-SIP service by sending a WebRTC browser-initated call to a SIP trunk (through one of their phone numbers). The interesting part here is that the Restcomm platform works by receiving SIP call invites so this was the perfect match!

To get this working:

– I used a free iNum from Voxbone and linked it to a SIP URI for testing (later to be replaced by the Restcomm URI).

– Downloaded the Voxbone WebRTC Node.js library and remodeled it as an embeddable script.

– Placed a call!

More info on how to get started with the Voxbone WebRTC-SIP SDK here.


  1. Gathering information with the Linkedin API and passing the context in the call

The Voxbone WebRTC-SIP SDK has a very useful SIP header called ‘X-Voxbone-Context’ which is passed along in the SIP invite. I used this to place any JSON object I wanted. In this case: information pull from the user’s LinkedIn profile.

When the user logged in, I placed all the useful info from his profile in a JSON object and put it in the context header to be passed along with the call.

More info on how to get started with LinkedIn authentication here (I used OAuth Passport for Node.js)



  1. Figuring out who to send the call to with the management tool

In order to get the dispatching dynamic, I created a management tool for the agents to be configured to a particular segment. From this management tool, I created a small API for the click to call to pull this information from. Now, every time someone logs in via LinkedIn on the click2call, I know which segment he’s in and can know dynamically who to call.



I also use this platform/API to configure the agent’s phone number and email address to send the info at the end of the call.


  1. Forwarding and recording the call with Restcomm

Half of the application is done. I have all the info I need, and know which agent to send the call to. Now I need to send the call to Restcomm to forward it to the agent’s SIP client and record the call.

Since this is a hack, I made the dynamic dispatch on my end before reaching Restcomm. Ideally, I would use Restcomm as the dispatcher based on this info I sent it.

The great thing was that Restcomm was able to read my X-Voxbone-Context header with all the information I placed in it. This way, I could build anything from an IVR to a call-forward(er) based on the info I passed.

My Restcomm flow will be covered in more details later. Below is the overview:

  1. When call is launched, pass the context header to Restcomm
  2. IVR reads name and asks to wait for call to be placed
  3. Sends to call to agent’s SIP phone (this is where I’d like the intelligent dispatch to happen in the future)
  4. Starts recording the call
  5. When call ends, it sends me a link to the recording of the call (back to my REST service). So I can process it in my emails/sms

Here it is, working in action!



  1. Returning info and recording to agent with Nexmo and Mailgun

The hard part is all done now. I’ve got an intelligent call dispatcher that records the call. I can now send an SMS and an email with all the info:

– Profile info of the caller

– URL the caller was looking at

– URL of the voice recording of the call.

– And more!


Since I have my own database with the agents’ information configured, I know where to send all that info. I used Nexmo and Mailgun for that – they are pretty good APIs and were easy to use for the little time I had left to implement these features!


Here’s the info sent over sms to the agent:

sms (1)


Here’s the info sent over email to the agent (with a link to the recording of the call):





The next iteration of Smart Dispatch will see speech-to-text integration and more modularity with external services (Facebook, Act-On, Zoho, Salesforce). However, stay tuned for the next steps of this tutorial!

TADHack was a wonderful experience as I was able to work closely with the Restcomm team and get my application up and running very quickly. Alan Quayle pulled off a fantastic event filled with passionate developers eager to see WebRTC evolve in something bigger. Thank you for everything Alan!

Restcomm has the potential to do many more great things, like sending SMS or email from its own platform. All API/SDK I used were very flexible – remember this was all done in under 20 hours!

I look forward to the second iteration of Smart Dispatch and to the following parts of the tutorial.

Look out on twitter @SachaNacar for Part 2, a LOT more code is coming soon!

How I won TADHack – Number Mapping with Restcomm Visual Designer

Following Alan’s work and the TADSummit/TADHack in 2014 I have been fascinated: He managed to get a crowd together that deals with Telecom’s problems, but from an angle and with a spirit that is entirely different (i.e. significantly better) than “typical operator conferences” I’ve seen and attended before.

I could not make it to both initial meetings, but had the pleasure to attend the second TADSummit in Istanbul at the end of last year. It was a nice gathering of likeminded colleagues and “the new generation of potential Telco vendors”. Yes, in most of my posts and presentations you’ll see me emphasize the importance of a different mindset than the one traditional vendors still have when it comes to – well just about anything :).

After TADSummit I’ve felt quite excited to also attend a TADHack myself, but it wasn’t until recently that I was not quite sure what to hack together. In my day job I’m not a programmer, but deal with Telecom’s network evolution and design mainly. Over the years I managed however to always find a side project to try out some programming languages and approaches that interest me and that help me connect more with the IT part of the operator world. When we stumbled across a problem in one of the recent business meetings at work, several options for solutions have been discussed, but all of them were rather complex and required a lot of internal systems integration. It was then when I thought to reserve a couple of spare hours over a weekend and try to apply some of the things learned at TADSummit – with one of the components that has been part of the most impressive demo at this event.

The problem was to map fixed and mobile phone numbers of customers in an efficient way. It should avoid visiting a shop in person as well as complex integration with existing systems. It sounded to me it’s time to investigate the options of Telecom’s Application Development :)

About the number mapping problem

Subscribers often have multiple registered phone numbers for good reasons – mobile phone number, home/family number, office number and others.

As a matter of fact, there is no standardized way to find out what are the phone numbers that a user controls, nor what the user prefers to use these numbers for.

If such simple mapping information were available, one can imagine a number of productivity applications and daily workflow efficiencies that can be realized. Some examples:

  • During office hours, when the user is in their office and wireless reception is poor, calls to the mobile number can be forwarded to the office line.
  • When the user is at home, mobile phone calls from friends can be forwarded to their IPTV phone after 8am and before 8pm.
  • After hours calls to the office line from VIP customers can be escalated to the personal mobile phone unless the user is floating on an inflatable banana near a Caribbean Island.

The solution

The solution I came up with – that was presented at TADHack 2015 in London, UK – allows anyone to map a fixed number and a mobile number by themselves using only their fixed and mobile devices respectively. The solution consists of three main components:

  • API logic
  • Restcomm
  • Nexmo

The API logic has been developed using Node.js and the restify module, amongst others. It implements a RESTful CRUD interface and some advanced logic to interact with both Restcomm and Nexmo. It also interacts with a demo website that contains a short set of instructions for using the service as well as an overview of all mapped numbers.

Want to learn more about Restcomm ?

Submit this form to receive more information about Restcomm.

The service is imitated by sending an SMS from the mobile that should be linked to the service (via Nexmo) – including the fixed number that should be linked. The service responds with a PIN to this mobile number that needs to be entered from the fixed line.

The next step is calling the service from the fixed line, entering the PIN, and receiving a confirmation: This is Restcomm’s task. Restcomm is “called” and will interact with the API as “external service”. At first, it will check if the calling number has been requested to be mapped. If not, it will announce instructions how to get started. Otherwise it will ask directly for entering the PIN. After the 4 digit PIN is “gathered” it will be compared through the API. Depending on the response it will either announce an error or initiate the mapping of both number. The call will end with an announcement that both numbers have been mapped successfully.

The service uses the following of Restcomms features:

  • Play
  • Collect
  • External Service interaction
  • Variables & conditional linking of modules

The Restcomm flow is shown below.

For the demo, Restcomm has been setup on a Digital Ocean host and required only little integration and interaction (caused by not RTFM on my side :) with TeleStax’ team to make it fully working.

A key feature I think is noteworthy is the Restcomm Visual Designer. I have not found any other tool that is as easily usable and fast to create an interactive application as this. The application could be developed fast, the complex functions of Restcomm were rather self-explanatory.


The enabler is ready now and has also been demonstrated in a small showcase (you can call Restcomm, enter a fixed number and it will connect to the corresponding mobile number through a Twilio trunk). See video below

I am already working on developing interesting ideas for its further use as well as for the Restcomm application server to be part of my next hack or the solution to a new problem we may stumble across.

I fully enjoyed my first TADHack, and am very happy that the jury decided in the end to award my hack with a price. Thanks to all the sponsors, in particular TeleStax for the assistance during these two intense days.

The demos from the participants were all very good (and are also available online) and I have been really impressed by what has been created in such a short amount of time by everyone.

I would like to say a big ‘Thank you’ to Alan for all the efforts he put, for the great organization and perfect execution as well as his contribution to the ecosystem. TAD is a very important initiative and increasingly relevant for vendors and operators alike. I can wholeheartedly say that getting involved is time/money well spent!

The application is available at for the duration of the TADHack competition.

All materials are available at

Enterprise Monitoring for Restcomm – An overview of the APIs and the tools


We really hope that everybody enjoys working with Restcomm and taking advantage of the tools and APIs that the platform provides. We make our best to provide you with all the required material such as documentation, turorials and how-to posts at for you to best work with Restcomm.

But when it comes to the production deployment, an enterprise monitoring solution is missing. Of course Restcomm mission is not to be a monitoring tool, but rest assure that Restcomm provides all the required tools and APIs to use and integrate with well established monitoring solutions and project.

This post is the first one from a series of posts that will walk you through the integration of Restcomm with monitoring tools but not only that, we’ll show you how to best use the Restcomm APIs for integration with enterprise tools and provide sophisticated solutions for managing and monitoring the Restcomm platform.

In this first post I will give and overview for the Restcomm APIs and the tools we will use for monitoring and the integration to enterprise tools.

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

Enter your personal information below: