VoIP Mailing List Archives :: View topic - [asterisk-users] Any reason to *not* use AEL? (Also, MixMonitor q)

Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community

[asterisk-users] Any reason to *not* use AEL? (Also, MixMonitor q)

Goto page Previous 1, 2

VoIP Mailing List Archives Forum Index -> Asterisk Users

View previous topic :: View next topic

Author

Message

sherwood.mcgowan at gm...
Guest

Posted: Tue Jun 03, 2008 12:01 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

Andrew Kohlsmith (lists) wrote:

Quote:

On June 3, 2008 09:21:48 am Jay Moore wrote:

Quote:

I am building a new Asterisk server here at the office, and I'm
wondering if there are any downsides to creating my dialplan with AEL.
It seems more intuitive (to me), but I'm not sure if there are any
pitfalls I need to be aware of first.

Community support is the big one. Personally I think AEL's a solution looking
for a problem. Ask Leif Madsen about what he can make a standard dialplan
do. Smile

-A.

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

Not really, I find it much simpler to perform logic, I can do anything
in standard dialplan that I can in AEL, I just prefer it to be more
easily managed and not have to write exten => [extenpattern],[prio or
n].... before every single line.

--
Sherwood McGowan
VoIP / Telecom Solutions
sherwood.mcgowan at gmail.com

atis at iq-labs.net
Guest

Posted: Tue Jun 03, 2008 12:38 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

On Tue, Jun 3, 2008 at 7:59 PM, Sherwood McGowan
<sherwood.mcgowan at gmail.com> wrote:

Quote:

Atis Lezdins wrote:

Quote:

On Tue, Jun 3, 2008 at 6:23 PM, Sherwood McGowan
<sherwood.mcgowan at gmail.com> wrote:

Quote:

Tilghman Lesher wrote:

Quote:

On Tuesday 03 June 2008 09:03:16 Sherwood McGowan wrote:

Quote:

The only thing you need to watch for is falling into some basic
"traps" like calling ${EXTEN} from within a switch (the AEL compiler
uses sw-xxxx extensions for case instances).

This should already be solved in the latest release. The extension will
be saved in an alternate variable, and references to ${EXTEN} below
a switch will be converted to use that alternate variable.

Actually, no they're not converted to the alternate variable. Guess I
should contact Murf, because now that I think of it I had mentioned this
to Murf before I think.

They are on 1.4.19, but this works invisible to user:

exten => _X.,76,Set(~~EXTEN~~=${EXTEN})
exten => _X.,77,Goto(sw-98-${DIALSTATUS}|10)
exten => _X.,78,NoOp(Finish switch-if-if-local_dial-95-97-9 Cool

exten => _X.,79,Goto(103)

Regards,
Atis

Yes, but if you call ${EXTEN} within the switch, it does not (at least
on my Asterisk 1.4.20 system) jump transparently to ${~~EXTEN~~} it
still attempts to use ${EXTEN}.

[new_test]
exten => _X.,1,Goto(sw-24-${CHANNEL}|10)
exten => _X.,2,NoOp(Finish switch-new_test-24)
exten => _sw-24-.,10,Goto(${EXTEN}|tests)
exten => sw-24-,10,Goto(sw-24-.|10)

AEL Code:
context new_test {
_X. => {
switch(${CHANNEL}) {
default:
jump ${EXTEN},tests;
}
}
}

Well, exactly the same code on 1.4.19 parser (aelparse -d -n -w -q
extensions.ael):

[new_test]
exten => _X.,1,Set(~~EXTEN~~=${EXTEN})
exten => _X.,2,Goto(sw-90-${CHANNEL}|10)
exten => _X.,3,NoOp(Finish switch-new_test-90)
exten => _sw-90-.,10,Goto(${~~EXTEN~~}|tests)
exten => sw-90-,10,Goto(sw-90-.|10)

Could it be that you have old version of "aelparse" in system?
However, i think I have seen that "make install" copies it to system.

Regards,
Atis

--
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

sherwood.mcgowan at gm...
Guest

Posted: Tue Jun 03, 2008 1:11 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

Steve Murphy wrote:

Quote:

On Tue, 2008-06-03 at 09:33 -0500, Sherwood McGowan wrote:

Quote:

Mindaugas Kezys wrote:

Quote:

Does Asterisk Realtime support AEL?

Regards,

Mindaugas Kezys

http://www.kolmisoft.com

*From:* asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] *On Behalf Of
*Gonzalo Servat
*Sent:* Tuesday, June 03, 2008 5:07 PM
*To:* Asterisk Users Mailing List - Non-Commercial Discussion
*Subject:* Re: [asterisk-users] Any reason to *not* use AEL? (Also,
MixMonitor q)

