[Home]

Summary:ASTERISK-01602: spool outgoing failed call
Reporter:geisj (geisj)Labels:
Date Opened:2004-05-12 18:36:41Date Closed:2011-06-07 14:10:34
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:A call is placed in the spool outgoing directory with
SetVar values in the file.

The call then fails due to busy etc ....
The same context is used to look for "failed" extension
and execute from there. If an AGI is ran at that time
NONE of the SetVar values are passed to the AGI.

This is not correct as the any SetVar values should be
passed to the failed AGI script.
Comments:By: Mark Spencer (markster) 2004-05-12 19:47:14

Obviously not a "major" bug but a minor one.b

By: Mark Spencer (markster) 2004-05-13 16:10:20

Can you confirm you still have the problem with cvs head?  I'm looking at the code and it looks like it properly sets the variables.

By: geisj (geisj) 2004-05-13 16:25:12

I am using asterisk-0.9.0 and I am not getting the SetVar values passed.
Is that different than cvs head?

By: Mark Spencer (markster) 2004-05-13 16:35:40

Please use the directions at http://www.asterisk.org to download and run CVS head of Asterisk.  This problem appears to already have been fixed in that release.  If for any reason it isn't feel free to re-open this bug.

By: geisj (geisj) 2004-05-25 10:16:56

I grabbed the v1_0stable on 5/24/04 and tried this again.

I use the following script to place a call in the outgoing directory.

echo > /tmp/call
echo "Channel: Zap/g1/999999" >>  /tmp/call
echo "Context: smvoice-dialout" >> /tmp/call
echo "Extension: 999999" >> /tmp/call
echo "Priority: 1" >> /tmp/call
echo "setvar: agi_dwc_record_num=55" >> /tmp/call
cp /tmp/call /var/spool/asterisk/outgoing
rm -f /tmp/call

My context for smvoice-dialout is:

[smvoice-dialout]
exten => 999999,1,agi,smvoice|-digium_asterisk

exten => failed,1,agi,smvoice|-digium_failed


When the call is placed I let it ring and do not answer it.
Eventually the smvoice -digium_failed gets called but I cannot
read the agi_dwc_record_num value.

I am using the T100P card connected to my phone switch. My phone
switch is setup so any call coming from the T1 will just ring on my extension.
Which works fine.

My whole application is working nicely under asterisk just not for
when a call fails. I need to know when a call fails as I might want to
then dial a different number than the first number to attempt to reach
the person someplace else.

Is there something I am not doing right? I just need to be be able to
read the setvar values on a failed call attempt.

Thanks,

By: Malcolm Davenport (mdavenport) 2004-05-25 10:27:55

You need to verify that this is a problem in Asterisk HEAD, not just the stable branch.  Please follow the instructions at www.asterisk.org to check out the development version.

By: Mark Spencer (markster) 2004-05-25 11:04:19

I just checked and I am able to use the following test.call file:

Channel: Zap/2
MaxRetries: 0
Context: default
Extension: s
Priority: 1
SetVar: file1=/tmp/to

And the following failed extension:

exten => failed,1,NoOp(${file1})

to clearly indicate that variables are properly handled:

*CLI>     -- Attempting call on Zap/2 for s@default:1 (Retry 1)
May 25 10:00:50 NOTICE[39246768]: channel.c:1592 __ast_request_and_dial: Unable to request channel Zap/2
   -- Executing NoOp("OutgoingSpoolFailed", "/tmp/to") in new stack
May 25 10:00:50 NOTICE[39246768]: pbx_spool.c:235 attempt_thread: Call failed to go through, reason 0
show version
Asterisk CVS-05/25/04-09:56:31 built by root@dhcp-34 on a i686 running Linux
*CLI>

and I tested both -stable and -head.

By: Mark Spencer (markster) 2004-05-25 11:05:40

To be sure this is clear -- in order to see variables of this sort you MUST use the "GET VARIABLE <foo>" syntax.  They are *NOT* passed to you as agi_foo like callerid and other special variables are.

By: geisj (geisj) 2004-05-25 11:26:14

I just grabbed the HEAD instead of v1_0stable.

I tried the same situation above and it still exists...

Jerry