System information

${NUMBER}
The number being requested.
${IPADDR}
The IP address to connect to.
It is generally safest to statically configure the hostname, rather than
make use of the ${IPADDR} variable. The ${IPADDR} variable will some-
times reply with an address in the private IP space, which is unreachable
from the Internet.
With our mapping configured, let’s create a simple dialplan context against which we
can perform lookups for testing. We’ll make this more dynamic in “Controlling Re-
sponses” on page 516.
In extensions.conf, we can add the following on both systems:
[RegisteredDevices]
exten => 1000,1,NoOp()
With our dialplan and mappings configured, we need to load them into memory from
the CLI:
*CLI> dialplan reload
*CLI> module reload pbx_dundi.so
-- Reloading module 'pbx_dundi.so' (Distributed Universal Number
Discovery (DUNDi))
== Parsing '/etc/asterisk/dundi.conf': == Found
We can verify the mapping was loaded into memory with the dundi show mappings
command:
toronto*CLI> dundi show mappings
DUNDi Cntxt Weight Local Cntxt Options Tech Destination
extensions 0 RegisteredDe NONE SIP dundi:${SECRET}@172.16.0.
With our simple dialplan and mappings configured, we need to define the mappings
each of our peers is allowed to use. We’ll do this in the next section.
Using Mapping Contexts with Peers
With our mappings defined in the dundi.conf file, we need to give our peers permission
to use them. Control of the various mappings is done via the permit, deny, include, and
noinclude options within a peer definition. We use permit and deny to control whether
the remote peer is allowed to search a particular mapping on our local system. We use
include and noinclude to control which peers we will use to perform lookups with in
a particular mapping.
512 | Chapter 23: Distributed Universal Number Discovery (DUNDi)