Hangup detection on outbound call

[adriannaude]

Hi,

I have a VXML dialogue that has been extensively tested via inbound calling. It contains a number of forms and each one has a
<catch event="connection.disconnect.hangup">
trap set. These all then branch to a common event hander. This setup works very well.

I have started using this same dialogue in outbound calls and it no longer detects hangup events. I realise there is an inherent delay caused by the telephony network when an outbound call is hung-up by the recipient, but even when I insert long delays (120s) a hangup is not detected.

Is there anything I can do to detect hangup other than trap "connection.disconnect.hangup" in an outbound call?

(These calls are being made from the UK platform).

Adrian Naude

[adriannaude]

As a further qualification to this issue, I have tested this to both POTS and mobile networks and the mobile networks seem to return hangups reliably, where as the POTS networks are inconsistent.

Adrian Naude

[support]

Hello,

What exactly are you seeing in the IVR call log for this IVR application? Is the IVR call is never being disconnected at all, or if the IVR platform is never throwing the connection.disconnect event? Could you please check the IVR call log to see if there is an error at the end one of these "never ending" calls. If there is and error please provide it as well as a simple VoiceXML file that demonstrates the error.

Regards,
Plum Support

[adriannaude]

Hi,

Thanks for responding.

The calls are terminating normally and I don't have any loop conditions occuring. I have written a simple application that I have used both inbound and outbound.

The app looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<!-- ********************* -->
<!-- Global properies -->
<property name="inputmodes" value="dtmf"/>
<property name="interdigittimeout" value="5s"/>
<!-- ********************* -->

<form id="doDialog">

<block>
<prompt bargein="false">This is the start of the pause<break time="30s"/>Pause complete</prompt>
<log>Dialogue completed normally</log>
<exit/>
</block>
<catch event="connection.disconnect.hangup"><goto next="#doHangup" /></catch>

</form>

<form id="doHangup">
<block>
<log>Dialogue completed with hangup</log>
<exit/>
</block>
</form>
</vxml>

When I call this inbound and hang up at the first prompt message I can see the disconnect event in the log:

impl->dxi->waitForPlayEOD() detected a disconnect. Abandoning queued data.
Line disconnect detected. Abandoning queued audio data.
received event: connection.disconnect.hangup

When I do the same outbound to a land line and hang up in the same place in the dialogue the call ends normally:

Previously playing audio (if any) has finished
Newly queued prompts are now being played
Dialogue completed normally
VXI::exit_element()
ng audio (if any) has finished
Previously playing audio (if any) has finished
Call End Event
Ending session

The problem is that it is not consistent. If I then make the same outbound call to a mobile then the hangup event is thrown correctly. I have also seen the hangup event thrown when calling landlines, though infrequently.

I have tried experimenting by calling landline numbers that have ADSL, or that are supported by network providers other than BT, but I haven't been able to find a pattern.

Adrian Naude

[support]

Hello,

There can be subtle differences between IVR inbound and IVR outbound calls. In this case the difference seems to be that the IVR system is executing your <exit> tag as soon as the system has completed queing the tts audio. The good news is that this is an easy fix.

The <exit> tag is designed to be an override for disconnect handlers. The idea being that if the user reaches a certain dialog in the VoiceXML script you may want to bypass your disconnect handler code for some reason. If you want to formally end the dialog while still allowing for the disconnect handler to be executed you should use the <disconnect> tag instead of <exit>. The problem you are experiencing is that you have a false assumption. VoiceXML is a sudo executed language, the order of certain tags does not make any difference. For example in your IVR code having a <prompt> followed by a <log> followed by an <exit> will not necessarily force the browser to perform those tasks in order. The following order of events is likely to take place:

1. The log tag is executed.
2. The prompt audio is created.
3. The prompt audio begins playing.
4. The exit tag is executed.
5. The platform waits for audio to finish.
6. The call is dropped without throwing connection.disconnect.hangup.

