New Relay / New Architecture


With the release of 3CX version 16, a ton of changes were made to the 3CX Call Control API. One of the biggest changes was the removal of most of the multi-tenant features held over from earlier versions of 3CX. But they have removed a large number of other methods our tools use. After looking at all the changes that would be required to get our current Relay to work with the new API, I’ve decided it’s time to focus all our efforts on our new .Net Core Relay.

Hat’s off to Shahzad, our chief architect of the original Relay. The Relay has proven to be far, far more reliable and flexible than I could have ever hoped for. He did an extraordinary job building a foundational part of our VoIPTools platform. “Wow”, is about the best thing I can say about his work. He is AWESOME!

But, as with all software, the technologies change and new capabilities mean we can do even more. When 3CX released the Linux version, we had to look at how to build one codebase to support both the Windows and Linux versions of the 3CX. Trust me, having two separate versions of the Relay would be a nightmare to maintain. Fortunately, .Net Core makes it possible to write one application that runs on both Windows and Linux (with some small platform-specific modifications).

The primary push for a new relay was the need to support Linux, but the intent was always to unify our Relay into one product that supports both Windows and Linux. With the release of 3CX V16, it makes sense to shift our development focus over to the new Relay rather than investing more in a product that was in the process of being phased out anyway. We have had beta testers using the new .Net Core Relay for several months now and the positive results have encouraged me to move forward with the new Relay for both platforms.

The Relay makes it possible (among many other things) to install our tools on a separate server from 3CX (something 3CX requested). The former Relay was based on WCF which is/was Microsoft’s enterprise-level approach to secure communications over the web. It’s been a great approach, but it has been a little tricky when it comes to security. Some customers in complex environments found it a bit challenging to get permissions setup correctly. The new Relay is based on REST and SignalR (for event publishing). I suspect a bunch of programmers out there probably just sat up in your chairs… REST? Yup, that means you have access to a full REST API, the same API our tools use to communicate with 3CX. I can hear cheers from all the programmers around the world saying “finally!”.

As with all big platform changes, there will be a period of “kicking the tires” to see how well the new Relay works in a broad release. While the technologies employed by the new Relay are not all that new (based on technology timelines), Microsoft only released SignalR as a native part of .Net Core last September. This was the one missing piece we needed to dive in and build the new Relay.

I’m personally very involved in writing code for the new Relay. It’s been one of those projects that really makes one stretch since so much of what is required is new to me — supporting Linux, building cross-platform solutions, and rearchitecting a very complex platform to support new technologies. It’s fun, for sure, and I’m excited to see my code running on servers around the world, but it has been a ton of work.

Your last question is probably “when can I get my hands on the new Relay?”. The answer is now! While the new Relay is in beta, we will work closely with you to get it installed. No doubt we will see many new platforms (AWS, Lightsail, Google, Azure, OVH and private hosting platforms) and we need more experience “helping you” implement our softwre on platforms that may be new to you. There are a large number of 3CX Partners who install 3CX on Linux using 3CX’s Express setup, and they have little or no experience managing Linux directly. Not-to-worry, we will help you implement our technologies on your platform of choice. You don’t need to be a Linux Guru to install our tools because we are here to help!

We still have a huge amount of work to do to fully support 3CX V16 and Linux but we are releasing pieces on a regular basis. You can see what’s available now by browsing to “Products –> Product Downloads” on our website. It’s a little sparse at the moment, but keep watch because you will see new things popping up on a regular basis starting now. By the way, we are quietly releasing four new products today — 3CX Auto Logout, 3CX Do-Not-Call, 3CX Active Directory Sync, and 3CX Recording Beep. So hang on tight, because things are changing pretty quickly!



When we started building tools for 3CX we were strongly urged by 3CX to focus on and build CRM plugins, which we did with considerable investment in both dollars and effort. Our CRM Plugins to this day far exceed the capabilities of the 3CX provided plugins. However, it’s clear that in spite of what 3CX is saying publically, 3CX Phone for Windows (and the associated plugins) is going to go away. And that means our CRM Plugins will no longer be useful.

I believe 3CX Phone for Windows will slowly fade away because 3CX has publically announced that no further development will be made to the product. This became abundantly clear recently when I saw questions on the 3CX forums about missing features in the latest release of 3CX Phone. The response from 3CX was that they had made changes to 3CX that were incompatible with 3CX Phone for Windows and that this necessitated the removal of the feature from 3CX Phone.

