Cisco BroadWorks little compendium.

Let’s start with a brief introduction to outline the landscape we are talking about. Cisco BroadWorks is the leading cloud calling solution provided by Cisco. Yet, initially, it was part of the BroadSoft portfolio. When first launched, it was almost revolutionary. It provided a centralized, integrated, and scalable calling solution designed to operate over-the-top (OTT). Moreover, it was specifically targeted to carriers and service providers. Configuration, operation, and management was a carrier responsibility. Service providers could then offer the service to final users in a public multi-tenant approach. All the customer needed was a simple internet connection!

It was the perfect solution for small to medium businesses, up to a few hundreds of users. In fact, they could not afford the burden of a complex, classic, on-premise calling solution. And, on the other hand, they were not even interested in advanced features provided by advanced calling solutions. With no surprise, BroadSoft quickly won the small and medium business market. It made such a huge impact that BroadSoft started looking out to offer its solution on its own. A public multi-tenant native could version of BroadWorks: BroadCloud. The BroadSoft answer to the emerging cloud transition.

As of 2018, BroadWorks partnered with more than 600 service providers in 80 countries, including most tier 1 carriers. With over 26 million users and almost 50 % market share, it was (and still is) the leading cloud calling solution. This was when Cisco decided to acquire BroadSoft. It was a strategic and intelligent move. Cisco needed a solution for small to medium businesses and was just entering the cloud world. With the acquisition, it completed his portfolio. BroadWorks became Cisco BroadWorks. The newborn BroadCloud, instead, evolved to become what is now known as Webex Calling.

What about Imagicle?

Ok then, BroadWorks is a great deal. What about us? Up to the Spring Release 2020, the Imagicle UCX Suite integration with BroadWorks was limited to the Call Recording, Digital Fax, and Call Analytics applications. However, we knew that there was much more we could do. BroadWorks was a great calling platform, but it was missing key complementary features that we could provide. Primarily a feature-rich Attendant Console. In other words, it was missing an integrated suite of UC applications.
The problem was that the Suite was using standard telephony protocols, while BroadWorks, being cloud-oriented, was talking an entirely different language, the shared language of the web, HTTP.
The only way to have our UCX Suite running on BroadWorks was by using a dedicated third-party TAPI driver. However, commercial drivers of this kind posed major issues in terms of multi-tenancy management and performance. This was, for example, the case for the Attendant Console.

This is why at the beginning of this (weird) 2020, we decided it was about time to do something great. Something that could really bring the Imagicle experience to the BroadWorks community. Something Imagicle.

Basic call functionalities: Imagicle native connector.

After the Spring release, we started designing our native connector to BroadWorks. A brand new Imagicle native XSI connector, not the usual development. We had just released many heavyweight advances, but it was not the time to sit back. When we first started scouting the product and thinking about issues and solutions, we were quite excited.

Initially, we focused on call monitoring. We wanted to be able to see live BroadWorks calls within our Attendant Console. It could look easy, but this meant integrating a brand-new technology in the Suite: XSI. The Extended Service Interface (XSI) is a huge set of HTTP rest API exposed by BroadWorks to do a variety of things. They are divided into two major groups: actions and events. The first set exposes control APIs used to act on different things. From server configuration to call management, these APIs can do pretty much everything. While the second provides a hook to establish a communication channel with the server and receive live events. A good and old set of HTTP REST API to be merged in a TAPI oriented design.
It was tough, but in a few sprints, we managed to have the first version of our XSI client. We established an event channel with a single XSI server and retrieved call information of a given set of users. We could basically see a BroadWorks call from our console. It was a heartwarming moment. And it was just the very beginning of our journey.

The second goal was to provide basic call control functionalities. We wanted to make, answer, and drop calls on our own from the Attendant Console. It was the turn of XSI actions integration. After a couple of sprints, we were able to control a BroadWorks softphone through our console and see real-time call updates without changing the Attendant Console itself. Cool huh?

What was missing? Well, a whole lot of things.

Advanced features: call park and XSI cluster support.

In the following months, we worked to strengthen our solution by adding other features, like the possibility to switch between users‘ scopes: enterprise, group, or custom directory. This means we can now monitor and control users belonging to a given enterprise, group, or custom directory. Another cool improvement was supporting overlapping dial plan scenarios. This was important since BroadWorks installations are most likely to request this kind of support. Finally, we added two key features: multiple XSI connections support and connection resilience. From that moment, you could set up more connections to different XSI servers, all working simultaneously. The last feature, i.e., connection resilience, was particularly challenging. We had to put in place a re-connection mechanism tailored to the XSI event channel specifications. A vital feature to minimize the downtime if an event channel connection was to be lost! By the way, we also added functionalities to other UCX Suite applications, like the Advanced Queueing, which was evolved to support SIP URI addresses, as requested by BroadWorks.

All these features were already included in the Summer Release 2020, adding basic support to BroadWorks via a native XSI connector. Yet, we felt that some key features were still missing to give BroadWorks users the complete Imagicle experience: call park and XSI cluster support. These have been the main goal for the forthcoming 2021 Winter Release.

Call park.

The call park functionality was left aside in the first moment because of the differences concerning the CUCM world. In BroadWorks, each user has a single associated park line, which can be used to park a single call at a time. This is quite limiting. To overcome this limitation, BroadWorks offers a feature called Group Call Park (GCP). Enabling this feature allows defining a set of users (within a BroadWorks group) to share their park lines. This increases the total number of parkable calls within a GCP to the number of users belonging to the park group.
The question was, which feature should we support? Well, why not both of them? Initially, we targeted the GCP feature alone. It seemed the most powerful choice and it was natively multi-tenant. However, during the development, we figured out that the best thing to do was to support both. And boy, we did it!

The Winter Release 2021 will offer complete call park integration from the Attendant Console. GCP users will be able to park and retrieve calls from any user belonging to their park group. On the other hand, for simple users, the UC suite will automatically revert to a simple call park.

A maximum flexibility solution that finds no match in other commercial applications.

XSI cluster support.

The other major topic for the winter release was adding support to XSI clusters.
BroadWorks installations typically consist of a cluster of servers in high availability configuration. To adapt to this scenario, we had to introduce a fail-over mechanism. Starting from Winter 2021, you will be able to configure a list of endpoints for every XSI connection. This list will be interpreted as an ordered ring. Every time connection is lost with one server, the Suite will try to connect to the following one, with no service restart required. This minimizes downtime and ensures a prompt reaction to connection issues.
BroadWorks connections can be managed through a set of provided REST APIs for integration with third-party provisioning systems.

What’s next?

Wow. We went through a lot and were able to achieve a solid result. During these 6 months, we managed to build a native solution for Cisco BroadWorks from scratch.
The most advanced Attendant Console and Customer Service solution for Broadworks, being able to work seamlessly with Cisco UC Manager and Broadworks for a seamless customer experience.

What about the future? We have come a long way, and we won’t certainly stop now.
Having a native integration under our complete control will open to a new set of possibilities that would have been a no-go if we had to rely on a third-party TAPI driver. Has anyone said native BroadWorks Call Center integration?  And let’s not forget about Cisco Webex Calling. We believe that the work carried out will be the foundation of future native integration with Cisco Webex Calling.

Stay tuned!