Programmable Voice

  1. Home
  2. Docs
  3. Programmable Voice
  4. Introduction to Using Voice Elements
  5. Voice Elements From Birth to Production Maturity

Voice Elements From Birth to Production Maturity

I first envisioned the basic framework of Voice Elements in the fall of 2007. At that time, our rock solid CTI32 toolkit for telephony was in its heyday. CTI32 had, for a decade or more, been a platform of choice for many a .NET developer. The CTI32 toolkit, took away many of the mundane tasks that plagued any serious telephony development effort, such as opening boards and channels, managing conferences, and so on. Moreover, it handled all the variances of differing protocols, and service releases that could be thrown at it.

The Voice Elements framework sought to expand on this bedrock by bringing all of the CTI32 functionality into an object oriented design. This, of course, is what .NET is all about. In December of 2007, I made my pitch to Inventive’s President, Ron Tanner. As the presentation went on, I could sense that Ron was cautious and I thought that the new framework would be tabled for a later day. But in the end, I asked him for the funding to radically change what was our premiere platform.

Not less than a week later, I was buried in refining the design of the framework (which didn’t even have a name yet). I love base classes, derived classes, polymorphism and interfaces. As I saw it, here was the perfect opportunity to create something that had never been done in the telephony world.

For example, Analog lines, Digital lines, and SIP based lines each have their own distinctness, yet in the end, you want to dial out on one, or take a call on one. Thus was born the “ChannelResource” class that the base class for any kind of line. With an instance of a ChannelResource, methods common to all lines are available: Answer(), Dial(), Disconnect() and IsConnected() just to name a few. Additionally common properties are also at your fingertips: Ani, CallerId, CallerIdName, Dnis, VoiceResource, etc.

The power of using the ChannelResource during development is that regardless of the underlying system, be it HMP (SIP), a board connected to a PRI, or an Analog board connected to a POTS line, you can design code that will operate on all systems without having to make code changes as a punishment for changing platforms. As many of our customers can attest, moving from boarded solutions to SIP has been a snap since they have only had to make configuration changes and their code works on their legacy equipment as well as the latest in HMP technology. One layer deeper you find that ChannelResources have common ground with other classes such as VoiceResources, FaxResources and soon to be announced VideoResources. They can be routed together. Thus was born the RouteableResource, a base class that is common to the majority of classes in the framework. With this common class, routing is a snap with methods such as RouteFull(), RouteHalf(), StopListening() among others.

Simplicity is found in the base classes. While great care has been taken to generalize methods and properties of classes, rest assured, nothing has been lost and the real power is found in the derived classes. All of the unique attributes of each line type can be accessed from within their own class. For example, a PRI line can be issued a two “B” channel transfer, and an analog line has to gather the caller id information from tones that come between the first and second ring. T1 CAS circuits might need to wink before they can answer a call. ISDN circuits can have facility messages that need to be examined. SIP based calls have headers that need to be set, or retrieved. Codecs may need to be changed. All of these options and more are either exposed to the developer or handled internally so that highly specialized applications can be created with ease.

During the initial stages of development, another unique feature of Voice Elements evolved. By separating the application’s process from the server, the server maintains state and the application controls the server via a socket connection. This allows the application to be developed independently. This was further expanded in to what we now term a Voice Elements Telephony Bank. Server banks allow you to develop and test your applications without having to purchase any hardware. You can “kick the tires” and throw together a proof of concept at your desk, then connect your app to our server bank and have fully functional IVRs in minutes.

By providing both simplicity in design and high level power house classes, Voice Elements stands apart from any other development platform that I have seen. I hope that you feel the same way after you have had a chance to take Voice Elements for a spin around the block. In my next article, I look forward to talking about our companion product HMP Elements which, when combined with Voice Elements, becomes our flagship product the Voice Elements Platform.

Cheers for now,

Monroe Comstock

Senior Developer

Was this article helpful to you? Yes 15 No

How can we help?