Further, 3CX has for some time been pushing people to start migrating to the web client, and they have publicly stated that all future development will be for the web client. The inclusion of a web-based phone into the web client pretty much sealed the fate of 3CX Phone in my mind. Also, we are told that V16 web client will have all the capabilities of the 3CX Phone for Windows plugins (and more!).

All these enhancements to the web client are good news for 3CX users, but bad news for the future of 3CX Phone for Windows (and MAC) and the associated plugins. It makes complete sense for 3CX to take this approach. Now rather than having to support a Windows, MAC, and Web client, 3CX can consolidate their efforts on one platform (the web) and even expand the supported platforms to include Linux clients, after all, web browsers are available on just about every conceivable platform.

The direction is clear. 3CX has pulled their own 3CX Phone For Windows plugins from their website and publically stated that they are no longer supported. As a result of this shift in focus away from 3CX Phone for Windows we have decided to End-of-life our CRM plugins and have removed them from our website as well. This includes our plugins for AutoTask, ConnectWise, and Zendesk. We will continue to support our Hubspot plugin for now simply because we use Hubspot internally and we need it for our internal purposes.

I’m a little uncomfortable about retiring several very useful tools. In the 10+ years we have been building tools for 3CX we have never dropped support for any of our tools, but I don’t think it is in our customers’ best interest for us to continue to sell and promote products for a platform that clearly is going away. I am sure that our efforts can be better spent keeping up with the changes to 3CX and ensuring compatibility with their ever-changing products. Frankly, it was a lot of work building and maintaining CRM plugins since the CRM companies are also making regular changes to their platforms and APIs.

When 3CX releases more information about the V16 integration capabilities for the web client, we will eagerly look at how we can add value to the 3CX community through custom CRM integrations, but for now we don’t have any plans to create new commercial CRM integrations as part of our Universal suite of tools. I’m not happy about the change, but we have to evolve as 3CX evolves their platform and unfortunately, 3CX Phone for Windows is going away and so too are our plugins for that platform.

We are committed to supporting all our tools for the long run. 10 years is a pretty good track record in my opinion. I’m excited to see how we can add value to the 3CX community when V16 is released. I’ll watch closely at what’s new for the web client and look for opportunities for us to add value. That’s our whole purpose for existing as a company.


I received some really good news today from 3CX. Initially when 3CX V16 was first announced we were told the Call Flow Designer (CFD) would no longer be included. In its place, we would write code using some type of scripting language… no more CFD. A month or so later we were told that the CFD would be released for V16 around the Service Pack 1 timeframe (That’s still the estimated release timeframe), but that significant changes would be required. Here is the good news we received today from 3CX:


From the tests we have been doing, the migration to v16 should be straightforward. Just open the CFD v15.5 project, build it, and you should be ready to upload the output to 3CX, no changes required… To be honest, we had to add that warning (changes would be required) because we can’t be 100% sure that we’re backward compatible, especially when you use the Call Control API, as there are some breaking changes there (deprecated methods). But all the projects we had from v15.5 work without changes in v16. So, don’t worry, everything will go smoothly.


The last time 3CX retooled the Voice Application Designer (VAD) and renamed it the Call Flow Designer, it required a total rewrite of all our VAD applications and a complete retooling of our application publishing process. It took about 6 months to retool and convert all our applications at an estimated cost of around $100,000.00. This latest news from 3CX has given me hope that the transition, while delayed until SP1, will be less painful than I had envisioned.

We do know, for sure, that the CFD applications will no longer be associated with Queues, rather, they will be their own object type separate from any dependency on queues (or previously digital receptionists). That is going to have an impact on our current CFD publishing process but sounds a whole lot better than what we were initially told. There will certainly be changes required, but I’m hopeful that we can make the transition quickly… although we don’t know what we don’t know.

The reason for the delayed release of the CFD was explained by 3CX as follows:


Actually, the bottleneck is not in the CFD tool. In fact, it is almost ready… But the server team still needs to work on the service that will execute the scripts generated by the CFD (or the scripts that you can create manually yourself). So, as soon as the server is ready, we will be able to release the CFD…


For those fretting over the fact that the new CFD won’t be released until around SP1, I submit this is not a big deal. I typically don’t recommend implementing a new version of 3CX until around the SP3 timeframe anyway to ensure the kinks are all worked out and all the previous version features are included in the new release. But my recommendations fluctuate from one 3CX release to the next. Still, waiting for a SP1 release before implementing a new version of 3CX is a good idea and strongly encouraged by me.


