Page 337 - Asterisk™: The Future of Telephony

locality=Toronto
stateprov=ON
country=CA
email=support@toronto.example.com
phone=+19055551212
;
; Specify bind address and port number. Default is 4520
;bindaddr=0.0.0.0
port=4520
entityid=FF:FF:FF:FF:FF:FF
ttl=32
autokill=yes
;secretpath=dundi
The entity identifier defined by entityid should generally be the Media Access Control
(MAC) address of an interface in the machine. The entity ID defaults to the first Ethernet
address of the server, but you can override this with entityid, as long as it is set to the
MAC address of something you own. The MAC address of the primary external interface
is recommended. This is the address that other peers will use to identify you.
The Time To Live (ttl) field defines how many peers away we wish to receive replies
from and is used to break loops. Each time a request is passed on down the line because
the requested number is not known, the value in the TTL field is decreased by one,
much like the TTL field of an ICMP packet. The TTL field also defines the maximum
number of seconds we are willing to wait for a reply.
When you request a number lookup, an initial query (called a DPDISCOVER) is sent to
your peers requesting that number. If you do not receive an acknowledgment (ACK) of
your query (DPDISCOVER) within 2,000 ms (enough time for a single transmission only)
and autokill is equal to yes, Asterisk will send a CANCEL to the peers. (Note that an
acknowledgment is not necessarily a reply to the query; it is just an acknowledgment
that the peer has received the request.) The purpose of autokill is to keep the lookup
from stalling due to hosts with high latency. In addition to the yes and no options, you
may also specify the number of milliseconds to wait.
The pbx_dundi module creates a rotating key and stores it in the local Asterisk database
(AstDB). The key name secret is stored in the dundi family. The value of the key can
be viewed with the database show database
family can be overridden with the secretpath option.

Creating mapping contexts
The dundi.conf file defines DUNDi contexts that are mapped to dialplan contexts in
your extensions.conf file. DUNDi contexts are a way of defining distinct and separate
directory service groups. The contexts in the mapping section point to contexts in the
extensions.conf file, which control the numbers that you advertise. When you create a
peer, you need to define which mapping contexts you will allow this peer to search.
You do this with the permit statement (each peer may contain multiple permit

DUNDi | 309