Multithreading in IVR Development

By Fouad Jennawi, Senior Software Engineer, Pronexus

Multithreading is one of the very interesting subjects of programming; end users know it as the reason that keeps their computers highly responsive, and developers use it as one of the techniques to improve the performance of the products that they are developing.

Pronexus VBVoice™ Interactive Voice Response (IVR) software is multi-threaded by design. It separates, on one hand, processing channels from each other and, on the other hand, from the application code. However, the IVR application code is usually done on one thread; the thread that instantiated the VBVoice controls which is called the main thread. This same thread also instantiates and handles the GUI (Graphical User Interface) code.

As application developers started doing more asynchronous coding using multithreading, Pronexus was asked to simplify this process. This is when the WorkerThread control was added to the VBVoice’s collection of controls. WorkerThread not only offers management of a pool of user threads but it also synchronizes them with both the main thread (the thread that all application code is executing) and the particular channel thread.

Simplicity is the key here; the IVR solution developer wraps his code to be executed in a worker thread in a class that implements IVBVRunnable interface. During a call, in the WorkerThread Enter event, the application creates an object that contains the set of parameters to be passed to the worker thread and an instance of wrapper class. VBVoice will kick in the worker thread with the custom code while playing music to the caller and listening to actions, such as hanging up or keying in digits. Later, when the custom code is done, the control exits by firing its Exit event and providing any results from the worker thread plus some useful flags.

The key benefits of the WorkerThread control are:

  1. IVR developers don't need to have extensive knowledge of multithreading programming and sophisticated thread synchronization which can get tricky.
  2. WorkerThread suggests the recommended way of writing custom thread code which saves time.
  3. It offers the best synchronization to telephony functionality.
  4. It simplifies debugging, as you only have to set the WorkerThread timeout to a high value and put a break point in your custom code.
  5. It is extensible, as application developers can add more threads if they need to and implement other ways of synchronization to the worker thread as well as the main thread.
Multithreading in IVR Development

4 Responses to “Multithreading in IVR Development”

  1. Sean says:
    October 28, 2010 at 1:17 pm

    In my experience, IVR programmers should consider multithreading for example for any applications which will do database lookups. In particular with high-density IVR systems, channel stability can be impacted by blocking the main thread. In a telephony platform, milliseconds count, and delays on the main thread cause instability. A multithread approach in application design will ensure you have the foundation of a robust IVR.

  2. KO says:
    October 28, 2010 at 2:34 pm

    There is a case study that talks to some of the benefits that you mention. Check out http://tinyurl.com/callcenter-casestudy. To give you an idea, a large call center was able to reduce code lines (and therefore time and costs) by 50% using multithreading to develop their dialer application.

  3. Sunny says:
    May 9, 2011 at 2:37 am

    Sir
    I need some help regarding to GSM modem voice call.

    My Scenario:

    i have an Excel Spreadsheet ( or a database ) which contain Five Thousand (5000) Phone numbers.Now i want to select a phone number call him and play a Pre Recorded Voice Message(Mp3, or an audio file) rather than live call by on operator.i.e audio streaming on outgoing call and then call another next phone number.calls may be 10 phone numbers at a time.

    What i researched on Google etc or what is my proposed solution:

    A modem with voice and supporting AT Commands of voice i.e FCLASS=8,
    OR a modem with his own voice SDK (software development Kit) to develop a programe(software / dialer/ in C++ etc) for interacting voice call task with modem. but upto this time i failed to find such a GSM modem to work with my scenario.
    Please drop me a line if you have any modem or idea to to-do the same with another approach(may be openscource).

    Thanks
    Regards

  4. Sean says:
    May 9, 2011 at 12:52 pm

    Sunny,
    We would want to confirm if the customer is in fact looking to connect to a wireless/GSM protocol, or if they have the option to connect to analog or digital PSTN, or even a VoIP provider – in this scenario we integrate VBVoice with Dialogic media natively on the same server, and we can connect directly with these protocols from the provider, or through a PBX.

    If they must use the wiresless/GSM network to make calls, then they must implement a gateway device between the VBVoice/Dialogic IVR and the GSM network. The gateway will change the protocol from analog, digital PSTN, or VoIP (which we support) to GSM.

    We do not recommend any paricular make or model of gateway or PBX, just as long ag the protocol adheres to the respective protocol standards.

    I have attached a system topology which shows how we could expect such a system to be configured. See diagram: http://pronexus.com/wp-content/uploads/2011/05/systemlayoutvoip.jpg

Leave a Reply