Logs look fine but calls end abruptly

[cdnadmin]

This document was generated from CDN thread

Created by: Christopher Nagel on 23-03-2010 08:22:10 PM
Currently, my application seems to be interrupted during playback of a confirmation prompt and immediately transfers to an agent.  The ICM script doesn't seem to get the chance to populate data, although there's no other way to get to the requalify step other than to set values.
 
In the VXML app's ActivityLogs, the entire call flow proceeds and even has timestamp durations that indicate successful completion of the interrupted prompt, and even the following prompt!  But the caller experience is a completely different thing.
 
Can anyone here suggest a plan of attack?  I'm frankly at a loss as to where I should begin.  If the logs showed an error, I'd certainly start there.
 
Thanks!
Chris

Subject: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) - Gen
Replied by: Janine Graves on 23-03-2010 08:27:40 PM
Is your Confirmation Prompt in an Audio element or an element that
collects input from the caller? If it's just in an Audio element,
there's no way to tell the gateway to wait for the audio to be
completely played before continuing.

What you can do is force the VxmlGateway to finish playing the entire
prompt by moving that audio prompt into a YesNo_Menu. Set the NoInput
Timeout to 10ms, set Max NoMatch to 1, set Max NoInput to 1. Don't let
the caller know you're waiting for input. Then connect all the exit
states to your cvp_subd_return element.

Cisco Developer Community Forums wrote:
> Christopher Nagel has created a new message in the forum "General
> Discussion - All Versions":
>
> --------------------------------------------------------------
> Currently, my application seems to be interrupted during playback of a
> confirmation prompt and immediately transfers to an agent.  The ICM
> script doesn't seem to get the chance to populate data, although
> there's no other way to get to the requalify step other than to set
> values.
> Â
> In the VXML app's ActivityLogs, the entire call flow proceeds and even
> has timestamp durations that indicate successful completion of the
> interrupted prompt, and even the following prompt!  But the caller
> experience is a completely different thing.
> Â
> Can anyone here suggest a plan of attack?  I'm frankly at a loss as
> to where I should begin.  If the logs showed an error, I'd certainly
> start there.
> Â
> Thanks!
> Chris
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2063712>
>
> or simply reply to this email.

Subject: Re: Call ends inside audio element
Replied by: Christopher Nagel on 24-03-2010 02:01:35 PM
To paraphrase what you said, "IVR prompts cannot be fully played before the IVR continues" ??
 
Isn't the entire purpose of an IVR to play audio?  --Sequentially??
 
I am really very confused about this answer - sort of like saying "Yea, you bought a new keyboard but in order to type on it you have to sit on the mouse."
 
NOTE: This was working just fine until I updated it to turn off debug output in one of the libraries.  Maybe you're saying I need to leave that on to waste time? :-)

Also note:  The sudden end of the call doesn't follow the normal path - it's as though the call is being TAKEN away and requalified.
 
Thanks,
Chris

Subject: RE: Re: Call ends inside audio element
Replied by: Janine Graves on 24-03-2010 02:48:07 PM
Chris, you can also turn on gateway debugging and see if the gateway is encountering an error of some sort.
Look in the call server logs to see if ICM is interrupting the self-service for some reason.
 

Subject: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) - Gen
Replied by: Janine Graves on 24-03-2010 02:18:40 PM
Christopher,

I don't work for Cisco, so if you have any complaints about how their
software works, please take it up with them by filing a ticket wtih TAC.

The way VoiceXML interpreters work is this, if there's audio to be
played, it is passed to another process to retrieve it (using http if
necessary) and then another process on the gateway plays the audio.
Meanwhile, the interpreter races ahead and does whatever else needs to
be done in that VXML page.

The VXML document that VxmlServer creates for an AUDIO ELEMENT, doesn't
have to wait for the audio to completely be played before it goes back
to VxmlServer to request the next page, UNLESS the element is also
trying to collect caller input. Then the interpreter has to wait for the
prompt to complete, and wait for caller input, before it can go back to
VxmlServer to request the next page.


So, a quick work-around would be to do as I suggest.  If it fixes the
problem, it might help you debug what the issue is. If it doesn't fix
the problem then it's probably an issue on some other box than the
VxmlServer.

