Ben Langfeld's Blog

Adhearsion 3 Roadmap

2015-06-23T00:00:00+00:00

Time Flies

It’s been almost 5 years since we released Adhearsion 1.0. Adhearsion 2.0 was released more than 3 years ago. In total, Adhearsion has been around for 9 years now.

Wow, that’s a really long time. Along the way, we’ve built a bunch of cool applications with Adhearsion which now underpin several big businesses and interesting projects, and a lot of the work on those has fed back into the open-source Adhearsion project. Shortly after the Adhearsion 2.0 release, I got fed up of promising FreeSWITCH support for so long and so just went ahead and added it. In collaboration with Grasshopper Inc, and thanks to Chris Rienzo, we managed to replace this implementation a year later with native support for Rayo in FreeSWITCH.

Until recently, we have lacked support for AMIv2, meaning users of Adhearsion were held back from upgrading past Asterisk 11. Thanks to another collaboration with Power Home Remodeling Group we were able to add AMIv2 compatibility to Adhearsion, the first parts of which were released in Punchblock 2.7.0.

But let’s talk about what’s coming down the road.

What’s Coming in Adhearsion 3

Now, on to the other items we are aiming to include in an Adhearsion 3.0 release, which we are hopeful to have ready by the end of the summer (northern hemisphere):

Core support for internationalisation
Merging adhearsion-asr into core to replace the old #ask and #menu methods which were found to be lacking
Integration of a web server for serving grammars, prompts, recordings, etc, as well as a batteries-included APIs for Adhearsion applications
Better performance through simplification and support for Ruby language advancements
Complete replacement of the EventSocket with Rayo for FreeSWITCH support This implementation has long been deprecated in favour of using Rayo, and everyone we have heard from has already migrated. Rayo’s many technical advantages means our FreeSWITCH support will continue to be great
Better documentation regarding application packaging & deployment – We’ll share what we’ve learned from 3 years of deploying Adhearsion 2 apps

What we need from you: feedback on this list! The Adhearsion community is core to the success of the project. Reach out to us on the mailing list, via Github Issue or, better still, a Pull Request.

Adhearsion + Asterisk Support Plans

Our new support for Asterisk 13, which is supported by Digium until October 2019, leads neatly to a discussion of how Adhearsion will move forward with compatibility for Asterisk in the future. As we detailed, there are improvements we can make to our support for Asterisk based on improvements in AMIv2 which are not backwards compatible with Asterisk 11. For now, we are supporting both AMIv1 and AMIv2, but in order to fully take advantage, we would have to drop support for Asterisk 11. When and how can we do this? Adhearsion follows Semantic Versioning, meaning that removing features requires a bump to the major version number. So if that’s all we care about, we could remove support for Asterisk 11 in Adhearsion/Punchblock v3.0.0. It’s not, though, and we’re equally concerned about having a smooth upgrade path for users of Adhearsion and Asterisk. For this reason, we are proposing the following policy:

A major version of Adhearsion will always support at least two LTS releases of Asterisk. Support for “standard support” Asterisk releases will not be guaranteed, but best effort will be made to use standard releases as an opportunity to introduce support for the following LTS release.

For Adhearsion 2, this has long been Asterisk 1.8 and 11, and now includes Asterisk 13, but Asterisk 1.8 sees its end of life in October of this year, so:

Adhearsion 3 will drop support for Asterisk 1.8 to anticipate its retirement.

Lastly, Asterisk 14/15 will be released in October 2015/2016, and will hopefully bring further improvements relevant to users of Adhearsion. Therefore:

Adhearsion 3 will add experimental support for Asterisk 14 around the time of its release. Adhearsion 4 will include full support for Asterisk 15, dropping support for Asterisk 11.

I’d love to hear feedback on this policy; any suggestions from our community who may be impacted by this are much appreciated.

What about ARI?

P.S. Yes, we want to support ARI. There’s one major blocker though, and that is that ARI does not yet support text-to-speech or speech recognition. Without those key ingredients, the Adhearsion framework would be significantly less useful on Asterisk. As soon as those become available via ARI, Adhearsion will be moving to ARI. Of course, this change will be transparent for Adhearsion users; suddenly Adhearsion on Asterisk will just start to perform better.

