Created by: Janine Graves on 15-10-2013 07:22:11 PM Hi Paul, Could you post an Audio element that clears the DTMF buffer? There's a huge demand for it in training classes that I teach. And you are much better at creating voice elements than I am! I always give up after an hour or two! Thanks, Janine
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Koen Van Impe on 16-10-2013 02:46:12 AM Hear, hear!
After my experience with the return element flushing the buffer (read all about it here), I agree with Janine.
Koen
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Paul Tindall on 18-10-2013 05:59:53 PM Give this a try and let me know if it works as I wasn't able to test it fully right now.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 19-10-2013 01:13:37 PM I will try this Monday. Many thanks for your help!
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 21-10-2013 05:34:55 PM Hi Paul, Just tried the element to clear dtmf buffer. It works if I'm using a speech recognizer. But it doesn't clear the dtmf buffer if I'm using the Cisco DTMF-Only gateway. I've only tested this on CVP 8.5 system so far. Also, I was surprised to see that you did not use the dtmf-typeahead-flush property in your java/vxml code created.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Paul Tindall on 22-10-2013 04:32:16 AM Janine,
Interesting. I used the cisco-typeaheadflush element for a couple of reasons. Firstly, it's the approach used in the subdialog return to flush the buffer (with corresponding implications as we saw just recently). Secondly, it was by far the simplest way as it could be inserted as the first form in the document by extending the existing audio element and didn't require re-building all the audio VoiceXML content, as you can see from the Java source. I'll investigate it a bit more when I have a moment.
Paul
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 22-10-2013 07:00:45 AM My mistake, I must've tested the Synchronous Audio element, not the typeahead flush element. Will re-test today.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 23-10-2013 01:05:21 PM HI Paul, I tested the correct element this time (AUdio_Flush_Typeahead) but it still doesn't seem to clear the dtmf buffer. I have a Digits element that collects 4-6 digits, then the Flush element, then a YesNo_menu. When I called in, I (as the caller) entere 7 DTMF-digits;1234567 but still got a Nomatch at the YesNo menu (as the gateway had the 7 in its DTMF buffer). I'm uploading the VXML Debug Log here - so you can see the vxml created by your java code. I thought cisco-typeaheadflush was a VXML property or an attribute of <prompt>.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 23-10-2013 01:17:50 PM [quote=Just uploaded the debug log.
Janine Graves]HI Paul, I tested the correct element this time (AUdio_Flush_Typeahead) but it still doesn't seem to clear the dtmf buffer. I have a Digits element that collects 4-6 digits, then the Flush element, then a YesNo_menu. When I called in, I (as the caller) entere 7 DTMF-digits;1234567 but still got a Nomatch at the YesNo menu (as the gateway had the 7 in its DTMF buffer). I'm uploading the VXML Debug Log here - so you can see the vxml created by your java code. I thought cisco-typeaheadflush was a VXML property or an attribute of <prompt>.
Subject: Re: New Message from Janine Graves in Customer Voice Portal (CVP) - General Replied by: Janine Graves on 23-10-2013 01:31:54 PM Just saying that I uploaded the vxml debug log.
Subject: RE: Re: New Message from Janine Graves in Customer Voice Portal (CVP) - Gen Replied by: Paul Tindall on 23-10-2013 04:51:37 PM Janine,
Thanks for doing some testing. I did it this way because cisco-typeaheadflush is a valid element as defined in the Cisco VoiceXML DTD. It's also used that way in the subdialog return Studio element and it would appear to cause buffer flushing there as that's what kicked-off this piece of work. I'll take another look at it when I get chance.
Paul
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Koen Van Impe on 24-10-2013 06:52:09 AM Janine,
Isn't this a timing issue? By the time you type "7" the vxml has already advanced to the yes-no menu. Could you add an audio element just before the new flush-typeahead element. Make it a long enough audio ("please hold while we process your answer") with barge-in enabled. The first six digits are read by the "Tell me your RX number." digits menu. The 7th digit will barge-in on the "please hold" but stay in buffer, be flushed by the flush-typeahead and you should hear your yes-no menu.
K
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 24-10-2013 09:05:40 AM Good guess! Sorry for doubting you Paul.
When I put a 1 second delay before using the Audio_Flush_Buffer element, then it performs as advertised. But this does show that people need to be pretty diligent in testing that their usage of the flush_buffer element will work as they expect.
Thanks Paul and Koen.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Janine Graves on 24-10-2013 09:25:39 AM Paul, As a follow up. I modified your element's java code and added a 1000ms sleep before returning the first page of vxml code to the gateway. This works great.
But, when I compile the java, I wind up with 2 java class files (this is true even if I delete both and recompile only the modified java): AudioFlushTypeahead.class and AudioFlushTypeahead$CiscoTypeahead.class I still wind up with just one Studio element. Can you explain why and which java class file is the real one? And why this is happening?
Subject: RE: New Message from Janine Graves in Customer Voice Portal (CVP) - General Replied by: Hemal Mehta on 24-10-2013 09:47:22 AM Janine, Two files are generated because the file is likely using anonymous inner class. (represented by AudioFlushTypeahead$CiscoTypeahead.class) Hemal
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com] Sent: Thursday, October 24, 2013 9:26 AM To: cdicuser@developer.cisco.com Subject: New Message from Janine Graves in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Clear Dtmf Buffer Audio Element
Janine Graves has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Paul, As a follow up. I modified your element's java code and added a 1000ms sleep before returning the first page of vxml code to the gateway. This works great.
But, when I compile the java, I wind up with 2 java class files (this is true even if I delete both and recompile only the modified java): AudioFlushTypeahead.class and AudioFlushTypeahead$CiscoTypeahead.class I still wind up with just one Studio element. Can you explain why and which java class file is the real one? And why this is happening?
Subject: RE: New Message from Janine Graves in Customer Voice Portal (CVP) - General Replied by: Paul Tindall on 24-10-2013 12:14:09 PM Spot on. In order to add the <cisco-typeaheadflush> custom VoiceXML element I simply included a class to extend VAction and implement the addVXML method.
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Koen Van Impe on 25-10-2013 06:39:07 AM Paul,
Your Audio Sync element proofs to be very helpful to solve an issue when using Application Transfer. Problem: I have a first app that just plays one audio element and then transfers to a second app. Each app has its own page with hotevents to catch badfetch and badfetch.404.http. I deliberately stopped the media server for testing ... and my call just disconnects without showing any errors. (It should have gone to a second media server). I know this works if I use just one app (no application transfer).
I guessed there was a timing issue with serving vxml pages and the gateway processing them.
Solution: I added your audio sync element just before the application transfer. It makes sure all vxml of the first app is processed before we jump to the next app. It works like a charm!
Thx Paul!
Subject: RE: Clear Dtmf Buffer Audio Element Replied by: Paul Tindall on 25-10-2013 08:54:45 AM Koen,
Thanks for the update and great to hear it's behaving as intended. The async nature of VoiceXML doc fetching has certainly caused it's fair share of problems and unexpected working, especially as CVP users used to using microapps started using Studio.
Paul
Subject: Re: New Message from Paul Tindall in Customer Voice Portal (CVP) - General Replied by: Janine Graves on 25-10-2013 08:59:21 AM Maybe as a future enhancement, Cisco can combine all these options into one Audio element that allows the developer to select: synch or asynch as well as whether to flush dtmf buffer or not.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: