VoiceXML 2.1 Development GuideHome  |  Frameset Home

  Shorthand Exceptions  |  TOC  |  Transfer Events & Exceptions  

Disconnect Events

When a 'connection.disconnect.hangup' event gets thrown, it is essentially telling the application that
it detected a hangup, either from the caller, or the callee, in the case of an outbound calling application, or lastly, if the application executes the <disconnect> event.

When catching disconnect events, remember these three very important points:


  ANNOTATIONS: EXISTING POSTS
grvshr
5/27/2005 3:04 AM (EDT)
Hi,
I am running some sample scripts on the getVocal voiceXML Gateway. All these scripts speaks out correctly whatever is written in the <prompt> tag, but before user input the connections hangsup with the exeption

"05/27/05 11:56:47, Resource #2: GV_VXML::RunInnerLoop - got exception: telephone.disconnect.hangup"

These are the last few lines which appears on the voiceXML gateway:

Waiting for call Resource 2 :Waiting for Call #8
Call Terminated on Resource 2.
05/27/05 11:56:47, Resource #2: TranID 60.  Returned resource..
05/27/05 11:56:47, Resource #2: exit_element got "0"
05/27/05 11:56:47, Resource #2: GV_VXML::exit_element()
05/27/05 11:56:47, Resource #2: GV_VXML::executable_element - 15
05/27/05 11:56:47, Resource #2: GV_VXML::execute_content()
05/27/05 11:56:47, Resource #2: GV_VXML::DoEvent(telephone.disconnect.hangup)
05/27/05 11:56:47, Resource #2: GV_VXML::RunInnerLoop - got exception: telephone.disconnect.hangup
05/27/05 11:56:47, Resource #2: TranID 55 completed..
05/27/05 11:56:37, Resource #2: Playing queued segments.  TranID 54.
05/27/05 11:56:37, Resource #2: PromptManager::Play()
05/27/05 11:56:37, Resource #2: GV_VXML::do_recognition()
05/27/05 11:56:37, Resource #2: GrammarManager::EnableGrammar(01756EE0)
05/27/05 11:56:37, Resource #2: GrammarManager::EnableGrammar(039119C0)


thanks in advance
gaurav
JimMurphy
5/27/2005 8:08 AM (EDT)
gaurav,

If I understand your question correctly, you are testing this application on a platform other than the Voxeo platform. Is this correct?

Jim
grvshr
5/28/2005 2:46 AM (EDT)
Hi Jim,

Ya, I am using getVocal for application testing.
I am very new to VXML, So tell me which one should i use.......

Thanks
Gaurav
JimMurphy
5/28/2005 12:49 PM (EDT)
Gaurav,

Aside from the fact that different platforms implement VoiceXML differently, GetVocal can actually be considered a competing platform to Voxeo's platform.

We're glad to offer support and help you implement your applications, but we have to reserve this privilege to developers using our platform.

Using our platform is quite easy. Just re-visit http://evolution.voxeo.com in your web browser and sign up for a free development account. From there I'd suggest reviewing the quick-start guide, which gives a great overview of how to use your account manager.

Once signed up, you can log your support tickets through your account. This will let you keep a log of your tickets, rather than having to keep track of which document page you posted on.

I hope you understand our position. We simply have to reserve the privilege of support to those developing on our platform.

I hope that helps.