On Tue, Jun 3, 2008 at 10:41 AM, Eric Wieling <eric at fnords.org
<mailto:eric at fnords.org>> wrote:

AEL in 1.4 was the first version of AEL that most people consider
"stable". Since not many people uses AEL, you won't get nearly as
much
(if any) community support compared to if you are using the
non-AEL syntax.

Really? Why would anyone want to write a dialplan using the old
extensions.conf syntax? That sort of syntax personally drove me nuts
(and real messy). I've got my entire dialplan on AEL (using Asterisk
1.6.0).

-

Quote:

Not sure what you mean, but if you mean realtime dialplan, then no, you
can't use AEL for that. However, we might wish to see if Murf knows if
this can be done.

extensions.conf is like assembler; it's a very strict, line per
instruction
format, 4 fields per line, that is able to be read in by normal config
file
parsers. It is in turn compiled into the internal asterisk data
structures.

AEL is more free form. Storing the dial plan in AEL format in a db
would
be pretty useless. However, the extensions.conf isn't so bad in a db, as
it still has the 4 columns, row per instruction sort of format.

But in general, I have to ask, as a programmer, if it's really, really
a good idea to store code in a db. The dialplan is a mixture of both
dialplan code and data, in the form of extensions.

But storing dialplan "code", as in a sequence of application calls,
is a slow way to execute your dialplan code.

And storing patterned extensions (extensions starting with _, like
_10XXXXXXXXX or whatever), is a really slow way to match pattern
extensions. My advise to everyone is this: Realtime is great, but
don't store extension patterns in there, and don't store your dialplan
code in there, if you can help it. It'd be much better to use your db
to store 'exact' extension data. Trying to find the best pattern match
via realtime is excruciatingly slow, as it calls up every extension in
the db for
that context, and then decides on the best match. DB's do a great
job at storing large numbers of uniquely keyed data that you can find
via
exact matches. So, use a general exten patten in your dialplan, and
then do a DB() lookup from there.

If you find a bug in your dialplan code, you've got to change it in two
places, in the realtime db, and you'd best have it in your original
source as well, in case you need to reload/recover your db or whatever.
A DB is a lousy source-code control system. Use cvs or subversion or git
or something to store your dialplan code instead. That way, you can back
out change sets, etc, and track your changes in a much more practical
way.

Just my two cents.

murf

------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

I personally agree completely, I HATE using RealTime extensions when I
don't have a need for the ability to modify the dialplan without
reloading (almost NEVER needed)

--
Sherwood McGowan
VoIP / Telecom Solutions
sherwood.mcgowan at gmail.com

sherwood.mcgowan at gm...
Guest

Posted: Tue Jun 03, 2008 1:35 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

Quote:

Phew! Thanks!

I was just about to go look this up and see if I forgot something.

murf

------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

Yeah I just re-did the make install (don't know why it didn't update
before) but the resulting code is now

