This is normal.
The VXML parameters fetchaudio and fetchtimeout are valid during the call.
If you want to do something after a hangup - then you use the following "Call End Action" as descripted in the programming guide.
The issue is that if the caller hangs up while listening to the wav specified in fetchaudio, no events occur.
Hotevent connection.disconnect.hangup and On Call End java api do not triggered.
In other situations, it is normally triggered.
Therefore, the logic when the call is disconnected cannot be executed.
That is interesting. If that is the case, it sounds like a bug.
I would open a Cisco TAC case give them a simplified version (to reduce complexity) of your application where you can reproduce the issue and show that on a hang-up the Call End Action is NOT triggered.
And update us here on your progress!
Control is at the server while fetchaudio is playing which means that only the VB knows about the hangup. Only when you perform the next VoiceXML action will the lack of caller be detected. If you don't perform another VoiceXML operation then call end processing will only be triggered when the application timeout expires or the session is explicitly ended by the application. If you set the application timeout to 1 minute and do a test where your application doesn't serve the next document for at least 1 minute you should see call end processing kick in after that time. If it doesn't, then there is a defect.
But isn't it a bug even if above "works" as you have outlined?
Shouldn't VVB on a hang-up terminate the call on and update VXML server as soon as the call has been hung-up?
If you only get an notice that the call has been hung-up after a number of minutes (when the application timeout occurs) this might not be very useful?
The way it works is sub-optimal. The problem is that the VB has already submitted a request to the server for the next document and is playing audio while it waits for the server's response. The VB is doing exactly what you told it to do -- that the response will be probably be delayed and you should play audio to keep the caller happy. At the server side you're handling the request, doing whatever backend actions are required and introducing a synchronous delay. The VVB will terminate the call but its session has to hang around to allow any final processing to be performed with the server. You'd need to check with wireshark at exactly what point the event is sent to the server but the server won't process it while it's not doing voice interface things. That's why you'll typically get the message in the activity log that the session failure was due to processing taking too long.
I believe what Paul means is that at the time of the hang-up, the VVB server is waiting for a response a request (and while waiting for this response it is playing the fetch audio).
When the caller hangs up - since the VVB server is still waiting for a response for the request and it doesn't send a hangup update to the VXML Server. To me this is a design bug or as Paul says design is "sub optimal".
The problem is it is unlikely to be fixed. But what you CAN do is what Paul has outlined.
Reduce the Application Timeout to a figure which still makes sense for your app. When this times out - the Call End Event SHOULD be called. Whether this is too late or not for your app I don't know?
Performing asynchronous operations at the caller-side and back-end is awkward. I don't know what your exact use case is but if you're long-polling at the back-end and expecting that request to be interrupted by hangup, that isn't going to happen. If you want to detect caller-side and back-end events in parallel then you have to perform the back-end request from VoiceXML. You might want to try using a subdialog to access the back end with fetchaudio enabled. That should report back hangup immediately to the calling thread.