Jim
yossi_tamari
5/15/2006 8:53 AM (EDT)
There seems to be an error in the line:
<property name="timeout" value='1s"/>
(' instead of ").
MattHenry
5/15/2006 9:06 AM (EDT)


Thanks Yossi,

I'll have this fixed in a jiffy.

~Matt
emeijer
10/26/2006 6:46 AM (EDT)

What I want to accomplish is:

1 disconnect
2 submit a server side request
3 serverside initiates a token based outbound call to the same phone number (after some wait)

But what I noticed is that any operation I do after a <disconnect> element is not executed by the vxml browser anymore..... So my submit is never executed.

So I figured I have to catch the disconnect event like explained in this section... only to find out that the catch event is already called before the disconnect takes place... so I have no way to ensure that the current call is ended  before I submit the server request and establish a token intiated call to the same callerid.

Q: how can I execute commands after the <disconnect> element ?


B.t.w the fix for the typo mentioned above is still there.
MattHenry
10/26/2006 9:30 AM (EDT)


Hello Edwin,

A disconnect event should allow you to perfom one last <submit> action, assuming that you are catching it correctly. I might suggest that you place some <log> statements in your app and make sure that the event is getting caught properly, (the handler might be at the wrong scope). If this doesn't give you any clues, then feel free to send us some debugger output, and we would be happy to lend a hand.

Regarding the typo, this actually has been fixed, but we have not put up the most recent Build of the docs for public consumption yet.

Cheers,

~Matthew Henry
emeijer
10/27/2006 11:21 PM (EDT)
Thanks,

I guess I wasn't clear.... I do catch the event but the functionality I want is:

1 end current call
2 submit a server side request
3 serverside initiates a token based outbound call to the same phone number

So what I did is:

* a <catch> block to catch the hangup event. In this event I issue the submit and then <exit>.
* a <disconnect> in my regular form.

This all works and I catch the events, no problem. But the order of execution I am seeing (using log commands) and through the dbugger is:

1 hangup event is raised by <disconnect> tag
2 hangup event is caught by <catch> block
2 submit is issued by <submit> tag
3 exit is performed by <exit> tag

With this behavior, I can't end the call before the submit is issued and my serverside initiated (token-based) outbound call is already calling the user before he hangs up.

So my question is, is there any way  in vxml to perform a submit (or for that matter any other operation) *after* a <disconnect> tag.. the hangup event is sort of a pre-disconnect event...what I am hoping to find is a post-disconnect event.

Hope this is clearer.



VoxeoJoe
10/28/2006 12:08 AM (EDT)
Hello Edwin,

It's my understanding that the "disconnect" event is the final event, and will stop all processes.  However, perhaps the answer lies within the "submit".  I'm sure there's some server-side logic that could be put in place to delay when the "re-call" is placed?  How about a "break" element?


Sincerely,

Joe Gallina
Voxeo Corporation
emeijer
10/28/2006 2:12 AM (EDT)
Certainly; I can put in a sleep command at the server side and hold off on doing the outbound call until some reasonable time has passed by and I can reasonably assume the user has hung up by herself by that time.

But still I would prefer some post-disconnect event; one that I can catch and use to initiate some server side processing at a point in time it's guaranteed the ivr call  with the user has ended.... I don't like to keep the line open with the user any longer than I have to (I won't have unlimited ports...)

Michael.Book
10/28/2006 11:53 AM (EDT)
Hello,

The issue here is the difference between a near-end disconnect, fired when the VoiceXML session hangs up, and a far-end disconnect, when the end-user hangs up.  If you issue a <disconnect/>, the resultant event simply means the VoiceXML browser has ended the connection.  It does not indicated an action taken by the user.

Your idea to simply wait on the server-side, giving the user time to hang-up, will work.  But if you really want to know when the far-end disconnect occurs, just play an audio file while you wait for the user to hang-up.  I might suggest a "good bye," followed by a click and then silence for about 5-10 seconds.  If you really wanted to seal the deal, play an audio file of a dial-tone for another 5-10s after that.  If the end-user is still holding the phone, then it is safe to assume you will have to end the call.

I hope this helps...


Cheers,

~ Michael
puneetb
2/1/2008 12:16 PM (EST)
Hi,

When a call goes to the voice mail, I get "user.death" event and the call fails. I am unable to find "user.death" event in the documentation. What is this event and when is it thrown? This happens when the phone rings for about 30 seconds and as soon as it goes to the voice mail I see user.death event in the debugger output and also "connection.CONNECTION_FAILED". My expectation is that when the voice mail message plays, voxeo should consider the call as answered. Is this not the way it is?

Thanks.
Puneet Bansal
mikethompson
2/1/2008 2:30 PM (EST)
Hi Puneet,

An answer (even if by a voicemail) should definitely throw an answer event (connection.connected).  As you say user.death happens around 30 seconds, so I'm thinking you might be hitting the call timeout value.  Are you using VoiceXML.start to launch these calls?  As you may or may not know, VoiceXML outbound is really launched by a stock CCXML application under the covers.  This CCXML application has some default values for things like call timeout, which is probably what you're hitting after 30 seconds.  If after 30 seconds of attempting to connect, the call will end and throw a connection.failed.

Fortunately, we can pass in the "calltimeout" parameter with our session request via VoiceXML.start and adjust the value.  For example:

http://session.voxeo.net/VoiceXML.start?tokenid=blah&numbertodial=blah&calltimeout=60s

Try sending in this parameter and let me know if you get good results.

Hope this helps,
Mike Thompson
Voxeo Corporation
puneetb
2/4/2008 3:53 PM (EST)
Thanks Mike - passing in 'calltimeout' parameter worked. What is interesting however is that we were never passing the parameter earlier but we could still leave voice mail until a week back. Don't know what changed and where.

Puneet
mikethompson
2/4/2008 4:00 PM (EST)
Hi Puneet,

I'm glad you were able to implement this parameter and get your calls working.  As far as why the behavior changed for you, each destination is unique, in the sense that you never know how long it will attempt to connect before going to voicemail.  If the destination has remained the same throughout your testing, there may have been some changes beyond the Voxeo network which caused the destination to ring more than 30 seconds before voicemail picked up.  Nothing has changed on the Voxeo front which would affect call out times.

Best,
Mike Thompson
Voxeo Corporation
archie172
2/7/2008 1:42 PM (EST)
I'm trying to catch disconnect events and it's not working. I think I need more details on the statement "a voice recognition <field> absolutely must be present in order to successfully catch this event."

What do you mean by "present"? Just that the VXML contains a <field> element with a voice grammar? Or that the engine has to actually be inputting that <field> at the time the disconnect occurs? Or... ?

Can you give a simple recipie for taking any VXML script and ensuring that <error> tags will ALWAYS catch disconnected events, no matter when they occur (prior to the end of the script)?

In other words: we need a reliable way to get notified of premature disconnects, no matter when they occur.

For example, I tried adding a "dummy field" to the end of all my scripts (see example below), but it doesn't help.

Here is an example of a case that doesn't work. If you hang up while the prompt is playing, the <log> messages don't appear in the application debugger.

Thanks.

<?xml version="1.0"?>
<vxml xmlns="http://www.w3.org/2001/vxml" version="2.1">

  <error>
    <log expr="'***********************'" label="trace:?level=VD_INFO"/>
    <log expr="'CAUGHT ERROR: ' + _event" label="trace:?level=VD_INFO"/>
    <log expr="'***********************'" label="trace:?level=VD_INFO"/>
    <exit/>
  </error>

  <form>
    <block>
      <prompt>
        <audio src="someprompt2.au"/>
      </prompt>
    </block>
  </form>

  <!-- dummy field to ensure disconnect events are caught -->
  <form>
    <field name="_dummyField">
      <prompt/>
      <grammar>[(dummy grammar)]</grammar>
      <filled>
        <prompt/>
      </filled>
      <noinput>
        <disconnect/>
      </noinput>
    </field>
  </form>
</vxml>
mikethompson
2/7/2008 4:59 PM (EST)
Hey Archie,

The short answer is yes, you must be in a recognition state in order to catch the hangup.  If you have a <field> in your document, but the user hangs up in a prompt outside of the field, the hangup will not be caught.  As for the <error> handler, this will be caught regardless of whether or not you're in a valid recognition field.  As for proper hangup handling logic, the example above titled "WorkingExample.vxml" should guide you in the right direction.

Let me know if you have additional questions.

Best,
Mike Thompson
Voxeo Corporation
archie172
2/8/2008 6:05 PM (EST)
Mike,

Thanks for your reply.

I think I see why I am confused. This web site mentions two different disconnect events: "error.telephone.disconnect" (on the "General Exceptions and Error Types" page) and "connection.disconnect.hangup" (on this page). Which event will get thrown if the caller hangs up? Why are there two events for the same thing? Or are they different somehow? If so, how?

I'm guessing if the caller hangs up during the prompt in my script (above) then "connection.disconnect.hangup" is thrown, because my <error> tag is never executed, and according to your statement it would have caught a "error.telephone.disconnect" event. Is this correct?

Are there any reliable strategies for detecting a disconnect event anywhere in a script? Seems like a simple thing to want to do.

In any case, wouldn't it be considered a bug that disconnect events don't work outside of a voice recognition <field>? If so, are there plans to fix it?

Thanks.

mikethompson
2/8/2008 6:26 PM (EST)
Hello,

It looks like our documentation may be a bit outdated on this subject, as I have not seen error.telephone.disconnect get thrown before.  This being said, you only need to worry about connection.disconnect.hangup being thrown.

As far as strategies go, just always make sure you have a reco field active whenever you're prompting the user and you should be A-OK. :)

I'm going to speak with Engineering and see if I can get details for you regarding why we don't consider this to be a bug.

Stay tuned,
Mike Thompson
Voxeo Corporation
mikethompson
2/11/2008 3:40 PM (EST)
Hello,

I have some information for you regarding why we must have an active recognition field present in order to catch the hangup.  The short answer is, the VXML W3C spec defines this:

http://www.w3.org/TR/voicexml20/#dml4.1.8

4.1.8 Prompt Queueing and Input Collection

A VoiceXML interpreter is at all times in one of two states:

    * waiting for input in an input item (such as <field>, <record>, or <transfer>), or
    * transitioning between input items in response to an input (including spoken utterances, dtmf key presses, and input-related events such as a noinput or nomatch event) received while in the waiting state. While in the transitioning state no speech input is collected, accepted or interpreted. Consequently root and document level speech grammars (such as defined in <link>s) may not be active at all times. However, DTMF input (including timing information) should be collected and buffered in the transition state. Similarly, asynchronously generated events not related directly to execution of the transition should also be buffered until the waiting state (e.g. connection.disconnect.hangup).


Hope this helps,
Mike Thompson
Voxeo Corporation

login
  Shorthand Exceptions  |  TOC  |  Transfer Events & Exceptions  

© 2008 Voxeo Corporation  |  Voxeo IVR  |  VoiceXML & CCXML IVR Developer Site