Showing 6 results.
Items per Page 50
of 1

CVP Forum

« Back to Universal Edition New Feature Discussion

Return back to last dtmf/speech entry from hotlink

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Imagine the scenario

1. DTMF/Speech element (can't have terminating character)
2. Caller presses zero/hash in stead
3. Global hotlnk activated
4. Write to log / update a variable
5. Return back ack to original DTMF/Speech Element
6. 60 possible DTMF/Speech entry elements
7. Achievable in VXML

So Audium

How can we route back to the correct DTMF/Speech Element from an activated hotlink. Usually reprompt would do this when in a VXML Link.

Thanks Mike, is there a response to this? We need some real answers and pretty fast!

Hi Karl,

We have a Knowledge Base article that describes how to jump to a specific element at runtime. The article gives an example of how a user can return to the last element visited from a Hotlink element. The article is available at: How can I jump to a specific element at runtime (i.e. goto)?

With that said, we understand that this solution might be cumbersome for large applications. We have a enhancement request in our internal issue-tracking system with an ID of CSCzc10311 for adding a <goto>-type element that would let you jump to any element in the call flow by name. Please note that we have added a note to this enhancement request describing your specific needs. Please refer to that ID in the future to check the status of this request.

Hope this helps,
Harish

Up are you serious that on a 200 page call flow system with loads of input elements that this is viable?

Seriously guys, time to start making these exit states dynamic and parameterised.

Also urge you to create special audium variables

1. Last input element visited
2. Last prompt element played
3. Last nomatch or noinput event triggered
4. Current event count value

audium.session.last_input_element
audium.session.last_prompt_element
audium.session.last_nomatch_noinput_event
audium.session.last_event_counter

etc

1. Connectors should be parameterised
2. Connectors should know the last page they came and have ability to return back to the next step after the call out.

Hi Karl,

Since you have raised several different points, please see the reply to each inline below:

[quote:ad77436f1d]
audium.session.last_input_element
audium.session.last_prompt_element
audium.session.last_nomatch_noinput_event
audium.session.last_event_counter

Etc
[/quote:ad77436f1d]

It is possible to access the element history in Studio via substitution under the "Caller Activity" tab. Using substitution, it is possible to access the Nth-visited element. Please note that the Nth-visited element cannot currently retrieve the previous element's name.

It is also possible to access the list of previously visited elements by using the Audium Java API. Here is a link to a knowledge base article that describes how to achieve this:
How to access a list of previously visited elements

We understand that the Java API solution might not be suitable for everyone. Therefore, in order to have this data accessible from Studio, we have entered this enhancement request in our internal issue-tracking system with an ID of CSCsh84174. Please refer to this ID in the future to check the status of this request.

[quote:ad77436f1d]
1. Connectors should be parameterised
[/quote:ad77436f1d]

We have this enhancement request in our internal issue-tracking system with an ID of CSCsh78317. Please refer to this ID in the future to check the status of this request.

[quote:ad77436f1d]
2. Connectors should know the last page they came and have ability to return back to the next step after the call out.
[/quote:ad77436f1d]

This enhancement request also exists in our internal issue-tracking system with an ID of CSCsh71368. Please refer to this ID to check the status of this request.

Regards,
Harish

Folks,

All we ask is to listen to our real world stories here, there's a lot of good stuff in the tool (sometimes we don't say it enough) but there's much to improve (even basics) and advanced features.

Many of things we've raised here are based on direct experiences on customer sites. Add a lot of these features and the tool will take a radical new dimension.

I had 8 menu components and had to incorporate star key press into them, and its a shame you can right click and increase the menu size type.

Would have taken me 1-2 hours with everything else connected to sort it out. Took me 15-20 mins edited the xml and check it works.

Hi Karl,

Thanks for your feedback! Constructive suggestions for improvements to our software are truly appreciated!

The ability to increase menu options within the same element is not currently supported in the XOptionMenu elements. However, it is possible to achieve the same functionality by using a Form element, followed by a Decision element. The Form element can be configured to listen for each of the options, and the Decision element can examine which option was chosen and exit accordingly. When this is done, new options can be added fairly easily by expanding the Form element grammar and adding new exit states to the Decision element.

As the Decision element has configurable exit states, the Form+Decision approach provides better call flow visibility than an approach using just an XOptionMenu element. So instead of exit states that are named 'option-1', 'option-2' and so on, you would get more meaningful exit state names such as 'news' and 'weather' in the call flow.

Hope this helps with what you are looking for.
Rachel

Rachael,

I totally agree with you. You should design according to the task alas we had no choice as some work was done by another vendor and their approach wasn't what I would call extensible. It was more of a hack job.

I still think my comment is applicable, right click, extend from a 3 to a 4 menu component. It takes 1 minute to edit the XML and achieve this but visually it takes longer.

Some areas I would target, exit state issues - dynamic, connectors, audio bargein, capturing events and providing this information on count by count basis, timeout with xml api, javascript calls and mapping.

It does need to be more accessible and having done VoiceXML for 5 years, there are frustrations here.

If you do some of these basic things god our lives would be easier, call flows more efficient and less workarounds.

Hope you folks will kindly take it all on board.

Hi Karl,

We sincerely appreciate the suggestions and feedbacks that you have provided. It is great that you are able to share your real-world experiences with us.

We have added the "XOptionMenu" enhancement request into our internal issue-tracking system. We have added your specific feedback to that request. Please refer to ID CSCsh98778 for status of this feature.

Regards,
Cheng

Given what i see, its a quick easy win to implement this and update the XML base code with a little funky java routine.

Adds a lot of value to the development environment too