DUNDi Module Ramblings

I use DUNDi to peer several systems right now and i'd like to have a FreePBX module to manage the connections. Right now i have to manually edit the config files and that makes it more work when i upgrade or add systems to the DUNDi cloud.

Here are some of my thoughts on how to do it.

Public/Private Keys

Public / Private key management should probably be a separate module. There should probably also be a standardized way for modules to use the keys. At first, a simple way would be to simply list the files in the /var/lib/asterisk/keys/ folder. Anything ending in .pub would be a potential inkey, and any ending in .pri would be a potential outkey.

Design

What i had in mind was a screen where you can add peers similar to the trunk screen. Each peer would have the following properties:

entityid (mac address)
host
inkey
outkey (this should probably always be set to the same, but maybe not?)
order = primary|secondary|tertiary|quartiary
model = symmetric|inbound|outbound
qualify = yes|no
precache = symmetric|incoming|outgoing

There would also be some settings that are for the host, not the peers.

• canonical
  • It's a good idea to advertise any DID's that you own.
  • Ex. 2525551212
• customers
  • This is where you want to list any extensions local to this server that you want to advertise into the DUNDi cloud.
  • Ex. 21XX
• via-pstn
  • If you want to allow peers to route calls to the PSTN thru this server, this is where you would list them.
  • Ex. 252555XXXX

For each one of those contexts you should also be able to select from a list of flags:

nounsolicited:  No unsolicited calls of any type permitted via this route
nocomunsolicit: No commercial unsolicited calls permitted via this route
residential:    This number is known to be a residence
commercial:     This number is known to be a business
mobile:         This number is known to be a mobile phone
nocomunsolicit: No commercial unsolicited calls permitted via this route
nopartial:      Do not search for partial matches

Another thought is that maybe you can add as many contexts as you want but add these as default contexts. I'm not sure which way to go.. one would be more straight forward to configure, simply plug in the numbers you want to share. The other way would be more flexible and allow you to join multiple dundi clouds it would also add quite a bit more work to get the module written. Currently i'm thinking of starting with these three predefined contexts and then in a later version add the flexibility if its requested.

You should also be able to pick the technology (IAX, SIP, H323) you advertise for your peers to use when connecting to you.

Another question to decided is how to insert it into the dialplan. Do i add another trunk and let the user insert it where needed or should it always check dundi first?

-- Discussion

(gregmac 6/29/2006) DUNDi seems like it may be a good solution to a FreepbxCluster. We'd still need to add a bit more logic so we could tell admins about conflicting extensions (ie, already provided by another dundi peer) but if it works, it would make clusters fault-tolerant and easy to setup, since DUNDi takes care of all the routing.

DUNDi also lets you publish (is that the right word?) PSTN routes, so not only would it be possible to just have internal (extension <> extension) calling, but it would allow routing calls to other cities, for example, if you're calling a local number there, or just providing backup routes if local routes are busy or down.

May be of interest: DUNDi Enterprise Configuration IAX

(ullbergm 6/29/2006) After i wrote the wiki page i started thinking about maybe have a simple config and a advanced config. The simple config would only let you enter the peer information (ie. hostname and key) and there would be checkboxes on what you want to publish (DID's, extensions, local routes). The simple way would be used to peer two or more pbx's.

When you check the extensions checkbox it would loop thru the extensions when writing the dundi config and publish those. Same thing goes for the DID's. The local routes would have to be done differently since i dont think there would be a way to figure out which routes are free calls for the local pbx.

The advanced config would let you enter the information discussed above.

Maybe the right thing to do is to make the DUNDi module the advanced way where you can edit everything and do the simple way in the FreepbxCluster? As far as validating extensions we could probably use the astmanager api to do a dundi lookup ext@priv

Another interesting link: http://blog.thegoldfish.net/dundi-tutorial-for-asteriskhome/