[asterisk-users] Couple of questions about modules

[Tilghman Lesher]

On Saturday 03 July 2010 08:04:34 Gilles wrote:
> I have a couple of questions about using modules in Asterisk (1.4 or
> 1.6):
>
> 1. I'd like to experiment with extensions.lua: What happens if...
>
> - I leave extensions.conf enabled by not using "noload=pbx_config.so"
> in /etc/asterisk/modules.conf? Will the two dialplans get mixed
> together, with possibly unpredictable results?

No, contexts don't get mixed from two different sources.  You will, however,
get warnings on the console, and whichever module loads first will get
precedence as to creating a context.  If you avoid naming your contexts the
same, this will not be a problem.

> - I disable extension.conf by setting "noload=pbx_config.so"? Will
> Asterisk still work OK?

Yes.

> 2. in /usr/lib/asterisk/modules, what do the prefixes stand for?
> Aren't they all applications, ultimately?

No, they are not.

> app,

Dialplan applications

> cdr,

Call Detail Record backends control where CDRs get posted once a call ends.
Their action is implicit.

> chan,

You need a channel before the PBX will even start.

> codec,

These modules implement transcoding between various methods of coding audio
data.  They are implicitly used, based upon the codecs negotiated during each
leg of a call.

> format,

These modules allow saving particular codec-encoded audio to disk and reading
them back from disk.  These are used both for playing prompts and for
recording and playing back voicemail.

> func,

Dialplan functions are used within PBX logic to set or retrieve values.  They
are similar to variables, although they at their core execute code, instead of
simply storing or retrieving values.  They cannot be invoked outside of a
dialplan application executing (such as Set).

> pbx,

These modules trigger calls or execute dialplan steps after a call arrives.

> res       

Resource modules generally provide services to other modules, although they
may, in addition, provide additional applications or functions which support
the resource implemented.


For the more experienced:  yes, I am aware that some of these descriptions
are over-simplifications.  For example, these are all artificial restrictions
and any module may implement any backend it likes, but for the vast majority
of modules, these categorizations hold true.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org