Kevin Junghans

Caching the VoiceModel and state machine for an ASP.NET MVC VoiceXML application is very simple. In the previous post Where is the Controller For an MVC VoiceXML Application  I demonstrated how to create a voice application to get the current weather conditions in an area identified by a zip code.  In this post the VoiceModel and state machine were recreated each time the controller was called.  I have modified the example to cache this information by slightly modifying the Builder classes for the VoiceModel and state machine.  The Builder classes follow the Builder design pattern  and are responsible for building the object graphs that represent the application VoiceModel and call flow.  It makes sense to handle the caching in these classes since they are responsible for creating these objects.  Here is what the class for the state machine builder looks like now. public class WeatherCallFlowBuilder { const string cacheId = "weather.cf"; public static ICallFlow B

This post discusses some of the design decisions used for developing VoiceModel , an open source project for creating a framework that simplifies developing VoiceXML applications using Microsoft ASP.NET MVC and Visual Studio. Developing voice/speech applications using VoiceXML has made development of IVR applications more like developing web applications.  The IVR acts like a web browser.  In fact the component of the IVR that consumes the VoiceXML documents is often referred to as the VoiceXML browser.  So that would make the IVR the client-side.  Any application logic we put into the VoiceXML document will be processed client-side.  Even though some constructs were added in later versions of VoiceXML to make it possible to access data sources directly from VoiceXML you usually needed server-side programming to access back-end systems to retrieve or update data and to dynamically generate VoiceXML documents that contain data to be voiced back to the user of the system.  So how much o

In a previous post I showed how easy it is to test a VoiceXML application developed using VoiceModel with a free IVR solution from Voxeo called Prophecy .  In this post I will show how you can use Voxeo's hosted IVR service which you can also test applications for free.  This hosted service resides in the Cloud and still uses the same Prophecy software to run it.  The added advantage to the hosted environment is gives you more options to try for connecting to the IVR, such as Skype, a number of SIP based phones, and regular telephone lines.  It is also a good way to test how your application will work if you plan to deploy it as a cloud based solution.  And it is easy to migrate your application from the hosted development  to production.  The other added advantage is the hosted platform is always up to the latest and greatest revision of the software which is transparent to you.  With a premise based solution you always have to check if there are new versions and apply the upd

I found a couple of issues when deploying a VoiceXML application using MVC and VoiceModel  to a hosted environment and I wanted to share the solutions here. First you may get an error message when you try to run the application that it cannot find certain assemblies that are required for MVC.  In an earlier post titled " Using ASP.Net MVC to Create a Simple VoiceXML Application " I discuss how you have to install MVC 3 because it does not come with VS 2010 right out of the box.  Well it is currently not part of the .NET Framework either.  But there is an easy solution for including the correct assemblies as described in this blog post .  Just right click on your project and select Add Deployable Assemblies .  I dialog box will appear and select the option for ASP.NET MVC .  Now when you publish your project the appropriate assemblies will be deployed with it. The other issue is that VoiceModel deploys shared views in the ~/tmp/Views/ directory.  When you run the applicati

In a previous post we created a simple "Hello World" application to demonstrate how to use the VoiceModel library.  This did not demonstrate how to control the flow of a voice application so in this post I will explore how we can add a controller to our MVC VoiceXML application.  Lets take a simple example of a voice application that allows the caller to get the weather conditions for an area based on zip code.  Here is the call flow for our application. If we were developing this application in straight VoiceXML the first block in our call flow could be handled something like this. <?xml version="1.0" encoding="UTF-8"?> <vxml xsi:schemaLocation="http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml20/vxml.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.w3.org/2001/vxml" version="2.1"> <form id="greeting"> <block> <prompt>

In this post we will look at making the core components for our MVC voice application more reusable. In a previous post we looked at making a simple Hello World application to see how we might use MVC and Razor to develop a VoiceXML application.  This was more or less a proof of concept for a framework that has the goal of making development of VoiceXML applications easy and could rival some of the VoiceXML development tools out there. I have taken the reusable parts of this framework and put them into a class library which is open source and can be downloaded from CodePlex . I call this project VoiceModel because it replaces the ViewModel in the MVVM Design Pattern .  What is in our VoiceModel is the meta-data required to render VoiceXML to an IVR (VoiceXML Browser).  The challenge I came across was packaging up the Views developed in Razor that are also reusable across projects.  I did some research and found a solution that seems to work pretty well and is described in StackOverfl

In this post you will learn how to test the VoiceXML application created in a  previous post .  This voice application was created using ASP.Net MVC, Razor, and C#.  We will test using Voxeo's Prophecy IVR which is available to developers for free.  You have two options with Voxeo's Prophecy; hosted or on-premise.  Hosted is an IVR in the cloud that is hosted in several Voxeo hardened and redundant facilities that are geographically dispersed.  On-premise is an IVR that resides in your facility, or in this case your development environment right on your workstation.  In this post we will cover setting up Prophecy on your workstation. First go to Voxeo's website to download Prophecy .  After you download Prophecy run the simple install.  In most cases the defaults are just fine.  There will be a point where it asks if you want to have the Prophecy services start automatically.  For my development environment I prefer to start the services manually so that it is not always

This is a continuation on a series focused on developing VoiceXML applications using ASP.Net and other Microsoft technologies. In today's post we will look at putting together a simple application using MVC 3.0 and Razor.  This assumes you have some familiarity with ASP.Net, Visual Studio 2010, and VoiceXML.  A good reference for VoiceXML can be found on Voxeo's Developer Website .  We will start out by creating the typical "Hello World" application. MVC stands for Model/View/Controller which is also a design pattern.  You can find a pretty good description of this pattern on the Microsoft Patterns & Practices Website .  Basically this pattern allows for more flexible and robust applications by separating concerns into these three areas.  The Model represents the application domain,  The View represents the information being displayed to the user, and the Controller mediates between the Model and the View by taking user input to control the flow of the applicat

This is a first in a series of blogs where I will explore using new Microsoft .Net technologies to develop voice/speech applications that will run on any IVR platform that supports VoiceXML.  In this initial blog I will take a brief look at the history of voice application development and why I think this is a viable and productive method for developing voice applications. I will also introduce you to the specific technologies I plan on using. I have been developing voice/speech applications for over 20 years and a lot has changed over these years.  The biggest change was from developing in proprietary development environments supplied by each IVR vendor to IVR platforms that supported open standards like VoiceXML and CCXML  that were controlled by the World Wide Web Consortium (W3C).  These open standards radically changed how voice application were developed, moving to more web-centric tools and promises of making every web developer a voice application developer.  Well almost.