| Anonymous | Hello trainers,
When teaching the CVP installation and boot camp classes, there may be questions from the students about how Audium software (CVP Server) is integrated with ICM, which is their current IVR environment and which is still used to launch CVP applications. I am providing a PDF supplied by Cisco that describes this integration that could answer a good number of the student's questions (Appendix E is where this information can be found). I'll also briefly explain it below.
Fundamentally, a CVP application is treated by ICM as a <subdialog>. Due to this, there are inputs and outputs (in VoiceXML). The integration between the CVP application (which is Audium) and the ICM script has to do with how that data is passed to the subdialog and returned from the subdialog back to ICM. In ICM, these inputs and outputs are mapped to what is called ECC variables. The ICM script can then act on these variables to do whatever it needs. The idea here is that you could take an ICM script and have it go do something in VoiceXML using CVP, then come back and do other stuff. Really, since Cisco is pushing CVP, the right design is that the ICM is now going to be responsible for doing call control and CTI-type stuff, where the IVR itself is completely in the hands of CVP.
Within the CVP application, the mechanism to deal with these inputs and outputs are two Cisco-specific elements that are installed with the CVP software. They are called the subdialog start and end elements. Every CVP application [b:a8e9578194]must[/b:a8e9578194] begin with a subdialog start element since it is responsible for taking the parameters passed from the ICM script to the CVP application and storing it in element data or session data as defined in the element's settings.
The subdialog end element [b:a8e9578194]must[/b:a8e9578194] be used instead of a hangup. So whenever you would hang up your application, you should instead use the subdialog end element. This element has settings that define 5 different variables that are mapped to ECC variables in ICM. The first one, "caller_input" is a required setting and can contain any information to return. You would make sure the values returned can be handled by the ICM script appropriately. Note that the subdialog end element has an exit state, even though its purpose is to return and act like a hangup. This is because Audium has a restriction that a custom element must have a single exit state. Therefore, to ensure that Studio does not complain about all exit states not being mapped, map this exit state to a hangup. This does not mean that the hangup will ever occur, its just to get past the validation stage.
There are two modes that an application can run in. The first uses ICM to connect to a CVP application as described above. In this situation, one cannot use the Transfer element as all call transfers are expected to be initiated by ending the CVP application with a subdialog return element that returns a value that the ICM script knows to initiate a call transfer.
The other mode is called "standalone mode". This mode does not involve ICM at all, though CVP is still called as a subdialog by using what is called a "bootstrap VoiceXML page". This is simply a static VoiceXML page managed by the Cisco browser that calls the CVP application as a subdialog. In this mode, the Tranfer element can be used to initiate call transfers.
Hope this provides a little background on the nature of the Cisco OEM design. |
