Is there a way to divine the cause for the disconnect? I had used other platforms before where you could get either an 'application' or 'user' termination flag at the end of the call. 'Application' was where the call ran to completion, or suffered an error, and 'user' was a hangup or carrier interruption. Is this possible here? Our outbound application is quite long and we would like to see if people cloy and hangup, or take one of myriad program exit paths.
Of course I could add more JS to catch every possible path to disconnect, but are there any event or message variables buried in telephone.disconnect and error, that may help here? Thanks.
<catch event="connection.disconnect.hangup">
<prompt>Caught a hangup by the user.</prompt>
</catch>
The other type of connection.disconnect is a "connection.disconnect.transfer", when the user has been transferred unconditionally to another line and will not return.
The above code example will always throw the third block during any termination of the application due to the error prefix hierarchy. We seek to differentiate between all three types. We could forgo the telephone.disconnect catch a single disconnect (i.e. hangup), but we need to have a <DATA> element sent on cessation for all cases, so we would need all disconnect type tags. The <EXIT> tag could be used everywhere else to catch application exits, but our 7 scripts total 11,000 lines and would be a massive rework to find every application exit point. Any other possibilities in the platform to elucidate this information? Beyond our unique requirements however, I think the below would work for most people.
Thanks for the <throw> tip. I had not wanted to go through the effort, but did any way. Below is how we tracked application or user termination. The user is easy to catch and thus the default. However, if the application would normally call the <disconnect/> tag, we now call <throw event="app_end"/> to store an application end state. Finally, we catch the other two ways to get thrown out by the platform which are a <nomatch> failout and a <noinput> failout.
This example also replaces the default English failouts with Spanish based on the current application language selected.
Plum Support, are there any other platform disconnect points that occur by default beyond <nomatch> and <noinput>?
Other than IVR errors that might occur (i.e. error.badfetch), <noinput> and <nomatch> are the only other disconnect points for an IVR application (other than the application end).