Yesterday we had our first Alpha install of our new Linux relay at a customer site. I was pretty pleased with the results because the Relay worked flawlessly.

Our new Linux Relay is written in C# (.Net Core — same as 3CX).  It doesn’t require any special SDKs or .Net installs because our Relay is “self-contained” (for those of you who know what that means in the .Net Core world).  Essentially, you copy the files to your 3CX server (hosted or on-prem), set a couple of permissions, register the license key, and start the daemon (service).  With a little practice, I think you could probably perform the install in about 5 minutes.

Here is what we have ready so far:

Setup Tool:

The setup tool automates about 95% of the installation process including:

  • Sets Linux permissions
  • Registers the license key
  • Creates the Relay and Proxy services (daemons)
  • Sets the web bindings (URLs the Relay will respond to)
  • Opens firewall ports (if you are using IPTables)
  • Configures the database proxy.


The new Relay requires a license key.  Why?  Because we’ve baked into the Relay a REST API which enables developers to leverage our 10+ years of 3CX development experience to easily build their own solutions.  So, if you can call a REST-based API, you can now integrate your solutions with 3CX without needing to know the intricacies of the 3CX Call Control API.  This new API will replace our HTTP API and will have far, far, more methods because all our tools will use this new API. While the example screen capture below may look a little complicated, this is exactly what a programmer would expect to receive from an API (json object of a 3CX extension).

Database Proxy and 3CX Exporter

Previously you had to install our 3CX Exporter tool directly on the 3CX server.  That’s no longer required because we have included in the Relay installer an optional database proxy.  The proxy makes it possible for 3CX Exporter to run on a separate server (in the cloud or on-prem) and synchronize the data in the 3CX database with Microsoft SQL or MySQL.

We’ve been pounding away on adding support for Linux into our tools, and we’ve made some excellent progress.

Want to be a beta tester?

Let’s be honest, it’s a little early to call this a Beta, but the Relay has already proven to be very stable.    Still, if you would like to tinker with some of our early work, get in contact with our team +1 801-642-4655.  My support staff will likely complain a little about the added workload, but they better get used to it because the flood gates will be opening very soon.  While there is a ton of work left to do before we can even call this a beta, we are looking for people who are willing to tinker and offer suggestions.  If you would like to take a peek, I suggest you navigate to our website and select “Contact Us” and then “Waiting for Linux”.  Put in the notes that you are interested in beta testing, and also be sure to list which applications you want to see released with Linux compatibility first.  That will help us prioritize our work.

Tools you can Try NOW

This blog post will get out of date very quickly as we release more of our tools with Linux compatibility.Today, 3CX Caller ID, and 3CX Exporter are the first applications that can take advantage of the new Relay.  However, I’m traveling to India tomorrow and will be with our development team for the entire month of January.  The purpose of the visit is to train our team on how to work with 3CX running on Linux and to walk through converting ALL our applications over to the new Relay.  I expect you will see several more Linux compatible tools being released over the next couple of weeks.  As you might expect, we are going to start with some less-complex applications first, then move to some of the more complicated applications once the team is comfortable with the process.

User Guide

If you are a real nerd and want a peek at the User Guide, you can see it here. Keep in mind that this is a working document and will change frequently. It’s not been proofed either guys, so don’t be too critical.  If you have suggestions, feel free to make a comment.




3CX has effectively made it necessary for all 3CX customers to upgrade to 3CX 15.5 SP6. While it is “possible” to continue to run older versions of 3CX, the risk of doing so makes it infeasible for a production environment.

For those who have not heard, 3CX had to make changes to their activation servers (for security reasons). The changes mean that you can no longer activate 3CX servers older than V15.5 SP6. Because there are many common reasons why a 3CX server might need to reactivate, older versions of 3CX could fail unexpectedly. You really have no choice but to upgrade.

Since EVERYONE MUST upgrade to 3CX 15.5 SP6, and 3CX announced V16 yesterday, we have decided to drop further development for older versions of 3CX. While our tools will continue to work on older versions of 3CX, we will not be releasing any updates for versions older than 15.5. This is the first time we have stopped supporting older versions of 3CX (we still have products available for download for V10).

Pragmatically, this change in our support policy will probably not impact any of our customers since we have not seen an activation on an older 3CX server in a long time. Regardless, here at VoIPTools are committed to supporting all our customers, and providing regular updates to all our products.


We were asked by a call center customer if Recording Manager could be configured to only record inbound external calls.  The answer now is “yes”.  While 3CX may still record all the calls, behind the scenes, Recording Manager can delete any recordings made of calls that are not inbound external calls.

In large 3CX deployments, storage can quickly be consumed by recordings.  This feature deletes unwanted recordings in real-time.  This is different from a retention policy that deletes ALL recordings older than a specified date.  With this feature, Recording Manager only deletes recordings that are internal or outbound external calls.

3CX really only provides two choices when it comes to Recording calls: (1) all calls for an extension, or (2) on-demand manual recordings. This new feature offers additional flexibility for deciding what recordings are important, and because the removal of unwanted recordings happens in real-time, disk utilization is minimized.


It’s no longer a all-or-nothing choice!

The cost of transcribing voicemails is very reasonable.  Even so, in very large organizations a tiny cost can add up over time.  Having the ability to choose which extensions are transcribed is an important feature.  Perhaps you only want to transcribe the CEO’s or selected managers’ voicemails.  The latest release of Voicemail Manager allows you to selectively choose which extensions are transcribed.  It’s no longer an all-or-nothing choice!



Leader Board

In the coming days, we will be releasing an update to our existing wallboard to include some additional views.  Our original wallboard view is a “Leader Board” that displays agent activity with the most productive agents listed at the top of the list while less productive agents fall toward the bottom.  It’s a great tool for motivating staff to be productive by introducing some gamification elements to the work environment while allowing managers to easily monitor performance.

Unlike the 3CX Wallboard, our leaderboard wallboard monitors both inbound and outbound calls, whether the calls come to the agent through a queue or direct calls to/from the extension.  This wallboard monitors all external calls, not just queue calls.


New Features:

We have added some new columns to the Leader Board.  We now show the current 3CX presence setting (Available, Away, DND, etc.) and a timer that shows how long the agent has been in the current status.  These columns update in real-time.  I anticipate we will release a new report that shows how long agents were in each status.



New Queue Views

3CX has a great built-in wallboard, but it has one limitation — you can only see one queue at a time.  We are adding two new views to our wallboard to display multiple queues.  These views display typical queue statistics, but I would like to point out one column in particular.  “Available Agents” displays the count of agents who are logged into the queue and available.  This data is obtained using our new Windows/Linux Relay.


Multi-Queue View

Simple Multi-Queue View

Linux Relay Development


Sometimes progress seems to happen at a snail’s pace, and at other times progress is breathtaking. Our Linux development efforts started out slow, but recently the pace has quickened and I’m truly excited to watch our progress unfold. Hang on, things are about to get a little crazy at VoIPTools (if it hasn’t already been crazy here for the last year or more).

As one of the lead programmers here at VoIPTools (yes, I still have my pet projects), I’ve had to retool my skills honed over the last 37 years to get up to speed developing for Linux. On one hand, the code has been pathetically simple, and on the other hand, I’ve never felt more like a fish out of water.

Going back many decades I was once a Unix administrator for a large government entity. So you would think it wouldn’t be such a challenge for a Windows guy to get back up to speed again on Linux. Well, that old experience has come in handy, but what do they say about all dogs learning new tricks? It’s been a challenge at times.

I’ve been so close to completing the technical aspects of our new Relay that this 3-day holiday weekend I decided to pound through the remaining issues and get it done. Happily, I completed the last really hard technical issue on Monday. Yeah, that’s what nerds do when they have a 3-day holiday — play!

The real bug-a-boos for me have been (1) making the Linux install easy for people who know nothing about Linux, (2) make the event broadcast/subscription pattern easy for our development team, and (3) getting one codebase to work seamlessly on both Windows and Linux. The last one (#3) was the last hurdle to overcome. You could probably hear me cheer when I got our Relay to run both on Linux (as a daemon) and Windows (as a service) with the same code. It was epic (from my perspective).

So, as with any new release of a technically challenging product that is core to our entire business, we have to take baby steps as we look at releasing tools that utilize the new Relay. Next week we install our first custom product using the Relay. We still have optimizations to perform, and certainly some refactoring, but you can’t imagine how excited I am to have the core of the freaking Linux Relay ready to turn over to the full development team.

For you fellow geeks that care about some of the guts, here is a peek into what’s different about the old and new Relays. The original Relay was written with WCF at the core (pardon the pun). This was an awesome architectural decision. It has been rock-solid from day-1. But… the security restrictions imposed by WCF proved to be a real challenge to configure in some environments (ok, many). With 3CX in the cloud and VoIPTools on-prem (as one example) getting everyone to play nice could be a challenge.



The industry has changed since we first architected the Relay. We have all moved from SOAP to REST and that’s what’s primarily different about the new Relay… it’s based on REST. I can hear the gears turning in your head. That’s right, REST. So, you are wondering… will there be a new REST API? The answer is YES! And this will not be a little API, this will be a HUGE all-inclusive API, and YES we plan to make it public. Do you hear the cheers from all the programmers around the world? Yup, I heard it too.

But REST doesn’t do event broadcasts, what about that? That’s been handled by SignalR and Websockets. If you could see the amount of code that has been ripped out of the Relay and the huge simplifications to the remaining code, you would be cheering too. The Relay used to be one of those applications that everyone (including me) hated to touch out of fear of breaking something. Now with the new REST API, the patterns are so easy to follow that even junior programmers at VoIPTools will be able to make changes. You just can’t imagine what this means to future development at VoIPTools. THIS IS HUGE.

Now I’m the first to admit that I get a little excited by new releases, and I have to back peddle a little and be a little more forthcoming about where we are with the new Relay and what that means to the release of Linux compatible versions of our commercial tools. We still have a ton of work to do on the Relay to make it “production ready”. If you twist my arm, I would say maybe a month or a little more to get it ready for prime-time. But that’s only part of the story. As a very brief retelling of how our tools work with 3CX — let’s review… Our products (Recording Manager, On-Call Manager, Emergency Notifier, etc.) don’t talk directly to 3CX, they talk to the Relay and the Relay talks to 3CX. That happens in both directions. I’ll not detail the “why” here, but trust me, the Relay was probably the single best decision we ever made at VoIPTools. So when we replace the Relay, we have to make some changes to our applications, right? Yes, that’s true. But I’ve gone to great lengths to minimize the necessary code changes. For example, the old Relay command for MakeCall was VoIPToys.RelayServices.MakeCall. The same command for the new Relay is VoIPTools.RelayServices.MakeCall. As you can see, that’s a pretty minor change.

There will be other changes necessary. For example, Recording Manager accesses 3CX recordings via a Windows shared folder. Obviously, that’s specific to the Windows platform. Sure, I could do the same thing with Samba, but rather than add that complexity, we now expose the recordings through the Relay. Therefore, gone are all the hassles of setting up shared folders and the necessary cross-domain security challenges that come with that technology. The Relay runs on the 3CX server and the recordings are on the 3CX server, so security becomes pathetically simple. And I have a ton of code we can strip out of all our applications that were required for setting up security and authorization. Now I hear all our customers cheering!


What’s Next?

Initially, only the Relay will be Linux compatible. Our applications will still run on Windows. Eventually, it seems likely we will port all of our tools over to “Core” so they can run on both Windows and Linux, but that’s down the road a little farther. Baby steps right?

We have so many initiatives I would love to pursue/complete (our cloud platform for example), but the Linux market has blown up over the last 2 years and I had to make a choice. It seemed logical that we focus on the Linux Relay first since that’s going to be needed to fully embrace our cloud initiative. Once we have all our tools working with the Linux Relay, I’ll pause, take a breath, then decide what the next big thing is at VoIPTools.


Keeping track of phone calls in the 3CX Call Control API is a messy business. It’s been particularly challenging getting our dialer to work in all environments. One of the challenges was making outbound calls, getting the resulting unique 3CX call ID, playing the correct prompt, and then transferring the call. The complexity of this process was compounded by the need to control the outbound caller ID, and handling the prepending and stripping of digits along the way. Mucking with the phone number in outbound rules was just one of many headaches that came along.

Happily, we have added a new feature to our dialer that allows you to prepend digits to the phone number prior to dialing so you can force the call out a particular trunk (to control the outbound caller ID). We also now support stripping those extra digits too. Adding and stripping digits was really messing with our ability to track the right call through the process, but it’s now fully supported in our latest release.


Get the Best Solution for your Business

Whether through one of our commercial products, or a custom solution built to meet your specific needs, we can help you get the most out of your 3CX investment. Call us today!

Contact Us