The alternative to extensions.conf is extensions.ael. extensions.ael is extensions.conf written in a scripting
language called Asterisk Extensions Language (AEL). AEL is language maintained by Digium solely for
writing dial plans in Asterisk. While it is functionally equivalent to extensions.conf,AEL is syntactically much
more powerful and allows for greater flexibility in simple scripting and logical operations. If you’re familiar
with scripting in other languages, AEL can often be easier to pick up than the regular extensions.conf syntax extensions.ael can be used as a replacement for extensions.conf or have both used side by side.
extensions.ael is not in widespread use in today’s installations. However, due to its greater functionality, it
would not be surprising to see extensions.conf depreciated in future versions of Asterisk in favor of
extensions.ael.
Using AEL to Write Your Extensions
Everything that can be written in extensions.conf can be rewritten in extensions.ael. Let’s take our simple example from Example 3.1 and rewrite it into AEL.
Execution-wise this does the same exact thing Example 3.1 did. Asterisk answers the call, starts playing the
mainmenu sound file while waiting for the caller to enter digits.The caller can then either enter 100 and be
connected to the channel SIP/10 or 200 and be connected to the channel SIP/20.The caller is then hung up
on when the menu stops playing. Notice how, despite being mixed up a bit, there are still contexts,
extensions, and variables. In this case, however, the exten => EXTENSION, PRIORITY,
COMMAND (ARGS) syntax is completely scrapped. In extensions. ael, the exten => is removed, along
with any use of priorities. extension.ael followsmore of a line-by-line execution pattern the way
extensions.conf executes when the n priority is used. While this simplifies things so you don’t have to worry
about making sure every extension has the right priority, it provides a lack of flexibility in execution order
and Goto() statements. Let’s see what happens when we rewrite the code in Example 3.2.
Because we can’t specify the exact step to jump into in the s context, we need to create a label in the s
extension to tell the Goto() statement where to enter.The restart: label in the s context is the where the t
and i extensions jump to when they are done executing.This label needs to be explicitly specified within the s
context because there are no steps numbered within the context. Macros also function much in the same way
they do in extensions.conf.They are set up as if contexts, but have extra variables that can be passed to
them. In AEL, variables passed to the macro are not referred to as ${ARG1} through ${ARGX}. In AEL
you can assign them local variables names, which cuts down on the confusion factor when trying to
remember which values are assigned to a certain variable. Another difference in AEL is that the Macro()
command is not used when calling a macro. Instead, the macro’s name has an ampersand added in front of
it. Let’s add the std-exten macro to our AEL example to see how it fits in.
AEL is a very powerful language that allows for a much cleaner dial plan. It is still in heavy development, and may change in future Asterisk revisions, so it may not be quite ready for production yet. However, it is a very good idea to learn the mechanics of it because Asterisk may move toward it in the future.
language called Asterisk Extensions Language (AEL). AEL is language maintained by Digium solely for
writing dial plans in Asterisk. While it is functionally equivalent to extensions.conf,AEL is syntactically much
more powerful and allows for greater flexibility in simple scripting and logical operations. If you’re familiar
with scripting in other languages, AEL can often be easier to pick up than the regular extensions.conf syntax extensions.ael can be used as a replacement for extensions.conf or have both used side by side.
extensions.ael is not in widespread use in today’s installations. However, due to its greater functionality, it
would not be surprising to see extensions.conf depreciated in future versions of Asterisk in favor of
extensions.ael.
Using AEL to Write Your Extensions
Everything that can be written in extensions.conf can be rewritten in extensions.ael. Let’s take our simple example from Example 3.1 and rewrite it into AEL.
Execution-wise this does the same exact thing Example 3.1 did. Asterisk answers the call, starts playing the
mainmenu sound file while waiting for the caller to enter digits.The caller can then either enter 100 and be
connected to the channel SIP/10 or 200 and be connected to the channel SIP/20.The caller is then hung up
on when the menu stops playing. Notice how, despite being mixed up a bit, there are still contexts,
extensions, and variables. In this case, however, the exten => EXTENSION, PRIORITY,
COMMAND (ARGS) syntax is completely scrapped. In extensions. ael, the exten => is removed, along
with any use of priorities. extension.ael followsmore of a line-by-line execution pattern the way
extensions.conf executes when the n priority is used. While this simplifies things so you don’t have to worry
about making sure every extension has the right priority, it provides a lack of flexibility in execution order
and Goto() statements. Let’s see what happens when we rewrite the code in Example 3.2.
Because we can’t specify the exact step to jump into in the s context, we need to create a label in the s
extension to tell the Goto() statement where to enter.The restart: label in the s context is the where the t
and i extensions jump to when they are done executing.This label needs to be explicitly specified within the s
context because there are no steps numbered within the context. Macros also function much in the same way
they do in extensions.conf.They are set up as if contexts, but have extra variables that can be passed to
them. In AEL, variables passed to the macro are not referred to as ${ARG1} through ${ARGX}. In AEL
you can assign them local variables names, which cuts down on the confusion factor when trying to
remember which values are assigned to a certain variable. Another difference in AEL is that the Macro()
command is not used when calling a macro. Instead, the macro’s name has an ampersand added in front of
it. Let’s add the std-exten macro to our AEL example to see how it fits in.
AEL is a very powerful language that allows for a much cleaner dial plan. It is still in heavy development, and may change in future Asterisk revisions, so it may not be quite ready for production yet. However, it is a very good idea to learn the mechanics of it because Asterisk may move toward it in the future.
No comments:
Post a Comment