[Home]

Summary:ASTERISK-13390: macro compatibility
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2009-01-18 16:27:55.000-0600Date Closed:2010-10-18 17:24:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In 1.4 AEL used to generate macro- prefix for all macro contexts and transform &m1() calls to Macro(m1). Now 1.6 Macro is deprcated and AEL generates Gosub instead and does NOT generate macro- prefix.

The problem is that if your dialplan calls AEL macros from regular dialplan - it will not work because AEL-generated macros do NOT have macro- prefix while Macro application will add it. For the same reason features like

myfeature => #,self,Macro,feature1

will not work anymore if feature1 is defined in the AEL.

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

My suggestion is: when Macro(xxx) is called, first try executing macro-xxx and if it is not found - try executing just xxx.

PS: if you guys deprecate Macro stuf, it would be good idea to remove all macros from sample dialplans too. Currently - it is full of macros.
Comments:By: Tilghman Lesher (tilghman) 2009-01-18 18:25:17.000-0600

Please open a discussion on the -dev list.  This is not the proper forum for this.
By: Dmitry Andrianov (dimas) 2010-10-14 17:31:10

Okay, the issue is 2 years old. I started a discussion on d-ev back then as I was told to - http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg35376.html

But it did not lead to any result.

Now after two years we are migrating to 1.6 and as I see the issue is still here. Asterisk is not backward compatible with old features.conf because of the issue. This is not documented anywhere and worst of all there is really no way of implementing what worked just fine in 1.4 with the new 1.6.2

1. You cannot use Macro in features.conf to call the AEL macro because it now requires Gosub
2. You cannot use Gosub in the features.conf because  only one argument can be passed to the features application while Gosub requires three. You cannot use neither coma (because feature attributes are already coma-separated) nor pipe (because it s not a valid argument separator anymore)
By: Tilghman Lesher (tilghman) 2010-10-18 00:06:21

Please review the current configs/features.conf.sample.  There are 3 syntaxes currently for specifying application arguments in features.conf.  I will include them here for brevity:

; The syntax for declaring a dynamic feature is any of the following:
;
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<AppArguments>[,MOH_Class]]
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,"<AppArguments>"[,MOH_Class]]
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]

The second two syntaxes are designed to allow you to use commas between arguments and not conflict with the commas in this configuration line.  Is this the syntax you are using?  Does this not work for some reason?
By: Dmitry Andrianov (dimas) 2010-10-18 15:23:02

Tilghman, well to be honest I was not aware of new syntax because UPGRADE document I checked didn't mention it. However the funny thing is that even not knowing the syntax, I tried it :) "just in case". And it did not work for me.

Right now I'm repeating my test and it looks like that I just misunderstood it not working completely with not working as I expected. The fact is that neither Goto nor Gosub worked. However now I see a section in the sample features.conf

;
; IMPORTANT NOTE: The applicationmap is not intended to be used for all Asterisk
;   applications. When applications are used in extensions.conf, they are executed
;   by the PBX core. In this case, these applications are executed outside of the
;   PBX core, so it does *not* make sense to use any application which has any
;   concept of dialplan flow. Examples of this would be things like Macro, Goto,
;   Background, WaitExten, and many more.


which does not really make sense to me because unlike Goto/Gosub the Macro application in fact WORKS. The only trick is that it MUST be regular dialplan macro, not an AEL one. And that is the main point in the original report - since AEL macro changed to use Gosub/return internally, it become impossible to call AEL macro using Macro application. Which in turn made them unusable from features.conf where they worked fine in 1.4.


So let me summarize once again:
1. Gosub does not work in applicationmap
2. Macro does work but Macro cannot be used to call AEL macro - Gosub should be used instead.
3. Gosub does not work in .... => see #1


By: Tilghman Lesher (tilghman) 2010-10-18 16:49:14

Yes, you're correct, the Macro application does not actually exit immediately; instead, it runs a separate PBX loop on the channel.

What it comes down to is that something might have worked prior to 1.6.2 as a happy accident, but it was not an intended feature.  The problem with Macro is that it takes up a large amount of stack, so subroutines in AEL, if implemented with Macro, could behave very badly, in that they could only go a certain depth before they either a) refused to go any deeper, or b) crashed Asterisk.  Obviously, for a higher-level language like AEL, neither of those outcomes are workable.

While I understand that you have a desire for a subroutine to run within the applicationmap, the fact is that you'll have to write the subroutine in traditional dialplan, instead of using AEL.  This, obviously, still works fine, and although Macro is deprecated, mainly due to the architectural problem in the previous paragraph, it is unlikely to ever be removed.  So, while we won't recommend that people use Macro in this way in the future, you can be reasonably certain that it will not disappear.