Where to go for more

Work on Adhearsion 3.0 is starting right now on the Adhearsion and Punchblock develop branches, so stay tuned there for details of what goes in, as well as the 3.0.0 milestone. We’ll announce again when we get to an alpha release, but in the mean time, get in touch in the comments below or via one of our other channels.

At the intersection of WebRTC and Traditional Telephony

2015-05-12T00:00:00+00:00

Since the beginning, Mojo Lingo’s focus has been building real-time communication applications. Our clients have often hired us because of our reputation as innovative and progressive; many of the applications we build are on the forefront of communications technology. One of the technologies we regularly employ, and the focus of this post, is WebRTC.

Many of our clients have large, complex, expensive platforms in which they have invested much money, time and effort over many years, whose operational properties and business value are known. Often, their regard for WebRTC is less certain. We’re frequently tasked with helping them to figure out how to evolve their product for anywhere from the immediate horizon to the next 5 years. This juxtaposition of stable platforms and modern interface (sometimes so modern that the specifications aren’t even finalized yet) can cause something of a dilemma.

Legacy Platform Limitations

While WebRTC is based on many of the technologies already in use for VoIP, it leaves the signaling protocol unspecified, and presents some new requirements which are not satisfied by existing systems. For example: Despite having reached End-Of-Life several years ago, Asterisk 1.4, remains in use by a large number of people. In order to integrate WebRTC with this or other similar older platforms, one must find a way to add support for:

Websocket transport, to enable browsers to send SIP messages
DTLS, the media encryption technology mandated by WebRTC (notably: WebRTC disallows the older SDES standard)
ICE, or Interactive Connectivity Establishment, the technology mandated by WebRTC for far-end NAT traversal, including STUN and TURN
New Codecs, including Opus, assuming the platform requires higher quality audio than G711 provides

Gateway Challenges

In situations where one cannot easily upgrade the core platform to add support for these things, they necessitate a gateway from the new world to the old. Unfortunately, the task of building such a gateway is quite involved, and there are some nasty issues to tackle along the way, for example:

SIP over Websockets requires re-using an existing connection to route all traffic. This is relatively easy to deal with for record-routed traffic in the case of a dialog established by the WebRTC user-agent, but what about calls from the old platform to the WebRTC endpoint? The Path (RFC 3327) and Outbound (RFC 5626) specifications exist in order to allow proxies and registrars to properly navigate this problem, but these place many requirements on the registrar in particular. Many target systems don’t support these specifications, including the aforementioned Asterisk 1.4. In such a case, one must bend the rules of SIP slightly in order to accommodate.
ICE resolution delay. If one simply proxies WebRTC traffic to a legacy system, particularly interconnecting with the PSTN and decrypting the media while performing ICE resolution along the way, one finds that there is often a significant perceived delay between the call being connected and the caller hearing audio. This is because ICE resolution (the process of choosing a path to traverse NAT) can take several seconds. In order to provide a good user experience, something must paper over this delay within the gateway.

We Can Help

Luckily, Mojo Lingo has dealt with these issues a few times already, and across varying use cases for several customers. We know what works and what doesn’t, and we’re well equipped to help figure out the best path for your business to adopt WebRTC as an extension of your existing platform with a short lead time and a high chance of success of your project. Get in touch to find out how.

Adhearsion Survey Results v2

2014-03-13T00:00:00+00:00

In January, we put together the second round of the Adhearsion Community Survey to gather data on how Adhearsion is being used in the wild, and what factors are important to the people and projects using it. This survey closed on Friday 28th February, and we’ve got the results for you right here in full (minus identifying information) to browse through. Below please find our high-level takeaways from the survey responses that we are now using to process our next steps in Adhearsion and to consider the content for RatchetConf (stay tuned):

