Hi,
In CVP script I have a custom Java class at the background of a decision element that waits for a specified timeout to meet a condition before making a decision. The Java code does not return untill the condition is met or the specified timeout expires. The problem is that if caller hangs up while the CVP script is executing the decision element which is running background Java code, CVP license port and session is not released untill Java code returns. So it consumes a port unnecessarily. I have a custom Java code handler for 'onEndCall' as well in the application, but that is also not called before the decision element Java code returns. CVP forum recommends not to catch 'connection.disconnect.hangup' and 'telephone.disconnect.hangup' events through hot events, because that also causes the license port to not releae.
Can any one suggest a solution please?
 
Thanks 

Hemal,
Thanks for your guidance. I have tried the solution you recommended but I could not solve the problem. My scirpt is not exaclty what you proposed and the java class at the back end of hot event is not there to set the flag. Here is what I have tried.
1) I have catched hangup event using hot event followed by a hangup node, but hot event is not triggered when the java code is executing and caller hangs up. I thought that this is due to the reason that control is not returning into the script. To solve this I have made the wait in java code small and put another decision element to check that java code is complete and loop back into the java code. But even this does not end the script and release port when the caller hangs up.
2) Hot event back end java class does not have access to session so I could not set the flag. But I am looking into some work around that can set some flag(may be VEvent can do this). Any idea how this can be done. But this will only help if the above problem is solved.

 
Hi Janine,
Thank you very much for your reply. VXML debug logs show that Gateway is not sending the hangup event to VXML server when caller hangs up while call flow is in Java. But looking at the logs I find that actually the VXML server does not send reply to a VXML request made from Gateway before hang up event occured, when it enters into the decision element with Java code at backend till the Java code ends(After 1 minute of wait). So in my opinion it is not the Gateway that is holding the hangup event rather it is VXML server that is not sending the response for a pending VXML request from Gateway when it enters into the Java code. Thus the Gateway does not send the hang up event till VXML server sends VXML response for the pending page request. Which occurs when the Java code completes. I have attached call flow and logs for three scenarios to make things more clear. They are explained below.
1) A normal call flow with only an audio element that ends normally when the audio prompt is complete.
2) A normal call flow with only an audio element that ends by catching the hot event when user hangs up before completing the audio.
3) A call flow with a decision element with Java code at backend. Audio prompt is being played as background music using fetchaudio property of audio element. Call does not end on hang up.
You can look from attached logs that in case 2 the call ended immediatley with hang up. But in case 3 although I hung up the call after 10 seconds the call remained there for complete 1 minute that is the wait time of Java code and activity logs will show you that the call was looping back into the Java code.
I do not know how to fix this, so any help from you will be very valuable.

Thanks

Attachments:

The VoiceXML gateway can only talk back to the server via the submit so it can't send the disconnect event if control is currently server-side until it gets the next document.  If it's executing a document which is non-blocking because it's just playing audio then it's already performed the submit and control is now at the server-side and in this case in an extended wait for back-end processing.  If the gateway is executing a document that's blocking then it can report the disconnect event immediately but then you can't do the server-side processing.  Bit of a no-win situation unfortunately.
Detecting immediate disconnect at the server-side isn't straightforward but I'll suggest a couple of things anyway for the more adventurous to try.
1.  Execute custom VoiceXML that will talk to a back-end servlet directly using the <cisco-data> element.  You can use fetchaudio on the element while it's waiting for the response.   As the VoiceXML document is blocking, the disconnect event should be processed immediately and submitted.   I've not tried it personally so no guarantees.
2. Use the Gateway Services API at the back-end to detect call disconnection at the gateway for the particular call-id, terminate/clean-up the back-end processing, return control to the gateway by sending the next VoiceXML doc and pick up the VoiceXML hangup event.
 

Why don’t you try and invalidate the session after you set the flag. If you are calling the class as action element you have access to the invalidateSession() method.
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, March 12, 2013 5:02 AM
To: cdicuser@developer.cisco.com
Subject: New Message from shaban qaiser in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: End custom back ground Java code execution if caller hangs up

shaban qaiser has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Janine,
Thank you very much for giving a new direction. But unfortunately the above change in the script and Java is not helping even. At first it looked to me as well that checking the status flag and looping back into an audio element with a wait message should help in detecting the hang up at worst by a delay of sleep time (5 seconds) in the decision element and the hangup event should be returned from Gateway when I enter back into the audio element with wait message but to my surprise that is not working. Either I am missing something serious or there is some limitations in my call flow. I am still looking into it and if I find any issue with my script I will update.

Paul,
Your description of the problem is perfect. The control lies with the VXML Server and there remains a pending VXML page request on VXML server side when script control is into the Java code at the back end of the decision element. We were trying to reduce that time by looping back into the audio element periodically as suggested by Janine, but surprisingly that is not working even. I will dig more on your suggestions and share the findings.

Thanks
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/community/-/message_boards/view_message/12912876 or simply reply to this email.

You can catch the hangup event and set a flag in the session to check that.
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, March 12, 2013 8:14 AM
To: cdicuser@developer.cisco.com
Subject: New Message from shaban qaiser in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: End custom back ground Java code execution if caller hangs up

shaban qaiser has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Hemal,

I need to stop my execution when the caller hangs up. I did not understand how can I invalidateSession in my decision element when I do not that caller has hung up. If you have any idea how can I detect in my decision element that caller has hung up then please share and I will try that. The flag Janine and I were talking about was to check whether Java code has completed its work or not periodically and loop back to an Audio element so that control switches between VXML Gateway and VXML server and hot event be triggered.

Please correct me if I am not following things in the right direction.

Thanks
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/community/-/message_boards/view_message/12918212 or simply reply to this email.

K, let me catch up with the other suggestions. I will run some tests myself and see. Meanwhile can you tell me what your java code is doing. What is waiting on and how long does that take ?

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, March 12, 2013 8:30 AM
To: cdicuser@developer.cisco.com
Subject: New Message from shaban qaiser in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: End custom back ground Java code execution if caller hangs up

shaban qaiser has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Hemal,

As you suggested in your first post I have put a hot event to catch hang up in script. But the problem is that hot event catching hang up is not triggering when script is in decision element with Java code executing and caller hangs up. The next idea was that this may be due to the reason that control is not returning back into script, so to exclude that possibility some other solutions are tried which are explained in details with findings in above posts. Please have a look at those posts and if you find some mistake or have some idea kindly share.

--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/community/-/message_boards/view_message/12918514 or simply reply to this email.

I looked at the code. What is the business logic behind this.  I do not see you calling a webservice, making some backend call etc. Just waiting for 16 secs, checking if the total time elapsed is not 60s. So why not just play the audio of 60s duration or if you need to split the audio to total 60s.
Unless there is some other backend processing happening, what is the point of going in this loop. Are you playing any fetchaudio while you are trying to make this wait in the decision element ? Depending on your business logic there may be a better way to do this.
Don't get into the thread business, unless you really know what you are doing, you can bring down your webserver down if you have tonnes of calls spawning threads
and you do not manage this correctly.

Hemal, Shaban will be doing a web service call in his java. For now,
he's removed it for simplicity and has replaced it with a delay, until
the problem with not receiving the hangup while the java is executing is
fixed.

Hi Paul, Where is the description and/or javadocs of using the Gateway Services API? -- Janine Graves