--------------------------------------------------------------
I have an application that waits for input forever, it uses a Voice Element Yes_No menu, 2s timeout, DTMF only, 10 retries counts, no replay and disable hotlinks is false


Can you clarify why it waits for input forever as you have 2 s timeout and then 10 retries. Not sure what you meant.
Meanwhile., can you enable extended logging in tomcat, so we can see the logs at the vxml level.

Hemal

________________________________
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Monday, January 10, 2011 11:44 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Bill Westby in Customer Voice Portal (CVP) - CVP - All Versions: CVP Subdialog Return has Audio Element entries in debug logs

Bill Westby has created a new message in the forum "CVP - All Versions":

--------------------------------------------------------------
I have an application that waits for input forever, it uses a Voice Element Yes_No menu, 2s timeout, DTMF only, 10 retries counts, no replay and disable hotlinks is false.

Occasionally the gateway throws a error.badfetch, don't know why and don't really care, probably network or GW too busy, whatever. I catch it using a HotEvent and return to ICM with a caller_input value of "error". What I see in the logs 90-95% of the time is the traces of the audio element playback mixed in with the return to ICM statement.

Take a look, my callflow is simply trying to return to ICM here using a CVP Subdialog Return named "Return rescheduled to ICM". How it has portions of what appears to be the Audio_groups from my Yes_No menu (I"m assuming that's what they are) is really odd, not sure why it would have any data beyond the name of the actual CVP Subdialog return element name...it's like it's executing the wrong node name and actions, it's really strange, hope I explained it well enough, thoughts?

Actiivty Log entries:
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.103,set_ExitingRescheduled,enter,
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.103,set_ExitingRescheduled,custom,ExitState,ExitingRescheduled
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.103,set_ExitingRescheduled,exit,done
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.103,Return rescheduled to ICM,enter,
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.103,Return rescheduled to ICM,interaction,audio_group,initial_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:10.743,Return rescheduled to ICM,interaction,noinput,1
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:10.743,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:22.668,Return rescheduled to ICM,interaction,noinput,2
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:22.668,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:34.588,Return rescheduled to ICM,interaction,noinput,3
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:34.588,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:46.508,Return rescheduled to ICM,interaction,noinput,4
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:46.508,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:58.433,Return rescheduled to ICM,interaction,noinput,5
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:42:58.433,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:43:10.245,Return rescheduled to ICM,interaction,noinput,6
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:43:10.245,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:43:22.165,Return rescheduled to ICM,interaction,noinput,7
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:43:22.165,Return rescheduled to ICM,interaction,audio_group,noinput_audio_group
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.119,Return rescheduled to ICM,element,hotevent,Fetch Error
10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011 12:41:49.119,Return rescheduled to ICM,exit,


--
To respond to this post, please click the following link:

<http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2887453>

or simply reply to this email.

Yes good plan Janine. As always thanks a million for your quick response and vast knowledge.

Thx,Billw. Sent from my iPhone

On Jan 10, 2011, at 10:24 AM, "Cisco Developer Community Forums" <cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "CVP - All Versions":
>
> --------------------------------------------------------------
> OK, this is what I think is happening (and you could probably turn on
> logging on the gateway to confirm if this is true).
> The VXML that goes to the gateway for your YesNo menu has code in it
> that continually adds information onto a logging variable audium_vxmlLog
> (or something like that) and then returns this logging variable back to
> VXML Server whenever it's done doing what it's supposed to be doing.
>
> So, your YesNo menu experiences (let's say) 9 noinput events. So, the
> audium_vxmlLog variable contains info like:
> "noinput,1, noinput, 2, noinput, 3, etc, noinput, 9"
>
> Now, if you finally exited down the max_noinput path, this data would be
> reported back to VxmlServer and would be logged as part of the YesNo menu.
>
> But, since you're getting a BadFetch event, there's other code that's
> now taking over. It's sending the event back to VxmlServer telling it to
> visit your hotEvent element. It's also adding onto the same logging
> variable audium_vxmlLog. So now that logging variable has something like:
> "noinput,1, noinput, 2, noinput, 3, etc, noinput, 9, ,hotevent,Fetch
> Error" --> this gets returned to VxmlServer who then logs the noinput
> events as part of the hotevent element path .
>
> I know this seems weird, but your time stamps in the log are odd also.
>
> Why don't you try setting the fetchtimeout to something like 360s in the
> Settings tab of your YesNo menu. That might take care of the erroneous
> badfetch events you are receiving.
>
> Janine
>
>
> On 1/10/2011 12:44 PM, Cisco Developer Community Forums wrote:
> > Bill Westby has created a new message in the forum "CVP - All Versions":
> >
> > --------------------------------------------------------------
> > I have an application that waits for input forever, it uses a Voice
> > Element Yes_No menu, 2s timeout, DTMF only, 10 retries counts, no
> > replay and disable hotlinks is false.
> > Â
> > Occasionally the gateway throws a error.badfetch, don't know why and
> > don't really care, probably network or GW too busy, whatever. I
> > catch it using a HotEvent and return to ICM with a caller_input value
> > of "error". What I see in the logs 90-95% of the time is the traces
> > of the audio element playback mixed in with the return to ICM statement.
> > Â
> > Take a look, my callflow is simply trying to return to ICM here using
> > a CVP Subdialog Return named "Return rescheduled to ICM". How it has
> > portions of what appears to be the Audio_groups from my Yes_No menu
> > (I"m assuming that's what they are) is really odd, not sure why it
> > would have any data beyond the name of the actual CVP Subdialog return
> > element name...it's like it's executing the wrong node name and
> > actions, it's really strange, hope I explained it well enough, thoughts?
> > Â
> > Actiivty Log entries:
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.103,set_ExitingRescheduled,enter,
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.103,set_ExitingRescheduled,custom,ExitState,ExitingRescheduled
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.103,set_ExitingRescheduled,exit,done
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.103,Return rescheduled to ICM,enter,
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.103,Return rescheduled to
> > ICM,interaction,audio_group,initial_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:10.743,Return rescheduled to ICM,interaction,noinput,1
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:10.743,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:22.668,Return rescheduled to ICM,interaction,noinput,2
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:22.668,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:34.588,Return rescheduled to ICM,interaction,noinput,3
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:34.588,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:46.508,Return rescheduled to ICM,interaction,noinput,4
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:46.508,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:58.433,Return rescheduled to ICM,interaction,noinput,5
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:42:58.433,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:43:10.245,Return rescheduled to ICM,interaction,noinput,6
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:43:10.245,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:43:22.165,Return rescheduled to ICM,interaction,noinput,7
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:43:22.165,Return rescheduled to
> > ICM,interaction,audio_group,noinput_audio_group
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.119,Return rescheduled to ICM,element,hotevent,Fetch Error
> > 10.60.244.41.1294511410641.20729.DB_Courtesy_CallBack,01/08/2011
> > 12:41:49.119,Return rescheduled to ICM,exit,
> > Â
> > Â
> > --
> > To respond to this post, please click the following link:
> >
> > <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2887453>
> >
> > or simply reply to this email.
>
> --
> Janine Graves
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2887493>
>
> or simply reply to this email.

[CONFIDENTIALITY AND PRIVACY NOTICE]

Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.

To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com