Summary: | ASTERISK-01602: spool outgoing failed call | ||
Reporter: | geisj (geisj) | Labels: | |
Date Opened: | 2004-05-12 18:36:41 | Date Closed: | 2011-06-07 14:10:34 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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 |