[Home]

Summary:ASTERISK-00578: chan_local loses variables on spooled calls
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-11-26 15:56:09.000-0600Date Closed:2011-06-07 14:10:12
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:
Bug Description:
 It seems that SetVar isn't working with Local channels (at least) in spooled outgoing calls.

I create a call with this syntax:

Channel: Local/12125551212@test
CallerID: Nobody (3052009831)
Application: Hangup
SetVar: UNIQUE=0001

The context looks like this:

[test]
exten => _X.,1,Answer          
exten => _X.,2,NoOp(${UNIQUE})
exten => _X.,3,Hangup          

Output looks like this:

burn1*CLI>
   -- Attempting call on Local/12125551212@test for application Hangup() (Retry 1)
   -- Executing Answer("Local/12125551212@test-778e,2", "") in new stack
   -- Executing NoOp("Local/12125551212@test-778e,2", "") in new stack
   -- Executing Hangup("Local/12125551212@test-778e,2", "") in new stack
 == Spawn extension (test, 12125551212, 3) exited non-zero on 'Local/12125551212@test-778e,2'
   -- Executing System("Local/12125551212@test-778e,2", "/home/terri/perl/end_call.pl ") in new stack
 == Spawn extension (test, h, 1) exited non-zero on 'Local/12125551212@test-778e,2'
burn1*CLI>  

This is similar to the problem we worked on some time ago, where you added an "n" option to Dial for Local channels.  I have added the ",n" to the dialstring (Channel: Local/12125551212@test,n) and this is the result:

burn1*CLI>
   -- Attempting call on Local/12125551212@test,n for application Hangup() (Retry 1)
burn1*CLI>

A little worse, and it doesn't seem like anything is running through at all.  I have changed "Application: Hangup" to other apps with no changes, as well.


****** ADDITIONAL INFORMATION ******

This seems similar to http://bugs.digium.com/bug_view_page.php?bug_id=0000239   which was repaired with the "n" option for Dial'ing channels of type Local.  Not sure if it's related.

I have not tried with channels other than Local to see if variables are correctly passed through.
Comments:By: Mark Spencer (markster) 2003-12-01 09:00:39.000-0600

This isn't a bug.  You're setting a variable on the primary side of a local channel and trying to read it on the secondary side.
By: John Todd (jtodd) 2003-12-01 09:05:55.000-0600

After talking with mark, this is not the best way to do it.  In any case, this is not a bug since I seem to be looking on the wrong side of the channel for the variables.