Internationalisation support is now more important than it was last year. We’ve listened to this and started work on adhearsion-i18n. This plugin is in early development, but will hopefully mature quickly, especially with community use.
Satisfaction with our documentation has increased drastically since last year
Respondents now consider the supportive community, quantity of features, API clarity and performance to be a stronger aspects of the Adhearsion project
Deployments on Asterisk and FreeSWITCH are now almost even, but deployments on Voxeo PRISM have now dropped off the map
People deploying to Asterisk are now overwhelmingly using Asterisk 11, while deployments on Asterisk <= 1.8 are all but gone (yay!)
Most people have upgraded from Ruby 1.8 to Ruby 1.9.3 (this means Adhearsion 1 applications going away), but fewer people are deploying to JRuby than last year
Average call volume on Adhearsion applications is up, with one respondent reportedly processing over 100k calls per day!
Most respondents consider themselves to be primarily Ruby developers, rather than telephony or web developers

This data will help to inform our decision making about the future of Adhearsion, through the rest of the 2.x series and on to 3.0.

Please don’t hesitate to continue to send us feedback about Adhearsion whenever you like. You can post on the mailing list, file feature requests or bug reports or get in touch with Mojo Lingo to discuss how we might help your project further.

Go ahead and take a look through the results for yourself. Let us know if you spot anything interesting.

Adhearsion 2.5 is here

2014-02-04T00:00:00+00:00

Today the Adhearsion core team would like to announce the release of Adhearsion 2.5.0, the latest feature release in the Adhearsion 2 series, which includes a selection of new features:

Allow stopping all components executed by a controller when passing from it (#hard_pass) or at will (#stop_all_components)
Generated plugins include a .gitignore file
Detect something like “1234#” as characters instead of text
Add --empty switch to app generator for power users. Generates an app with less fluff.
Default generated applications with config appropriate for Telephony Dev Box
Allow preventing automatic call hangup after controller completion. Set Call#auto_hangup = false prior to controller termination.
Allow specifying a pre-join callback to #dial
Allow specifying ringback to #dial as either a list or a proc
Allow passing :join_options parameter to #dial to specify the kind of join to perform.
Allow passing :join_target parameter to #dial to specify who to join to (eg a mixer).
Generated apps now encourage storing most app code in app/, which is in the load path. Nothing in this directory is auto-loaded, but can be easily required without messy relative paths.

Adhearsion 2.5 also includes one major compatibility change, and that is that Ruby 1.9.2 is no longer supported. Ruby 1.9.2 reached its end of life date last year, and is no longer receiving security fixes from the Ruby core team. For this reason, we encourage anyone who is still using Ruby 1.9.2 to upgrade at least to Ruby 1.9.3, or preferably to Ruby 2.1, since Ruby 1.9.3 will reach EOL in just over a year’s time. For more details on this change, see our GitHub update. Additionally, see the changelog for further details on bugfixes included in this release.

We hope you enjoy the new features in this release, and would appreciate your feedback on this release; note that the Adhearsion Community Survey is currently running, and would be a great place to share your feedback. We’ve already begun work on changes proposed for Adhearsion 2.6 and even Adhearsion 3.0, so check those out!

Surveying Adhearsion usage

2014-01-20T00:00:00+00:00

It’s been approximately 7 months since we last surveyed the Adhearsion community about how and where Adhearsion is being used, and users’ priorities for the project. Since that time, much has changed. Here is a selection of highlights over that time:

Major performance enhancements to Adhearsion 2 on Asterisk have been realized
The Rayo specification has been published by the XSF, and Adhearsion/Punchblock have been made compliant with the latest revision
FreeSWITCH has gained a Rayo server implementation that is compliant with the specification, and this has gained wide adoption
Adhearsion has become fully compatible with JRuby, and use on JRuby has been adopted among many of the larger Adhearsion deployments for better performance
Asterisk 12 has been released with updated APIs
The last AdhearsionConf was hosted in Atlanta in December 2013
Several important new plugins for Adhearsion have been released or significantly improved, including Voicemail, Matrioska (In-Call Apps), Lemondrop (Redis), Statsd (Adhearsion-Stats), and more

For these reasons, we feel it is now time to once again gather the opinions and usage data of the Adhearsion community and have updated our survey to that effect. We would really appreciate if everyone who currently uses Adhearsion as part of their application stack could spend a few minutes to complete it, in order to more fully inform the core team of the priorities for the project going forward, and help us to deliver a more valuable, performant, flexible and robust Adhearsion core.

Take the 2014 Adhearsion Survey

This survey will close on Friday, February 28th and the results will be published here on Monday, March 10th. Thanks for supporting the Adhearsion Community!