Here are some non-VxmlServer things to look at: Did the call get queued
to an agent before being sent to self service, ICM can interrupt the
self-service to send calls to agents?

Did the Studio application increase in duration? Because the ICM
GS,Server,V script has a timeout value waiting for the self-service to
complete.

Good luck, Janine



Cisco Developer Community Forums wrote:
> Christopher Nagel has created a new message in the forum "General
> Discussion - All Versions":
>
> --------------------------------------------------------------
> To paraphrase what you said, "IVR prompts cannot be fully played
> before the IVR continues" ??
> Â
> Isn't the entire purpose of an IVR to play audio?  --Sequentially??
> Â
> I am really very confused about this answer - sort of like saying
> "Yea, you bought a new keyboard but in order to type on it you have to
> sit on the mouse."
> Â
> NOTE: This was working just fine until I updated it to turn off debug
> output in one of the libraries.  Maybe you're saying I need to leave
> that on to waste time? :-)
>
> Also note:  The sudden end of the call doesn't follow the normal path
> - it's as though the call is being TAKEN away and requalified.
> Â
> Thanks,
> Chris
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2065794>
>
> or simply reply to this email.

Subject: Re: Call ends inside audio element
Replied by: Christopher Nagel on 24-03-2010 03:33:12 PM
Hi Janine,
 
I hope you didn't take my attempt at cartoonish incredulity as any sort of criticism - in the future I'll try to avoid attempts at humor, as I should know by now they always seem peevish rather than funny.  So, sorry about that.
 
Anyway, your fix worked just fine, and now the calling application (which plays the "Goodbye" message) has the problem with its "goodbye" audio, the next prompt in the chain.
 
These are apps that have been in production with just Audio elements for 4 months now.  Suddenly I have to redesign it using your fix to preserve the existing functionality.  And the developer of the calling app will now have to modify his app to preserve existing functionality.
 
Doesn't that seem strange to you?  I am very happy to have a fix (which I would not have without your advice!!), and may even write a custom audio element that does this for ALL audio elements going forward.  But so far, it seems as though this should never have worked, and yet it *is* working just fine right now in production.
 
I'm curious - when (if ever) is it safe to use the Audio element?
 
Thanks again,
Chris

Subject: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) - Gen
Replied by: Janine Graves on 24-03-2010 03:38:40 PM
You say that the calling app is having this problem now. Are you using
SubdialogInvoke to call one Studio app from another? Or Application
Transfer?

I'd say a good rule of thumb is that in the last audio before you leave
a Studio App, you should wait for input. This would apply to App
Transfer, SubdialogInvoke, Subdialog_Return, CVP_Subdialog_Return, and
Hangup.



Cisco Developer Community Forums wrote:
> Christopher Nagel has created a new message in the forum "General
> Discussion - All Versions":
>
> --------------------------------------------------------------
> Hi Janine,
> Â
> I hope you didn't take my attempt at cartoonish incredulity as any
> sort of criticism - in the future I'll try to avoid attempts at humor,
> as I should know by now they always seem peevish rather than funny. 
> So, sorry about that.
> Â
> Anyway, your fix worked just fine, and now the calling application
> (which plays the "Goodbye" message) has the problem with its "goodbye"
> audio, the next prompt in the chain.
> Â
> These are apps that have been in production with just Audio elements
> for 4 months now.  Suddenly I have to redesign it using your fix to
> _preserve the existing functionality_.  And the developer of the
> calling app will now have to modify his app to preserve existing
> functionality.
> Â
> Doesn't that seem strange to you?  I am very happy to have a fix
> (which I would not have without your advice!!), and may even write a
> custom audio element that does this for ALL audio elements going
> forward.  But so far, it seems as though this should never have
> worked, and yet it *is* working just fine right now in production.
> Â
> I'm curious - when (if ever) is it safe to use the Audio element?
> Â
> Thanks again,
> Chris
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2066152>
>
> or simply reply to this email.

Subject: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) - Gen
Replied by: Janine Graves on 24-03-2010 03:39:40 PM
sorry if I misinterpreted the tone, it's tough in emails!


