Hang up call during fetchaudio play in CVP

[lee yongbeom]

Hang up call during fetchaudio play in CVP, no event occurs.
How can I get hangup event?

[pk88]

Hello Lee,

Can you let me know what are you trying to do? If you want to perform some action upon call hang-up, you can use CVP call-end API. hope this helps.

[lee yongbeom]

Hi pk88,

Like the hold/unhold function of UCCX, I implemented fetchaudio and fetchtimeout in CVP and it works well.
But, if I hang up the call while the wav file set in fetchaudio is playing, no event is generated in the hangup or call-end API.
Is it normal or abnormal?

[Gerry O'Rourke]

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.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/cvp_12_6/programming/guide/ccvp_b_1261-programming-guide-for-cisco-unified-cvp-vxml-server-and-cisco-unified-call-studio/ccvp_b_1261-programming-gui...

Gerry

[lee yongbeom]

Hi Gerry,

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.

Lee

[Gerry O'Rourke]

Lee,

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.

• Simplified Call Studio app with just the bare config to reproduce the issue
• Exact Steps on how to reproduce the issue

And update us here on your progress!

Gerry

[ptindall]

Lee,

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.

[Gerry O'Rourke]

Paul,

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?

[ptindall]

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.    

[lee yongbeom]

Hi ptindall,

You mean, VVB sends a disconnet event to CVP, but CVP cannot process it even if it receives an event while performing backend actions.
In other words, the event cannot be detected.
Is that right?

Lee

[Gerry O'Rourke]

Lee,

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?

Gerry

[lee yongbeom]

Hi Gerry,

I understand.
But, the event for the call should be processed immediately.
Reducing the timeout doesn't seem like a good idea.

Lee

[Gerry O'Rourke]

Lee,

That is the way it is at the moment.

You can try to create a a feature enhancement to change how the VVB / CVP behaves for this use case.

If so - contact your Cisco account manager, open a TAC case, otherwise I believe you will have to try the method described by Paul above.

Gerry

[ptindall]

Lee, 
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.

[pk88]

You will have to write a Call-End class file in your VXML application. This class will be triggered once the caller hangs up or application completes its execution.