Cisco

DUNDi, So Easy A Caveman Could Do It!
JR Richardson Engineering for the Masses hubguru@gmail.com General Description DUNDi™ is a peer-to-peer system for locating Internet gateways to telephony services. Unlike traditional centralized services (such as the remarkably simple and concise ENUM standard), DUNDi is fully-distributed with no centralized authority whatsoever. What? Simply put, DUNDi isan Asterisk specific protocol setup between two or more PBX’s whereby a PBX may request extension call route location information from one or more peering PBX’s. Here is a verbal example: PBX A: Hello PBX peer B. Do you have extension 201? PBX B: Hi PBX peer A. Yes I do have extension 201, and here is how you will contact this extension, IAX2/username:password@10.10.14.122/201 Please forgive me ifthis seems too simplistic, no offense intended. But this is really as simple and as complicated as things need to get with DUNDi. In its purest sense, all DUNDi does is look for extensions on another PBX. There are things we have to do to setup this peer relationship between the PBX’s and some dial plan manipulation to make it work effectively. In this paper, we will step through the basicconcepts and configurations needed to get 2 or more Asterisk PBX’s setup as DUNDi peers and look at the actual DUNDi messaging while processing DUNDi request. PBX Test Setup Assumptions, Asterisk servers are setup and functioning properly, SIP phones are registered to each PBX and normal call flow within each PBX is working fine. For DUNDi to work only 2 Asterisk servers are needed but we will go intoexamples with 3 servers. PBX A, ver 1.4, 10.10.14.121, extension 101 through 103 PBX B, ver 1.2, 10.10.14.122, extensions 201 through 203 PBX C, ver 1.2, 10.10.14.123, extensions 301 through 303

DUNDi Configuration: IAX.CONF First we have to setup a channel for calls to pass between the PBX’s. In this example we will use IAX2. A simple context in iax.conf is all that is needed for the serversto communicate with each other.
[priv] type=friend dbsecret=dundi/secret context=incomingdundi

Add this context to each server. That’s it, done with IAX2 setup. Now all the PBX’s have a channel to direct calls across. The [priv] context is a name, could be any name as long as it is common between the mapping in dundi.conf, more on this later. The type=friend allows for a 2-way channel betweenservers. The dbsecret=dundi/secret is the password used when location information is sent out to requesting servers. The DUNDi protocol generated a new secret password every hour and stores this password in the local Asterisk database. The context=incomingdundi is the entry point in the dial plan where calls come into. So extensions.conf must have a [incomingdundi] context with a routableextension, like a Goto or include=internal where a new call can be processed properly. This context could be named anything you like or could be any existing context where incoming calls come into your dial plan. DUNDI.CONF Now we will look at the dundi.conf specific configuration. This is where we setup our peering relationship between servers and configure DUNDi responses. We will setup the basicsrequirements in effort to keep explanation simple and easy. DUNDi uses its own protocol on UDP port 4520 to exchange DUNDi query messages. DUNDi does not communicate queries or responses through IAX, just the calls go through the [priv] IAX channel. You can test this by commenting out the iax.conf context [priv], reload chan_iax.so and you can still have DUNDi query’s respond for valid extensions. The[general] section has several parameters that require modification for your specific server to work with others properly. Most of this section is described fairly well in the conf file and the defaults are fine to get up and running.

[general] department=dept organization=company locality=city stateprov=state country=US email=engineer@company.com phone=contact phone number

This information...