[Voiceglue] A CRITICAL entry

[James Green]

Doug,

We have no involvement in Asterisk beyond sending an HTTP request for the call to be placed. Control is handed to the dialplan and in turn to VoiceXML. Our use of DeadAGI is only in the 'h' priority, and is to call the "hangup" part of our application.

Now a brief update covering today.

We have this morning switched our test server to a bare-metal machine running Ubuntu 9.04 with Asterisk 1.6.1.0 (latest voiceglue of course).

We are pointing calls at the old test machine (the VMware instance). A dial plan on this box merely listens for silence then sends back DTMF tones to match human responses.

With 15 simultaneous calls we have still managed to get Voiceglue to hang at 100% CPU. That said, it takes longer (in the order of 100s of calls before a hung voiceglue surfaces).

We have also had Voiceglue literally exit from the process list once.

Current testing is based on 1,000 voice messages. We are now strace-ing both phoneglue and asterisk each run.

The one hang of Voiceglue we managed (prior to strace) seems to suggest something occurred (nothing obvious), followed by a delay of a few seconds, then a fetch timeout. Call it a stutter if you like. There is some argument that VoiceGlue continued logging other channels activity prior to finishing.

Soon as I have something more concrete I shall follow up.

James

-----Original Message-----
From: voiceglue-bounces at voiceglue.org [mailto:voiceglue-bounces at voiceglue.org] On Behalf Of Doug Campbell
Sent: 05 June 2009 19:30
To: General discussion about voiceglue
Subject: Re: [Voiceglue] A CRITICAL entry

> Asterisk logs for this call uploaded: http://pastebin.com/m407b4b91

Everything looks fine until:

[Jun  4 13:32:16] VERBOSE[20750] logger.c:     -- Executing [h at mjogrb171_VG:1] NoOp("Local/1154 at confirm-call-56d4,1", "2BA2AE3C5A083D61A4FFAEA5EDB97F85 - AGI status - FAILURE") in new stack

This corresponds to the same timestamp in the voiceglue logs where the AGI GetDigit ("WAIT FOR INPUT") got a -1 response, a failure.

So, why is Asterisk failing?  What Asterisk are you using?
Is anything else doing anything to this channel under Asterisk?

> As a best practice, should VoiceXML applications capture disconnects 
> if we do our app
 > clean-up in the h section of the dial plan?

The VXML specification requires that a connection.disconnect event always be thrown when the call is disconnected from the VXML session.  Voiceglue supports this by interpreting an AGI connection drop as a disconnect.
Thus, you should be able to handle a call disconnect from both the VXML connection.disconnect event and from any Asterisk mechanism.
Not catching the connection.disconnect event in VXML should also be benign, and that session should clean up normally.

> We took ours out (under the mistaken impression that should the callee 
> hang up, VoiceXML
 > should be destroyed) and instead performed clean-up in the hangup section of the dial plan  > (sounds logical!), it appeared to help, then we started seeing mass hangs of the VoiceGlue  > process under load at random, with DeadAGI listed for each channel.

DeadAGI?  Voiceglue doesn't even use DeadAGI.
Perhaps the Asterisk logs simply mean that the AGI session has finished.

Doug Campbell
_______________________________________________
Voiceglue mailing list
Voiceglue at voiceglue.org
http://www.voiceglue.org/mailman/listinfo/voiceglue

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.56/2161 - Release Date: 06/07/09 17:53:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.339 / Virus Database: 270.12.56/2161 - Release Date: 06/08/09 06:01:00
-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.339 / Virus Database: 270.12.57/2163 - Release Date: 06/08/09 12:30:00