exten => _X.,1,Set(~~EXTEN~~=${EXTEN})
exten => _X.,2,Goto(sw-24-${CHANNEL}|10)
exten => _X.,3,NoOp(Finish switch-new_test-24)
exten => _sw-24-.,10,Goto(${~~EXTEN~~}|tests)
exten => sw-24-,10,Goto(sw-24-.|10)

--
Sherwood McGowan
VoIP / Telecom Solutions
sherwood.mcgowan at gmail.com

mkezys at gmail.com
Guest

Posted: Tue Jun 03, 2008 1:47 pm Post subject: [asterisk-users] Any reason to not use AEL? (Also, MixMoni

Thank you for your opinion. Then my question would follow: how to build human-friendly system which will use GUI and lets user use that system without messing with .conf files?

atis at iq-labs.net
Guest

Posted: Tue Jun 03, 2008 2:12 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

On Tue, Jun 3, 2008 at 9:47 PM, Mindaugas Kezys <mkezys at gmail.com> wrote:

Quote:

That should be good. Personally I use db for DID detection, NA
handlers, etc. So, main logics is kept in AEL,
but DB contains configurable parts.

Quote:

Also: Any reason to "not" use extensions.conf?

What AEL can do better then extensions.conf?

Many people still use vi. Because it can do everything what they want. Same
here with extensions.conf.

Write in more high level language - use loops, if's, blocks of code.
For sure you can use Assembler but how many people nowdays do that?
You can optimize code a little, but it just takes more time in
development and maintenance.

Regards,
Atis

Quote:

Regards,
Mindaugas Kezys
http://www.kolmisoft.com

Quote:

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
bounces at lists.digium.com] On Behalf Of Steve Murphy
Sent: Tuesday, June 03, 2008 9:02 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Any reason to *not* use AEL? (Also,
MixMonitor q)

On Tue, 2008-06-03 at 09:33 -0500, Sherwood McGowan wrote:

Quote:

Mindaugas Kezys wrote:

Quote:

consider

Quote:

"stable". Since not many people uses AEL, you won't get nearly

Quote:

much
(if any) community support compared to if you are using the
non-AEL syntax.

Really? Why would anyone want to write a dialplan using the old
extensions.conf syntax? That sort of syntax personally drove me

nuts

Quote:

(and real messy). I've got my entire dialplan on AEL (using

Asterisk

Quote:

1.6.0).

-

Quote:

Not sure what you mean, but if you mean realtime dialplan, then no,
you can't use AEL for that. However, we might wish to see if Murf
knows if this can be done.

extensions.conf is like assembler; it's a very strict, line per
instruction format, 4 fields per line, that is able to be read in by
normal config file parsers. It is in turn compiled into the internal
asterisk data structures.

AEL is more free form. Storing the dial plan in AEL format in a db
would be pretty useless. However, the extensions.conf isn't so bad in a
db, as it still has the 4 columns, row per instruction sort of format.

But in general, I have to ask, as a programmer, if it's really, really
a good idea to store code in a db. The dialplan is a mixture of both
dialplan code and data, in the form of extensions.

But storing dialplan "code", as in a sequence of application calls, is
a slow way to execute your dialplan code.

And storing patterned extensions (extensions starting with _, like
_10XXXXXXXXX or whatever), is a really slow way to match pattern
extensions. My advise to everyone is this: Realtime is great, but don't
store extension patterns in there, and don't store your dialplan code
in there, if you can help it. It'd be much better to use your db to
store 'exact' extension data. Trying to find the best pattern match via
realtime is excruciatingly slow, as it calls up every extension in the
db for that context, and then decides on the best match. DB's do a
great job at storing large numbers of uniquely keyed data that you can
find via exact matches. So, use a general exten patten in your
dialplan, and then do a DB() lookup from there.

If you find a bug in your dialplan code, you've got to change it in two
places, in the realtime db, and you'd best have it in your original
source as well, in case you need to reload/recover your db or whatever.
A DB is a lousy source-code control system. Use cvs or subversion or
git or something to store your dialplan code instead. That way, you can
back out change sets, etc, and track your changes in a much more
practical way.

