Porting a Voice Application

Legacy VBVoice applications were written to run on a voice card or driver that support telephone calls. However, with some restrictions and limitations, the same existing application can be imported to run on Data channels in the Visual Connect environment. Developers need only to follow certain steps to accomplish this, here they are:

1. Configure VBVoice to run VisualConnect functionality

   Refer to the page Configuring VisualConnect to complete this step.

2. Edit your application's LineGroup properties

   The following properties might need modification to allow the application to run in VisualConnect mode:

   • LinesInGroup: change the range of channels used by this LineGroup to include a Data Channel.
     For example, if voice card type is set to none any range set in this property between 1 and the maximum licensed Data channels will be used for VisualConnect. If the system is using a 4 lines voice card and the card type is set to type=dialogic, setting a range of 1-10 allows the application to serve 4 voice calls on channels from 1 to 4 and 6 data sessions on channels from 5 to 10.
   • Data AppName: by default this property is an empty string which is interpreted as default. Change this property to give this IVR application a unique name when accessed from the web.
     When the application starts, browsing to the root folder of the machine's website will show a list of all the VisualConnect applications running on this machine distinguished by this name.

   At this point, your application is ready for an experimental run.

3. Run your application an experimental round

   A wide range of IVR Voice applications require no further changes to run on a Data channel. If your application does not use any of the VBVoice features listed as not supported in VisualConnect (see VisualConnect application limitations) you can proceed to build your application and run it. Then try to browse from a desktop browser on the same machine to the localhost as http://127.0.0.1 (or from another machine or a mobile connected to the same network through WIFI to the IP or name of the machine running the application as http://<machine IP>/.

   This step has two purposes:

   • Experience the visual look and feel of the application on a browser (preferably mobile but desktop is enough).
   • Test the different functionalities of the call flow on a Data Channel and create a task list of behaviors to customize in the call flow.

   An example of a behaviour you may want to customize is a prompt that is redundant or does not make sense on a browser.

4. Provide alternate text for the voice prompts

   VisualConnect automatically renders a suitable HTML page for each greeting object that needs to be played on a Data Channel. It does this perfectly for the VBVoice system phrases and relatively good for phrases that use the VAP files. However, if the application is using some custom recorded wave files they will need some attention, the test executed in the previous step would show such cases.

   By default, phrases of type wave files would show the file name instead. For each of the wave files used in the application, provide an accompanying text file that contains the alternative text for that phrase. Accompanying files share the name of their related wave files ending with a second extension as .txt; e.g. welcome.wav should be accompanied by a welcome.wav.txt file.

5. Customize the call flow for Data Sessions

   Respond to the list of tasks collected in step 3 above. Modify the IVR application to accomodate a Data Session.

   Examples of tasks to do in this step are:

   • Letting the call flow skip controls that are not supported in VisualConnect, e.g. DynamicGrammar.
   • Avoiding calls to any telephony-only method, e.g. BridgeChannelToChannel.
   • Further configure VisualConnect if the default behavior is not favoured for this application, e.g. Voice Over Data feature may not be acceptable for high security applications.

   Using IsDataChannel runtime property of VBVFrame allows the application to dynamically check if the current channel is serving a Data Session and a call to TakeCall (or a method) is required.

   With this step, the application is mostly ready for a beta test.

6. Enhance the IVR application to better serve Data Sessions

   This step is to take care of the less critical tasks listed from step 3 above. See the section Enhancing a Voice Application for more details.