05-31-2018 03:44 AM
I Observed , Hotevent's Strings got changed with VVB .
below is the list i Observed,
Is there a document or something , where i can find a complete list of changed events ?
HotEventName | Event String in 9.5 | Event String in 11.6 |
---|---|---|
NoResourceError | error.noresource | error.badfetch.http |
CallDisconnect | telephone.disconnect.hangup | connection.disconnect.hangup |
VXML Application Debug Logs for disconnect Event :-
------ Request HTTP Arguments with IOS Browser------
Parameter Name = "audium_vxmlLog" Parameter Value #0 = "|||audio_group$$$initial_audio_group^^^0"
Parameter Name = "audium_hotevent" Parameter Value #0 = "CallDisconnect"
------ Request HTTP Arguments with VVB------
Parameter Name = "audium_vxmlLog" Parameter Value #0 = "|||audio_group$$$initial_audio_group^^^0"
Parameter Name = "audium_type" Parameter Value #0 = "connection.disconnect"
Parameter Name = "audium_action" Parameter Value #0 = "hangup"
--------- VoiceXML Response --------
Solved! Go to Solution.
05-31-2018 06:43 AM
Hi - I just tested this workaround on my 11.6 vvb and indeed if you connect your HotEvent element to an AppTransfer element that sends the call to a simple Studio app named Exit that has a CVP_Subdialog_Start connected to a CVP_Subdialog_Return, then it catches the connection.disconnect.hangup event by executing the app transfer, and doesn't cause an infinite loop.
I'm posting a couple of snapshots.
06-01-2018 02:15 AM
Probably impossible to find in the forum history so this is probably the one.
06-01-2018 03:51 AM
Got Reply from TAC On this.
Pasting here, so that it will be helpful for other Folks in community.
Looking through the details of the case and the defect CSCve28300, please note that this an enhancement defect which is not currently being fixed in any of the releases and incorporation of this is not there in immediate roadmap of the product. To share additional details about this defect, This issue is not a bug as per Cisco documentation for Hot Event. Also the Hot event description clearly mentions a NOTE about not to use telephone.disconnect and connection.disconnect for hotevent.
Our development team believes that adding this enhancement may help handle other scenarios and hence we have this enhancement defect filed.
05-31-2018 05:05 AM
You could try connecting to an app transfer element when you catch the disconnect. I have not tried it but it's one of the few ways that don't cause the disconnect event
Sent from my Verizon 4G LTE smartphone
05-31-2018 06:43 AM
Hi - I just tested this workaround on my 11.6 vvb and indeed if you connect your HotEvent element to an AppTransfer element that sends the call to a simple Studio app named Exit that has a CVP_Subdialog_Start connected to a CVP_Subdialog_Return, then it catches the connection.disconnect.hangup event by executing the app transfer, and doesn't cause an infinite loop.
I'm posting a couple of snapshots.
05-31-2018 07:54 AM
Thanks Janine, work-around did work with app transfer.
but with App transfer, i need to send all data to new app , whatever i was sending back to ICM.
I tried with subdialog invoke , but no luck
How ever i will follow up with TAC on BUG CSCve28300
Appreciate Your quick help, You Rock
05-31-2018 07:58 AM
In what way are you sending data to ICM? The ICM Script aborts at the
same time the VXML Server app is notified of the disconnect.
05-31-2018 08:32 AM
I was trying to use CVPSubdialogreturn from Exit application, but looks like , call is just getting hanged up there.
i tried to send back "disconnect" back to ICM and release call there. but it looks like it won't work.
05-31-2018 08:00 AM
You could create an end of call java component to determine if the call
ended with a hangup, and miimc what the CVP_Subdialog_Return does, it
sends a last vxml page to the voice browser to return the caller_input
and/or FromExtVXML entries. I think Paul Tindall posted something
similar a few years ago.
05-31-2018 08:01 AM
You could create an end of call java component to determine if the call ended with a hangup, and mimc what the CVP_Subdialog_Return does by sending one final vxml page to the voice browser to return the caller_input and/or FromExtVXML entries. I think Paul Tindall posted something similar a few years ago.
06-01-2018 02:15 AM
06-01-2018 02:28 AM
thanks Paul for sharing this info.
10-23-2020 02:59 PM
Hello,
How do I apply this to my application? I created a .java file out of it and placed it in my application specific class folder. I didn't see any new elements created so I'm wondering how do I do this? Thank you for any info!
06-01-2018 03:51 AM
Got Reply from TAC On this.
Pasting here, so that it will be helpful for other Folks in community.
Looking through the details of the case and the defect CSCve28300, please note that this an enhancement defect which is not currently being fixed in any of the releases and incorporation of this is not there in immediate roadmap of the product. To share additional details about this defect, This issue is not a bug as per Cisco documentation for Hot Event. Also the Hot event description clearly mentions a NOTE about not to use telephone.disconnect and connection.disconnect for hotevent.
Our development team believes that adding this enhancement may help handle other scenarios and hence we have this enhancement defect filed.
06-05-2018 02:47 AM
hi Janine,
Workaround you suggested works fine with Entry App (1st Application invoked by VVB )
I have same problem in sub-dialog (Sub-Application). connection.disconnect.hangup hotevent is causing infinite loop.
its causing infinite loop at (subdialog return, HangUp) elements.
can you suggest some workaround ?
06-05-2018 06:04 AM
What are you trying to accomplish when handling/catching the hangup event?
Cisco SHOULD FIX THIS BUG (and it is a bug!), but until then the only
workaround will be to either of the following - neither of which is a
good option:
1) Use an App Transfer from within your subdialog app - but this must to
transfer to a different Studio app (ex, name it ExitSubdialog) app that
ends with a General/Subdialog_Return element (NOT a
Cisco/CVP_Subdialog_Return). And this Subdialog_Return must return the
name=value pairs that the SubdialogInvoke element in the main app is
expecting back - and you'll have to include something so the main app
will know the caller hung up.
Then in the main app, after returning from the SubdialogInvoke, you'll
have to check to see if you received the thing indicating the caller
hung up, and in that case assign whatever data was returned into
specific variables to return info to ICM, and then connect to the
CVP_Subdialog_Return element. This will (of course, ugh!) cause the
hangup event to occur, but now you're ready for it.
2) stop catching the telephone.disconnect.hangup use custom java written
as EndOfCall java component just like Paul Tindall posted on this link a
few days ago.
However, if your inside a Subdialog App, the calling app must be
expecting or checking for some information to be returned (do you have
anything configured in the SubdialogInvoke element's setting named
ReturnValue?). Because whatever is named in the ReturnValue setting must
be returned with that name. So some modification of Paul's code will be
required for the Subdialog app.
06-05-2018 06:46 AM
Many thanks Janine,
below is what i have got working.
1) Doing an APP Transfer , just hangs up in new app without any looping, and no licenses are held up.
2) I got rid of all Hot-Events for hangup and used onEndCall to determine if call was hung up ?
and using same class to do whatever i was doing through application after catching Hot-Event.
It works even if disconnect happens in (Subdialog app) , I get HangUp event in calling application .
Appreciate your Response janinegraves and Code Shared by ptindall
Thank You all!!!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide