System information

Configuring extconfig.conf
Our next step is to tell Asterisk what information to load via realtime and what tech-
nology to use. Using the extconfig.conf file, we have the option of loading several mod-
ules dynamically (and we can also load files statically). For more information about
Asterisk realtime, see “Using Realtime” on page 368.
For our example, we’re going to configure the sipusers and sippeers dynamic realtime
objects to load our SIP peers from LDAP. In the following example, we have a line
like this:
ldap,"ou=people,dc=shifteight,dc=org",sip
We’ve specified three arguments. The first is ldap, which is the technology we’re going
to use to connect to our realtime object. There are other technologies available, such
as odbc, pgsql, curl, and so on. Our second argument, enclosed in double quotes,
specifies which database we’re connecting to. In the case of LDAP, we’re connecting
to the object-unit people within the domain shifteight.org. Lastly, our third argument,
sip, defines which template we’re using (as defined in res_ldap.conf) to map the realtime
data to the LDAP database.
Additionally, you can specify a fourth argument, which is the priority.
If you define multiple realtime objects, such as when defining queues or
sippeers, you can utilize the priority argument to control failover if a
particular storage engine becomes unavailable. Priorities must start at
1 and increment sequentially.
To define the use of sipusers and sippeers from the LDAP server, we would enable
these lines in extconfig.conf:
sipusers => ldap,"ou=people,dc=shifteight,dc=org",sip
sippeers => ldap,"ou=people,dc=shifteight,dc=org",sip
Configuring sip.conf for realtime
These steps are optional for configuring SIP for realtime, although you will likely expect
things to work in the manner we’re going to describe. In the sip.conf file, we will enable
a few realtime options that will cache information into memory as it is loaded from the
database. By doing this, we’ll allow Asterisk to place calls to devices by simply looking
at the information stored in memory. Not only does caching make realtime potentially
more efficient, but things like device state updates simply can’t work unless the devices
are cached in memory.
A peer is only loaded into memory upon registration of the device or
placing a call to the device. If you run the command sip reload on the
console, the peers will be cleared from memory as well, so you may need
to adjust your registration times if that could cause issues in your system.
LDAP Integration | 439