AEL Multiple patterns : EXTEN/CDR messed up after jump/macro

Asterisk Asterisk Support
1

Hello,
I am new to Asterisk, and using a small home installation. I have two outgoing SIP trunks, and Dial each one as needed in my AEL dialplan. My problem is that I have two patterns ( _[0[068]. and _[13].) that are handled in exactly the same way:

  • first I tried to define the steps in one pattern, and jump from one to the other

_[0[068]. =>
{
// Do stuff here
}
_[13]. =>
{
jump _[0[068].;
}

  • then I tried using a macro

_[0[068]. =>
{
&macroCall(${EXTEN});
}
_[13]. =>
{
&macroCall(${EXTEN});
}

The problem is that in both cases, the DST field of the CDR contains the pattern ("_0[068]." or “s”), and not the dialed number.

What would be the proper way to handle two or more patterns that are processed in exactly the same way?

I am using Asterisk 1.8.3.

Best regards,

2

In the original extensions.conf language, you could probably GoTo a high numbered priority that used a very general wild card match. As long as the priority range didn’t overlap that used for any other patterns, there should be no conflict, even though it would match so other priority 1 patterns.

3

You can also do this with GoSub, and that should be the method used to replace, deprecated, macros, in the current extensions.conf.sample file. I’m not sure if there was a workaround for macro in AEL.

4

I’ve read that macros in AEL in implemented using gosub, but I’m not sure.

In find the original syntax nearly un: you have to repeat exten and the pattern on each line (use?), have to use gotos (ugh hard-to-read spaghetti code) … AEL is much more structured (yeah I’m a software developer).

I’ve thought about matching something like _X. and then doing all the branching / processing inside, but isn’t that kinda ugly in Asterisk?

5

Ok, so I dug a bit deeper after the gosub comment and I found these :

dslreports.com/forum/r258534 … trangeness

viewtopic.php?f=1&t=7560&start=0

issues.asterisk.org/bug_view_ad … g_id=15214

The last link in particular makes me afraid… Is that an official stance that AEL is unusable??? :frowning:

6

It means that, unless some third party provides a patch to change it, AEL macros produce CDRs of limited value; that’s a lot weaker than “useless”.

Note that Call Event Logging is the preferred method of generating billing for all non-trivial dial plans.

7

Ok, maybe “useless” was indeed a bit strong. I do consider my dialplan to be trivial however :frowning:
Thanks for the tip about CEL, I’m going to look into that then.

8

I’m probably simply going to use the “userfield” in the CDRs, since everything else looks like it’s working.

Why is the DST field of the CDRs read only? Now I’ll have to run an update on the DB, replacing DST by userfield… It would be so much better directly in the dataplan IMHO.