Below is your IVR code fixed to properly throw a disconnect.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<!-- ********************* -->
<!-- Global properies -->
<property name="inputmodes" value="dtmf"/>
<property name="interdigittimeout" value="5s"/>
<!-- ********************* -->

<form id="doDialog">
	<block>
		<prompt bargein="false">This is the start of the pause<break time="30s"/>Pause complete</prompt>
		<log>Dialogue completed normally</log>
		<disconnect/>
	</block>
	<catch event="connection.disconnect.hangup"><goto next="#doHangup" /></catch>
</form>

<form id="doHangup">
	<block>
		<log>Dialogue completed with hangup</log>
		<exit/>
	</block>
</form>

</vxml>

Regards,
Plum Support

[adriannaude]

Hi,

Thanks for the response, but I'm not sure that this has identified the issue. If you insert a <disconnect> as you have suggested then this causes a hangup event to be thrown even when the call has completed normally, which isn't what I need. What I want to be able to do is to trap a hangup issued mid-call by the recipient. As I mentioned earlier, this happens sometimes, but not consistently.

My actual application is a lot more complex than the example I have posted here. The initial call via the Plum outbound PHP is to a servlet that dynamically generates a root document. The root document then dyanamically loads the main dialogue as a sub-dialogue. The main dialogue uses <return> rather than <exit> once it has completed. I could try and create a static version of all this if it would be of assistance.

Adrian Naude

[support]

Hello,

The comments above still hold true. The one thing you will always have to contend with is that the final dialogue is not guaranteed to execute and throw a disconnect if it has an <exit> tag. Your best bet is to have a root document or an IVR application level scope disconnect handler. This is guaranteed to catch any disconnect events that are thrown by the IVR system.

You should use the <exit> tag if you do not want the disconnect handler to be thrown. If you do not see a connection.disconnect event it is because you have executed an <exit> tag. Otherwise the event will be thrown, just be aware of the execution behaviors of the IVR system.

Regards,
Plum Support

[adriannaude]

Hi,

Yes, I understand your comment about the <exit> tag and my application doesn't contain any. It does have a root document and does have a global catch for the hangup event, and this works because it fires sometimes. The point I am trying to make is that not every hangup event that occurs at the telephony level on an outbound call is being reflected in the platform and I wondered if there is anything I can do at the VXML level to alter this?

Adrian Naude

[support]

Hello,

That is correct. The IVR platform will always throw a connection.disconnect event if the script that it is executing does not do one of the following:

1. Execute an <exit> tag. Again, there is no guarantee that the <exit> tag will not be executed while the last prompt is playing.

2. Trigger a fatal error. If you have bugs in your IVR application that trigger error.badfetch or a "max disconnect counter" error then the disconnect event handler will not be executed.

If you can come up with an IVR example that falls outside of these two cases then it is an issue with our IVR platform, otherwise that is the expected behavior. The only way to guarantee that even a last prompt is being executed is to put it in a field rather than a block. This IVR code should allow us to detect a hangup rather than processing the <exit> tag.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<!-- ********************* -->
<!-- Global properies -->
<property name="inputmodes" value="dtmf"/>
<property name="interdigittimeout" value="5s"/>
<!-- ********************* -->

<form id="doDialog">
    <field type="digits">
        <prompt bargein="false" timeout="10ms">This is the start of the pause<break time="30s"/>Pause complete</prompt>
    </field>
    <filled>
        <throw event="nomatch"/>
    </filled>
    <catch event="nomatch noinput">
        <log>Dialogue completed normally</log>
        <exit/>
    </catch>
    <catch event="connection.disconnect.hangup">
        <goto next="#doHangup" />
    </catch>
</form>

<form id="doHangup">
   <block>
      <log>Dialogue completed with hangup</log>
      <exit/>
   </block>
</form>

</vxml>

The code above will not execute the <exit> tag until after the field has finished detecting input. This guarantees that if a disconnect that occurs before input is detected then a connection.disconnect will be thrown. If there is no input then the <log> and <exit> occur.

Regards,
Plum Support