Decision tree support for IVR modules

[Sanchit Bahal]

As part of the ongoing IVR Verboice work, we would like to add support for decision trees in the IVR Verboice module. Also, this should be generic enough so that adding support for decision trees in other IVR modules is straightforward.

 

Here is how we envision this to work:

·        The decision to whether use decision tree or not is left up to the implementer.

·        Base IVR module should provide:

o   Contract for the set of IVR events (viz., newCall, gotDtmf, hangUp, etc.) that each of the individual IVR modules (viz., Kookoo, Verboice, etc.) should implement. Each module could have their specific verbs corresponding to these events, e.g., Verboice refers to the ‘gotDtmf’ event as ‘gather’.

o   Contract / default implementation for a common request / context object.

o   Contract for response object. The individual IVR modules can then have a template-based approach to create the final response XML.

o   Controller to interact with a decision tree. As step 1, we are thinking of implementing support only for a single tree, however at a later stage, it would have support for multiple trees with provision of jumping off from one tree to the other. Would it make more sense to push this in the Decision Tree module?

 

Please have a look at the attached pics for more details on the design, and let us know your thoughts/comments.

 

Thanks,

Dileep | Sanchit (pairing)

[Rob LaRubbio]

I think I'm a little confused by this.  First how does this relate to the existing decision tree module?  The idea behind that was to express a decision tree in JSON that then could be served in VXML or a different markup.  Or how does this relate to the other decision tree like module we built in Javascript for BBC?  Why would we duplicate those in each of the IVR * modules?  It also seems this wants to work with an API or evented IVR system.  How would it work with one that is document based?

Anyway INSTEDD has been working on a call flow designer that will execute call flows within verboice or potentially export them as VXML, so longer term I see a lot of this code/logic moving out of MOTECH.  I'm attaching some screen shots from the call flow designer work they've completed so far for context.

-Rob

[Sanchit Bahal]

Currently, only the IVR Kookoo module has support for decision trees, i.e., it understands the call flows specified in the ‘decision tree’ format. The intention here is to make this support for decision trees available to the other IVR modules as well (or in other words, reuse the DecisionTreeBasedController that was built for TAMA).

More context: Ghana National would be using the IVR Verboice module of the platform. The Verboice module should have support for decision tree in order to enable the Ghana National team to specify their call flow as a decision tree.

 

An alternate approach could be to drive the call flow by registering handlers for callbacks.

 

>> It also seems this wants to work with an API or evented IVR system.  How would it work with one that is document based?

Currently, both Kookoo and Verboice are event-based (unlike VXML, a twiML document represents single interaction). However, we agree that for a pure document based IVR system, like OnMobile, this approach would not work.

 

Thanks,

Sanchit Bahal

Mobile: +91 9980141983

[Rob LaRubbio]

On 5/4/12 5:39 AM, Sanchit Bahal wrote:

Currently, only the IVR Kookoo module has support for decision trees, i.e., it understands the call flows specified in the ‘decision tree’ format.

That's not true, you can use the decision tree module with asterisk or voxeo.  You use those modules to initiate the call and point it to a url that is served by the decision tree module.  The decision tree then handles the markup and communication with the IVR system.

More context: Ghana National would be using the IVR Verboice module of the platform. The Verboice module should have support for decision tree in order to enable the Ghana National team to specify their call flow as a decision tree.

 

>> It also seems this wants to work with an API or evented IVR system.  How would it work with one that is document based?

Currently, both Kookoo and Verboice are event-based (unlike VXML, a twiML document represents single interaction). However, we agree that for a pure document based IVR system, like OnMobile, this approach would not work.

The issue with kookoo wasn't that it was event based, it was that it always posted back to the same url.  (although it would have been possible to modify the existing decision tree to work with that, and I wish we had).  With twiML you can specify a URL with the gather tag (and nest say or play within it).  So it actually maps very well onto the VXML markup currently used by the existing decision tree.

-Rob