[asterisk-users] Dial() Macro option error in 1.4.15

[Mark Michelson]

Anthony Messina wrote:
> On Thursday 06 December 2007 12:42:42 pm Mark Michelson wrote:
>> Anthony Messina wrote:
>>> After updating to 1.4.15, I have the following issue:
>>>
>>> When I try to use the "M" macro option in the Dial() option, I get the
>>> following in the console:
>>>
>>> -- Executing Dial("Zap/1-1",
>>> "Zap/g2/w5051234|60|M(set-userfield^local)KT") -- Called g2/w5051234
>>> -- Zap/3-1 answered Zap/1-1
>>> [Dec  6 12:10:58] ERROR[19496]: app_dial.c:1541 dial_exec_full: Unable to
>>> start autoservice on calling channel
>>> [Dec  6 12:10:58] ERROR[19496]: app_dial.c:1553 dial_exec_full: Could not
>>> find application Macro
>>>     -- Hungup 'Zap/3-1'
>>>
>>> The requested Macro does exist in extensions.conf as:
>>> [macro-set-userfield]
>>> ; Set CDR userfield to value defined in Dial() command
>>> exten => s,1,Set(CDR(userfield)=${ARG1})
>>> exten => s,n,MacroExit()
>>>
>>> This always worked for me with 1.4.14 and I'm not sure how to begin to
>>> get this fixed.  Any help is appreciated.  Thanks.
>> I think this was due to a change in the way autoservice is handled. I think
>> that if you were to upgrade to SVN revision 90432 or later, this error will
>> not occur.
>>
>> Mark Michelson
> 
> Thank you.  The strange this is, in the first example, I was pulling the 
> extension from MySQL RealTime and got the error.
> 
> If, however, I place a fake extension (2289) that dials the same number in 
> extensions.conf (for testing):
> 
> exten => 2289,1,Dial(Zap/g2/w5051234|60|KM(set-userfield^local)T)
> 
> it works as follows and the macro is executed properly:
> 
> -- Starting simple switch on 'Zap/1-1'
> -- Executing [2289 at mss-chicago:1] Dial("Zap/1-1", "Zap/g2/w5051234|60|
> KM(set-userfield^local)T") in new stack
> -- Called g2/w5051234
> -- Zap/3-1 answered Zap/1-1
> -- Executing [s at macro-set-userfield:1] Set("Zap/3-1", "CDR(userfield)=local") 
> in new stack
> -- Executing [s at macro-set-userfield:2] MacroExit("Zap/3-1", "") in new stack
> -- Hungup 'Zap/3-1'
> 
> Is there some sneaky difference between the two methods of matching the 
> extension that might cause this?

The difference most likely is that in the code path executed by retrieving the 
extension from realtime autoservice was started on the channel, and then when 
Dial() was called, autoservice was started on the channel again. By putting the 
"fake" extension in, autoservice was only started once, and so the error fixed 
in revision 90432 would not show itself.

Mark Michelson