Just my two cents.

murf

--
Steve Murphy
Software Developer
Digium

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

--
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

sherwood.mcgowan at gm...
Guest

Posted: Tue Jun 03, 2008 4:52 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

Mindaugas Kezys wrote:

Quote:

Thank you for your opinion.

Then my question would follow: how to build human-friendly system which will
use GUI and lets user use that system without messing with .conf files?

From my experience large and complicate systems can't be effectivelly
managed without Realtime and I see no way how to put AEL into DB. Maybe it's
possible?

We are storing "exact-match" info into DB and all _X., etc stuff we have in
extensions.conf. So no speed issues with large systems.

Also: Any reason to "not" use extensions.conf?

What AEL can do better then extensions.conf?

Many people still use vi. Because it can do everything what they want. Same
here with extensions.conf.

Regards,
Mindaugas Kezys
http://www.kolmisoft.com

Quote:

Mindaugas Kezys wrote:

Quote:

consider

Quote:

"stable". Since not many people uses AEL, you won't get nearly

Quote:

nuts

Quote:

(and real messy). I've got my entire dialplan on AEL (using

Asterisk

Quote:

1.6.0).

-

Not sure what you mean, but if you mean realtime dialplan, then no,
you can't use AEL for that. However, we might wish to see if Murf
knows if this can be done.

extensions.conf is like assembler; it's a very strict, line per
instruction format, 4 fields per line, that is able to be read in by
normal config file parsers. It is in turn compiled into the internal
asterisk data structures.

AEL is more free form. Storing the dial plan in AEL format in a db
would be pretty useless. However, the extensions.conf isn't so bad in a
db, as it still has the 4 columns, row per instruction sort of format.

But in general, I have to ask, as a programmer, if it's really, really
a good idea to store code in a db. The dialplan is a mixture of both
dialplan code and data, in the form of extensions.

But storing dialplan "code", as in a sequence of application calls, is
a slow way to execute your dialplan code.

And storing patterned extensions (extensions starting with _, like
_10XXXXXXXXX or whatever), is a really slow way to match pattern
extensions. My advise to everyone is this: Realtime is great, but don't
store extension patterns in there, and don't store your dialplan code
in there, if you can help it. It'd be much better to use your db to
store 'exact' extension data. Trying to find the best pattern match via
realtime is excruciatingly slow, as it calls up every extension in the
db for that context, and then decides on the best match. DB's do a
great job at storing large numbers of uniquely keyed data that you can
find via exact matches. So, use a general exten patten in your
dialplan, and then do a DB() lookup from there.

If you find a bug in your dialplan code, you've got to change it in two
places, in the realtime db, and you'd best have it in your original
source as well, in case you need to reload/recover your db or whatever.
A DB is a lousy source-code control system. Use cvs or subversion or
git or something to store your dialplan code instead. That way, you can
back out change sets, etc, and track your changes in a much more
practical way.

Just my two cents.

murf

--
Steve Murphy
Software Developer
Digium

jsneerin at gmail.com
Guest

Posted: Tue Jun 03, 2008 5:52 pm Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

On Tue, Jun 3, 2008 at 8:21 AM, Jay Moore <jaymoore at accu-com.com> wrote:

Quote:

We use AEL exclusively here. We run a small call center with both
inbound queues and outbound sales calls. All told around 3000 calls a
day flow through the system; some inbound, some outbound, some
extension to extension.

No pitfalls that I'm aware of, other than all of the NoOp's it
generates. This leads to a very busy CLI if you run at verbosity level
3 or higher.

-James

gavin.henry at gmail.com
Guest

Posted: Wed Jun 04, 2008 4:45 am Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

What about using RealTime LDAP in 1.6? That woudl be much faster than a RDBMS.
2008/6/3 Sherwood McGowan <sherwood.mcgowan at gmail.com>:

