How Could an IVR Application Serve a Mobile Application?

Event driven programming model

IVR applications built on VBVoice toolkit use an event driven programming model where application code mainly executes upon an event fired by the toolkit when it is suitable to execute that code. This model fits with telephony applications where the voice card driver informs the application of any action that happens on the telephone line, e.g. a call is offered, a DTMF is pressed or the caller hanged up the call... etc. The IVR application may execute a suitable response to the event like accepting or rejecting a call that is rining.

The same model is applied to web-based applications, including the mobile ones. When a user browses to a web page, clicks a link, submits a form on the page or enters some text in an input box on the page, an event is sent to the server, at which point the application can execute a suitable code and send back a response.

The first time a user browses to an application, VBVoice creates a session that is simulating a voice call in telephony. The session is served by actions defined in the specific application call flow control by control starting from the LineGroup identified by the application name and in most cases ending with an OnHook. Whenever the IVR application is expected to interact with the user, a page is presented in the browser awaiting their input to proceed. The following diagram shows this model in details:

The event driven model serves the data channel session by responding to each HTTP request with an HTML page after executing the suitable application and some lower level code. The HTTP requests are generated from a click of a button or from some data entry that mimic entering digits in a telephone call, while the HTML response contains the announced information by the application that mimic a voice prompt in a voice call.

Understanding the similarities between Voice channels and Data channels

VBVoice abstracted many of the telephony terms used in IVR applications to properly cover VisualConnect and Data channels functionality. The following terms are explained to help developers make the analogy and smoothe their move to use VisualConnect:

• Data Channel: similarly to a voice channel, a data channel is a licensed port of VBVoice that is delegated to serve a particular mobile web session. It runs in its own thread and properly manages the interaction with the application code providing it with a unique set of all the controls runtime properties involved in the application call flow.
• Call Flow: is the IVR application call flow that a call will go through during a voice call. The same flow serves a data channel by definition.
• Data Session: this term can be used in comparison with a Voice Call.
• Data Application Name: the target machine's website (that is hosted by IIS) is considered the single point entry to all IVR applications running on this machine. Those applications might be distinguished with an app name. The full URL that is used to reach this application is similar to the phone number that is dialed to reach the IVR voice application.
• Text Prompt: VBVoice uses the term Greeting to refer to voice prompts played to a caller in IVR applications. The greeting is now extended to cover a text type (or an HTML formatted text) that is shown on the browser during a Data Session.
• Wait For Session State: is the Data Channel equivalent to a Wait For Ring state in voice channels.
• HTTP Request: every time a user browses to a VisualConnect application to initiate a new call, their mobile browser sends an HTTP request with a GET method to the application. This request initiates a Data Session on one of the Channels that are in the Wait For Session state.
  All other HTTP Requests that interact with an active channel are using a POST method.
• Hanging Up A Data Session: when a call flow of an active session reaches an OnHook control, VBVoice closes the session and frees up its channel to be reused by setting it in Wait for Session state. Vbvoice will not expect any further requests submitted to this ssssion and, as a matter of fact, the final page of the Data Session does not provide any HTML element that allows such action.

Exceptions and Differences

Due to the difference between the technology behind a web application and that behind a telephone call, we should expect some behavioural differences. This section will explain those differences.

• Idle Time: following an HTML response from the application to the browser, there is a period of time during which the application is waiting for the next action of the end user. This is considered an idle time as the application is actively interacting with the end user while keeping tne Data channel and all its resources reserved for this user.
  Similar situations in Voice channels are not exactly the same because the telephony technology allows the IVR application to listen to tne user during this period, play an announcement to the user urging him or her to respond to the call, or terminate the call making sure the user aware of that.
  Users of mobile applications may or may not respond quickly to a Text Prompt requesting certain information. They may even choose to abandon the Data Session completely, yet it might look like an abandoned session while the user took a little more time to respond. VisualConnect defines a timeout called Session Idle Timeout during which the Data Session is sitting waiting for the user input. When the Idle timeout is over the IVR application hangs up the Data Session and frees its resources.