| VoiceXML 2.1 Development Guide | Home | Frameset Home |
|
<disconnect> event.<disconnect> element will throw an 'connection.disconnect.hangup' event, while the <exit> element will NOT throw this event. Make certain you know the difference when coding your application.<exit> out of the application. Otherwise, you may see a number of errors stating 'error.semantic.fatal Trying to listen to user after a hangup.' While these are non-fatal, and non-application affecting, it can cause quite a bit of confusion from a debugging perspective. As such, we recommend that the following snippet be your template for catching disconnect events:
<catch event="connection.disconnect.hangup">
<submit next="MyCleanupPage.jsp" namelist="var1 var2"/>
<exit/>
</catch>
<field> absolutely must be present in order to successfully catch this event. If there is not an existing <field>, we can create a 'dummy' field with a garbage grammar to allow this event to be properly caught:
<?xml version="1.0" encoding="UTF-8"?>
<vxml version = "2.1">
<catch event="connection.disconnect.hangup">
<submit next="MyCleanupPage.jsp" namelist="var1 var2"/>
<exit/>
</catch>
<form>
<block>
<prompt>
Thanks for calling, you may now hang up.
</prompt>
</block>
</form>
</vxml>
<?xml version="1.0" encoding="UTF-8"?>
<vxml version = "2.1">
<catch event="connection.disconnect.hangup">
<submit next="MyCleanupPage.jsp" namelist="var1 var2"/>
<exit/>
</catch>
<form>
<field name="dummy">
<property name="timeout" value="1s"/>
<!-- set the 'noinput' timeout to 1 second -->
<prompt>
Thanks for calling, you may now hang up.
</prompt>
<!-- create a 'garbage' grammar that will never, EVER get a match -->
<grammar> [(kathy bates is really hot)] </grammar>
<filled>
<prompt> no way this will ever happen, babycakes. </prompt>
</filled>
<noinput>
<disconnect/>
</noinput>
</field>
</form>
</vxml>
| ANNOTATIONS: EXISTING POSTS |
grvshr
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| There seems to be an error in the line:
<property name="timeout" value='1s"/> (' instead of "). |
|
MattHenry
|
|
|
Thanks Yossi, I'll have this fixed in a jiffy. ~Matt |
|
emeijer
|
|
|
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
|
|
|
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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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
|
|
| 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 |
|