Quote:

Mindaugas Kezys wrote:

Quote:

Mindaugas Kezys wrote:

Quote:

consider

Quote:

"stable". Since not many people uses AEL, you won't get nearly

Quote:

nuts

Quote:

(and real messy). I've got my entire dialplan on AEL (using

Asterisk

Quote:

1.6.0).

-

Not sure what you mean, but if you mean realtime dialplan, then no,
you can't use AEL for that. However, we might wish to see if Murf
knows if this can be done.

extensions.conf is like assembler; it's a very strict, line per
instruction format, 4 fields per line, that is able to be read in by
normal config file parsers. It is in turn compiled into the internal
asterisk data structures.

AEL is more free form. Storing the dial plan in AEL format in a db
would be pretty useless. However, the extensions.conf isn't so bad in a
db, as it still has the 4 columns, row per instruction sort of format.

But in general, I have to ask, as a programmer, if it's really, really
a good idea to store code in a db. The dialplan is a mixture of both
dialplan code and data, in the form of extensions.

But storing dialplan "code", as in a sequence of application calls, is
a slow way to execute your dialplan code.

And storing patterned extensions (extensions starting with _, like
_10XXXXXXXXX or whatever), is a really slow way to match pattern
extensions. My advise to everyone is this: Realtime is great, but don't
store extension patterns in there, and don't store your dialplan code
in there, if you can help it. It'd be much better to use your db to
store 'exact' extension data. Trying to find the best pattern match via
realtime is excruciatingly slow, as it calls up every extension in the
db for that context, and then decides on the best match. DB's do a
great job at storing large numbers of uniquely keyed data that you can
find via exact matches. So, use a general exten patten in your
dialplan, and then do a DB() lookup from there.

If you find a bug in your dialplan code, you've got to change it in two
places, in the realtime db, and you'd best have it in your original
source as well, in case you need to reload/recover your db or whatever.
A DB is a lousy source-code control system. Use cvs or subversion or
git or something to store your dialplan code instead. That way, you can
back out change sets, etc, and track your changes in a much more
practical way.

Just my two cents.

murf

--
Steve Murphy
Software Developer
Digium

There's not really a reason to NOT use extensions.conf, other than it's
spaghetti code, and not as readable. You CAN write a gui that alters the
*.ael files, that's how a lot of the GUIs work for extensions.conf, they
modify the file. Putting your dialplan into a database is needless in
about 90% of cases I've run across.

--
Sherwood McGowan
VoIP / Telecom Solutions
sherwood.mcgowan at gmail.com

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

--
http://www.suretecsystems.com/services/openldap/

tzafrir.cohen at xorco...
Guest

Posted: Wed Jun 04, 2008 5:19 am Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

On Wed, Jun 04, 2008 at 10:45:13AM +0100, Gavin Henry wrote:

Quote:

What about using RealTime LDAP in 1.6? That woudl be much faster than a RDBMS.

If performance is such a major issue, why not use explicit queries?

realtime has overhead even in extensions/proiorities where it is not used.

--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir

gavin.henry at gmail.com
Guest

Posted: Wed Jun 04, 2008 5:42 am Post subject: [asterisk-users] Any reason to *not* use AEL? (Also, MixMoni

2008/6/4 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:

Quote:

On Wed, Jun 04, 2008 at 10:45:13AM +0100, Gavin Henry wrote:

Quote:

What about using RealTime LDAP in 1.6? That woudl be much faster than a RDBMS.

If performance is such a major issue, why not use explicit queries?

realtime has overhead even in extensions/proiorities where it is not used.

Static will always be faster than any Realtime. But as I understand
it, some things should be kept out of it.

Display posts from previous:

	VoIP Mailing List Archives Forum Index -> Asterisk Users	All times are GMT - 5 Hours Goto page Previous 1, 2
Page 2 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum