Zang from the Inside Out
Zang is clearly after the enterprises looking to extend their on-premises systems to new apps, solutions, and workflows.
When I was a kid growing up in the 60s, the big question of the day was "Mary Ann or Ginger?" Being the fairly wholesome, innocent child that I was, my answer was always the same -- Mary Ann. Ginger certainly had her appeal (which grew as I got older), but Mary Ann was the one you knew you could count on till death do us part. She was sweet, kindhearted, and in the eyes of a young boy inexperienced in the ways of the world, the safe choice. Ginger, on the other hand, had eye appeal and a slightly frightening allure, but would she stick around after the novelty wore off? In my case, definitely not.
Here in the world of communications, we are in the midst of a similarly heated discussion -- specifically, premises or cloud. Like the Mary Ann vs. Ginger debate, it often comes down to the choice between tried and true and the allure of something new and exciting. We know exactly what we will get (and have been getting) with on-premises, but the case for cloud can be very enticing – albeit as frightening as Ginger was to that ten-year-old Andrew.
However, unlike Gilligan's Island, there is another architectural choice, and many enterprises are looking at a hybrid approach for their next-generation communications platform. They want to take the best of both worlds and munge them together into something that makes users, customers, IT directors, C levels, and bean counters happy. They want to take advantage of the cost savings and scalability of cloud, but they don't want to do so at the expense of flexibility and the customization that their businesses often demand. The intellectual property that is an enterprise's workflow doesn't always translate into a one-size-fits-all cloud solution.Bing, Bang, Zang
Like many of you, I first became aware of Zang during Avaya's keynote at Enterprise Connect 2016. Although I wasn't exactly sure what I was hearing, it sounded significant enough for me to spend some time at the Avaya booth learning more about what Zang was and perhaps more importantly, what it wanted to become. While that was a good first look, I was hungry for more, so I dug around their webpage to get a better understanding of this platform as a service (PaaS) offering. That led to seeking out No Jitter articles such as Avaya Steps Up its Platform Game and The Yin and Yang of Avaya and Zang. Eventually, I felt armed with enough information to take it one step further. I wanted to write code that allowed me to explore Zang from the standpoint of an enterprise ready to dip its toes into the communications cloud while keeping a good part of its body on dry land.
I began my Zang programming adventure by signing up for a trial account, which allowed me to play with the entire API set from either a hard client application (e.g. Java code that I would write) or a Web browser capable of sending and receiving RESTful Web services GETs and POSTs. In order to get the biggest bang for my buck, I chose to do both. I added code to the Avaya Snap-In I wrote about in My Life as an Avaya Boot Camp Recruit and installed the free RESTClient add-on to Firefox. Optionally, developers can use the API Explorer that Zang created.The Faces of Zang
Before I go too much further, I need to explain the different interfaces that Zang exposes. First, there is a RESTful command interface that allows a developer to send Web services messages that instruct Zang to do something useful. Using RESTClient, I established an authenticated connection to Zang that allowed me to do everything from send an SMS message to query the usage of my registered telephone numbers.
For example, to query my telephone number usage, I issue the following command. (Note that ACbf8890843add436c6fea470ebd718a64 is my Zang account identifier.)
Zang responds with a list of data items such as the number of inbound calls, outbound calls, SMS messages, Carrier/CNAM lookups, etc.
To retrieve general information about my account, I issue this command:
Zang responds with my balance (money I can use to make calls, send texts, etc.), configured time zone, maximum outbound limit, and other account related items.
APIs supported by the command interface allow an application to make calls, send digits, play audio, record calls, control conference calls, send SMS text messages, perform carrier lookups, block destinations, create whitelists, and a host of other call and account management functions.
The next interface allows an external applications server to receive asynchronous XML requests from Zang. For this, I used the Breeze Snap-in I created in my boot camp to accept and process the messages Zang generated each time someone called one of my registered telephone numbers.
I registered the RESTful interface of my Snap-In using the Zang number management webpage shown above. This allowed it to act as an applications server for all inbound calls. At that point, the following workflow was implemented:
- Zang sends the Snap-In a message when one of my numbers is called
- The Snap-In responds with an XML message that instructs Zang to play a prompt and collect a digit
- Zang plays the prompt and collects the digit
- Zang sends the Snap-In a message containing the digit
- The Snap-In responds with an XML message that instructs Zang where to route the call
Pictorially, the workflow looks something like this:
Like the RESTful command interface, this Inbound XML interface is feature rich. Besides playing prompts and collecting digits, an application can do things such as release calls, reject calls, redirect calls, connect to conference rooms, and process SMS text messages. For example, it's possible to write a chatbot that accepts incoming SMS text messages and programmatically responds to the sender.
It's important to know that all a Zang application ever sees is signaling to and from the Zang cloud. Media is completely managed by Zang, and although an application is aware that a call exists, it never comes in contact with the actual voice stream or streams. This allows for on-premises solutions to be highly scalable without the need for specialized hardware (e.g. DSPs) or excessive processor demands.
The one exception, of course, is SMS text where a Zang application is fully aware of inbound and outbound text. By its very nature, though, SMS is not as processor demanding as real-time voice.Mischief Managed
While other vendors are presenting themselves as a one-stop-shop, all-in-one PBX in the cloud, Zang is clearly after the enterprises that are not displeased with their on-premises system, but feel the need to extend it with new applications, solutions, and workflows. They may have everything they need in the way of voice, but want to extend their reach into text. They might be interested in adding voice response functionality without the expense of a dedicated IVR. They might be people like me who come up with clever ideas and want a communications platform on which to build them. That's what platform as a service is all about, and that's the sandbox Zang is fully equipped to play in. In other words, it's the security of Mary Ann blended with the spiciness of Ginger for something altogether new and different.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.