Dundi-Whitepaper.pdf

Using DUNDi with a Cluster of Asterisk Servers!

General Description and Scope

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.

Clustering Asterisk gives us the ability to distribute the load of PBX/Soft Switch

a specific registration server then scripting static dial-plan routes to those registration

servers. Dynamic peer location and immediate contact is the goal.

This serves a couple of fundamental needs when designing and building an IP Telephony

network.

1. We design in an environment that is self healing across the core soft switch.

2. We design architecture with scalability and growth in mind, organic growth so

incremental equipment costs are low.

To accomplish dynamic peer location across the cluster, we will first implement a method

whereby an individual PBX is aware when a specific SIP Agent peer has an active

registration on itself. When a SIP Agent registers with a PBX, it is the duty of the local

PBX to let the other PBX’s know where this SIP agent is and how it can be contacted.

We also need the ability for the cluster to share a common pool of SIP Agent registration

information. This will be accomplished through the Asterisk RealTime Architecture

using sip users/peer information pulled from a MySQL Database. This database will be a

stand-alone server for the purpose of this paper but could also be a cluster of servers in a

high availability or load balanced arrangement.

regcontext=<context>

If regcontext is specified, Asterisk will dynamically create and destroy a NoOp priority 1

extension for a given peer who registers with the server. If the context is not specified in

extensions.conf, then it will be dynamically created when a sip agent registers.

Example:

In the [general] section of sip.conf:

produce:

REGPBX1*CLI> show dialplan

[ Context 'sipregistration' created by 'SIP' ]

'1001' => 1. Noop(1001) [SIP]

'1006' => 1. Noop(1006) [SIP]

This gives this PBX a dedicated context that we can map DUNDi lookup request to.

When a DUNDi lookup requests location information for extension 1001, this PBX will

We do not insert a [sipregistration] context in the extensions.conf file because there is no

need. The PBX dynamically creates the context in the dialplan as soon as 1 sip agent

registers.

As we insert regcontext=sipregistration in the sip.conf file in each registration server, we

begin to see how the cluster, with DUNDi lookups, intuitively knows where SIP Agents

are registered.

DUNDi Lookup Server

gateway servers. With a handful of servers, not much of a big deal, but with

50 or more servers, now you have a maintenance event that could span several

hours or over the course of several evenings.

2. As we bring on more trunk access between other markets, say you are turning

up a Dedicated T1 to Lake Charles, LA; you just have to make a

route/translation in the DUNDi lookup server instead of across all of the

registration servers.

keys or passwords. Because this is a cluster, protected from the outside world and only

used to route calls and DUNDi request internally, just use a simple context in iax.conf

that is common to all the servers.

Example in iax.conf:

[priv]