Cisco Developer Community Forums wrote:
> Christopher Nagel has created a new message in the forum "General
> Discussion - All Versions":
>
> --------------------------------------------------------------
> Hi Janine,
> Â
> I hope you didn't take my attempt at cartoonish incredulity as any
> sort of criticism - in the future I'll try to avoid attempts at humor,
> as I should know by now they always seem peevish rather than funny. 
> So, sorry about that.
> Â
> Anyway, your fix worked just fine, and now the calling application
> (which plays the "Goodbye" message) has the problem with its "goodbye"
> audio, the next prompt in the chain.
> Â
> These are apps that have been in production with just Audio elements
> for 4 months now.  Suddenly I have to redesign it using your fix to
> _preserve the existing functionality_.  And the developer of the
> calling app will now have to modify his app to preserve existing
> functionality.
> Â
> Doesn't that seem strange to you?  I am very happy to have a fix
> (which I would not have without your advice!!), and may even write a
> custom audio element that does this for ALL audio elements going
> forward.  But so far, it seems as though this should never have
> worked, and yet it *is* working just fine right now in production.
> Â
> I'm curious - when (if ever) is it safe to use the Audio element?
> Â
> Thanks again,
> Chris
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2066152>
>
> or simply reply to this email.

Subject: RE: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) -
Replied by: Christopher Nagel on 24-03-2010 04:17:09 PM
Yes, this app is called via Subdialog Invoke.
 
I'll pass on your recommendation to our team, and also open up a TAC case.
 
Do you know of a VXML Property that I can set on the Audio elements to force the browser to wait for full playback?  Or maybe a cache setting on the gateway?
 
I am still concerned that this is working fine in production, and not knowing what causes the thing to fail now...
 
Thanks,
Chris
 

You say that the calling app is having this problem now. Are you using
SubdialogInvoke to call one Studio app from another? Or Application
Transfer?

I'd say a good rule of thumb is that in the last audio before you leave
a Studio App, you should wait for input. This would apply to App
Transfer, SubdialogInvoke, Subdialog_Return, CVP_Subdialog_Return, and
Hangup.

Subject: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP) - Gen
Replied by: Janine Graves on 24-03-2010 05:16:40 PM
There is no VoiceXML property that tells the gateway to play the item to
completion before returning back for the next page.
It's definitely worth requesting it.
Is your test environment different from your production? Is it
standalone vs. comprehensive? Or different versions of VxmlServer software?

Cisco Developer Community Forums wrote:
> Christopher Nagel has created a new message in the forum "General
> Discussion - All Versions":
>
> --------------------------------------------------------------
> Yes, this app is called via Subdialog Invoke.
> Â
> I'll pass on your recommendation to our team, and also open up a TAC case.
> Â
> Do you know of a VXML Property that I can set on the Audio elements to
> force the browser to wait for full playback?  Or maybe a cache
> setting on the gateway?
> Â
> I am still concerned that this is working fine in production, and not
> knowing what causes the thing to fail now...
> Â
> Thanks,
> Chris
> Â
> You say that the calling app is having this problem now. Are you using
> SubdialogInvoke to call one Studio app from another? Or Application
> Transfer?
>
> I'd say a good rule of thumb is that in the last audio before you leave
> a Studio App, you should wait for input. This would apply to App
> Transfer, SubdialogInvoke, Subdialog_Return, CVP_Subdialog_Return, and
> Hangup.
>
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2066220>
>
> or simply reply to this email.

Subject: RE: Re: New Message from Christopher Nagel in Customer Voice Portal (CVP)
Replied by: Christopher Nagel on 24-03-2010 07:24:35 PM

Is your test environment different from your production? Is it
standalone vs. comprehensive? Or different versions of VxmlServer software?

 
Both servers are standalone model, and using VXMLServer/admin/status, the following string is returned from both servers:
 
        Cisco Unified Customer Voice Portal VXML Server v7.0(2)
 
They both use the same media server and the same ICM instance (ICM is 7.2.4).  ICM Scripts are different but haven't changed.
 
The only other thing I did recently was move the element code from local elements to global elements (moved it from application/java/lib to common/lib/).  Perhaps there was an inadvertent threading dependency removed -- perhaps the "global" objects run in a separate address space from the individual apps?  (I don't mean to promote a possibly superstitious narrative as a technical explanation, but it's the closest I can come so far...)
 
Thanks,
Chris