In the previous three “Envoy® Updates” articles covering the Envoy® Soft Phone (ESP) we looked into performance advantages ( Building a “Better” Soft Phone, Part One ), efficient business use case adaptation ( Building a “Better” Soft Phone, Part Two ) and the slick user interface features ( Building a “Better” Soft Phone, Part Three ). In this article we will have a look at some of the more advanced features that ESP has to offer.
Application Programming Interface (API) – ESP is built on top of the Envoy® Client program which exposes methods to send / receive XML messages. It is really that simple – all the powerful event driven features and call control functionality are accomplished using a very simple, standards based, easy to read message set built purely upon XML. VEXIS “ate our own cooking” by using our client side API to build our soft phone – no proprietary technology hidden under the covers. So we know the API can be trusted to drive a demanding call center application, but how easy is it to use? Well, the nice thing about the API of the Envoy® Client program is that it is exposed as a C/C++, COM, and .NET API. By having all these various interfaces, the API can be called from virtually any programming language such as the latest .NET (C#, VB.NET, ASP.NET) technologies to low level C code and even legacy Visual Basic applications – allowing your developers to use the programming language with which they are most comfortable. There is even a special version of the API used to allow enterprise class applications, such as an Interactive Voice Response (IVR) system to make use of the client in a network optimized manner. In other words, the user interface of ESP (although we really like it) is optional – if you prefer to have all the same powerful technology in your own application specific in your environment, use the API that is freely distributable throughout your enterprise. You can read more about the API here: Envoy® Client Software Development Kit (SDK).
Technology Abstraction – ESP communicates with Envoy® Server which in turn communicates with backend systems. The great thing about Envoy® Server is that it is a highly scalable, powerful message routing engine that manages resources and operates within a “push” model. Basically, this means it can support a large number of heterogeneous clients in a very efficient (event driven) network traffic mode of operation. Yes, different clients with different message framing can communicate with Envoy® Server simultaneously, even accessing the same (or different) backend systems. Envoy® Server can be instructed to do whatever you need it to do for your enterprise applications because Envoy® Server is a plugin framework. If you need Envoy® Server to communicate with Cisco ICM or Genesys T-Server, there are plugins already written for those tasks; if you need it to communicate with IBM WebSphere MQ, use that plugin which is also available, as are many other standard plugins. Use plugins in any combination; allow your client applications to access multiple backend systems all through the same one “friendly” XML based message API. Going back to ESP, the real advantage is that it uses the abstraction layer and resource management capabilities of Envoy® Server – so ESP can communicate with an Avaya switch through an AES Server or Nortel switch via a Symposium server – or both at the same time. ESP will issue call control commands and Envoy® Server will route the messages to the proper technology plugin needed to execute the issued operation. A plugin can do anything from aggregating data from multiple backend systems to monitoring enterprise applications, to communicating with distributed telephony resources – and if you cannot find a standard plugin that does what you want it to do, leverage the powerful Envoy® Server plugin architecture and write your own plugin in your favorite programming language! You can read more about Envoy® Server here: Envoy® Server Multi-Client Endpoints, Envoy® Server Resource Management, and The Power of Envoy® Server, the Dexterity of .NET.
Desktop Application Integration – ESP is an event driven application. What does that mean? It means that ESP does not “poll” (keep asking) the Envoy® Server if there is anything new it needs to know about but instead is notified when things it is interested in knowing occurs. Consider a call center that has 500 agent desktops – each one running a softphone application. In a “pull” model each desktop would ask (poll) the server “is there a telephony event for me”? The server would have to reply to each desktop application – with 500 hundred replies – and maybe only half of those desktops have an actual event they need to be notified of from the server. To make matters worse, the “poll interval” – how often the clients ask for “anything new” – could be configured such that it occurs every second, or even more frequently. This “pull” model makes the server work hard and the network full of unnecessary traffic. With the “push” model, the clients tell the server to send events to them only when they occur and then the clients do not bother the server again; the server notifies the client when the specific event they want to know about happens. This model is more efficient because the server only sends messages when they are necessary and network traffic is considerably less “chatty”. The Envoy® Server even takes this “push” model a step further by allowing different clients to not only “subscribe” to specific events but also to dynamically “filter” the events in which they are interested in at any time – and Envoy® Server is aware of those additional events that now need no processing so effectively become “no ops” (operations that do not need to be carried out). Going back to ESP – this “push” model allows the ESP user interface to dynamically update based upon events that occur (event driven) on the telephony switch. An example might be where an incoming call event would be notified back to the specific ESP application (running on proper agent desktop for that extension) and thus tell the user interface to show a flashing (“ringing”) notification. This event driven architecture is leveraged a great deal by ESP because ESP can consume these events but can also pass them along (in addition to other call related data) to other applications running on the agent desktop. Imagine tying in legacy code running on the desktop such that it can react to / process events occurring on backend systems! Legacy applications that were previously only usable as a manual human interface (passive) application can now be enabled to play a much more proactive role on the desktop – this is where ESP shines as a conduit for desktop application integration based upon events from backend systems.
Goal Tracking – As a teaser, consider that ESP communicates with Envoy® Server and that one of the plugins available among standard plugins is the Envoy® Reporting plugin (soon to be featured in an upcoming article). This plugin consumes the same friendly XML messages that all the plugins use – so perhaps ESP (or your own client that uses the client side API) wants to incorporate goal tracking – the infrastructure is all in place today – using the Envoy® Framework components (client, server, and plugins are known as the Envoy® Framework). Is this cool or what?! Just as other enterprise applications can track business level effectiveness through goal tracking (attempts, successes, failures) your client side application – the softphone itself – could start tracking configured goals.
There are still many more advanced features of ESP not listed here that your enterprise can put to use immediately; make sure and check out some of the related articles. Hang on to your seats for the next VEXIS Voice “Envoy® Updates” article!
Richard Wolff, Director of Software R&D