CVP and DTMF Grammars

mikehentges · ‎12-04-2009

We have a CVP application that needs to accept a fairly complicated set of digits, and an elegant design solution involved the use of a DTMF grammar.

Upon deployment, we are seeing that this results in an ASR license being allocated to this call, even though it is a DTMF-only application.

Is there a way to utilize a DTMF grammar without having the system use an ASR license? We are trying to specify that the caller can enter a valid menu option (1-4, *) OR a 6-digit extension number at the input. A DTMF grammar allows this to be done with leveraging the application standards processing for invalid inputs, which is clean.

geoff · ‎12-04-2009

I don't know how to solve that problem, but I do have a view on this type of user interface, which I expressed recently when a similar question was asked in the context of IPIVR. I hope you won't consider this a thread-crap.

I believe that this mixing of digit entry (for dial by extension) with menu options is old fashioned, having been derived from the way old PBX/IVR collected digits; and it is hard to implement and has poor error checking.

With CVP I prefer a menu with an option like - "for dial by extension, press 1" and then send the caller to a nice handler like Unity. One customer also wanted the "dial by name" option, and again, off to Unity which of course does a splendid job.

Recently, a low bandwidth line between the voice gateway at the branch office and centralized Unity pushed me to implement a dial by extension application in CVP (running on the VG), selected after a menu option. I implemented this using microapps. There are only 150 phones so I can check that the entry is valid before returning the label - in CVP 7 you can do this with a SIP refer to release the CVP port.

Is it possible to have the customer consider splitting the two functions apart and building the CVP applications separated by ICM scripting?

Regards,

Geoff