Usando la red DUNDi en Asterisk
Este mes toca darle un repaso a DUNDI, un protocolo de localización de servicios telefónicos.
Básicamente, DUNDI nos permite crear una red P2P de centralitas, donde cada una “publica” números de teléfono para los que es responsable, como sus extensiones locales, números para la que es la ruta de menor coste, etc.
Dos ejemplos
El ejemplo típico es el de la empresa multisede. Cada sede publica sus extensiones propias, de forma que el resto pueda localizarlas. ¿Quién tiene la extension 329? Esta consulta se enviaría, directa o indirectamente, a todos los equipos (peers) de la red DUNDI. La centralita que sirva esa extensión responderá algo como “IAX2/usuario:clave@1.2.3.4/329″, que es la forma de llamar a dicha extensión. La centralita que hizo la consulta utilizará esa información para llamar efectivamente a la extensión 329.
Aún en el caso de que cada sede tenga asignado un rango de extensiones, DUNDI nos resultará útil, porque evitaremos llamar a la centralita remota si la extensión buscada no está creada aún, aunque esté en su rango. Podremos gestionar el error localmente.
En otro ejemplo de uso, las diferentes centralitas publican los números de teléfonos locales. Tenemos la sede A en Asturias, la B en Barcelona y la C en Canarias.
Pongamos que un usuario de la sede C llama a Asturias, al 985123123. Estamos hablando de llamada nacional, que si no tenemos tarifa plana, no es barata. La centralita, antes de marcar usando las líneas propias, hará una consulta DUNDI, para ver si alguien puede terminarnos la llamada. La centralita A nos responderá con IAX2/usuario:clave@sedea.empresa.es/985123123.
Cuestiones a tener en cuenta
El protocolo DUNDi utilizar por defecto el puerto 4520/UDP. Habrá que abrirlos en los firewalls. Es independiente de IAX, es decir, la cadena de conexión devuelta en una consulta puede hacer referencia a cualquier tipo de canal (IAX2, SIP, H323, etc), aunque normalmente se usa el IAX2.
Manos a la obra
dundi.conf
Nuestra primera parada es el fichero dundi.conf. Vamos por partes:
[general]
department=SedeA
organization=Empresa
locality=Fuerteventura
stateprov=Canarias
country=ES
email=julianjm arroba gmail.com
phone=+34928000000
Como véis, la primera parte consiste en indicar quienes somos y la información de contacto. Esto permitirá a otros nodos de la red concernos 
entityid=00:11:22:33:44:55
El entityid es un parámetro importante. Es nuestra identificación en la red, y debe ser única. Si no lo definimos, se usará la dirección MAC de la primera interfaz de red, pero para más seguridad conviene definirlo.
ttl=2
No necesitaremos conocer “personalmente” a todos los nodos de la red. Nuestros vecinos pueden propagar nuestras consultas a los suyos, y así sucesivamente hasta que el ttl (time-to-live) llegue a 0. Poniendo ttl=2 limitaremos la profundidad de las consultas, reduciendo el tiempo de espera.
[mappings]
Esta sección es clave. Por un lado definimos los recursos que vamos a usar, por otro indicaremos los números que nuestra centralita publicará:
extensiones-locales=>
ext-local,0,IAX2,dundi:${SECRET}/1.2.3.4/${NUMBER}
Vamos a detenernos y a analizar cada uno de estos elementos.
- extensiones-locales: Este es el nombre del recurso. Lo usaremos solamente para buscar extensiones en la empresa, en las diferentes sedes.
- ext-local: Es el contexto donde tenemos definidas nuestras extensiones. Cuando otro nodo busque una extensión que tenemos definida en este contexto, responderemos con gusto.
- 0: Es el peso de nuestra respuesta. Cuando menor sea más peso (prioridad). Es útil en otro tipo de recursos. A la hora de buscar rutas de menor coste para las llamadas, si estamos seguros de que somos la mejor, pondremos 0. Si nuestra ruta es buena, pero las hay mejor, pondremos un valor mayor.
- IAX2: Simplemente el tipo de canal. Puede ser SIP, H323 o cualquier otro.
- dundi:${SECRET}/1.2.3.4/${NUMBER}: En una cadena de llamada IAX2, “dundi” es el usuario, ${SECRET} se sustituirá por la contraseña a utilizar (más información abajo), 1.2.3.4 nuestra IP, y ${NUMBER} se sustituirá por el número de la consulta.
Cuando definimos peers IAX2, hay un parámetro dbsecret, que indica que la contraseña está almacenada en AstDB, por ejemplo en dundi/secret. DUNDi genera esas contraseñas, y las va rotando cada cierto tiempo. Permite que los diferentes nodos puedan contactar con nosotros (y llamar a las extensiones que hemos publicado), pero sin darles una contraseña de acceso fija.
Ahora toca definir nuestros vecinos en la red. Como comentaba, no estaremos conectados con todos los nodos de la red DUNDi, sino con unos pocos. Cuando nuestra centralita haga una consulta, se la enviará a estos vecinos, y si éstos no tienen respuesta, la seguirán reenviando hasta encontrarla, o bien llegar al máximo de “saltos”. Para eso usamos el parámetro ttl, ya que podríamos eternizarnos si la red tiene muchos nodos.
[BB:BB:BB:BB:BB:BB] ; Lo identificamos por su entityid
model=symmetric
host=1.2.2.2
inkey=dundikey
outkey=dundikey
include=extensiones-locales
permit=extensiones-locales
Model puede ser incoming, outgoing o symmetric, en función de si solo permitiremos consultas procedentes de este peer, si solo haremos consultas pero no las aceptaremos, o si haremos ambas cosas.
Las comunicaciones entre nodos van encriptadas usando clave pública/privada. Deberemos generarlas previamente y almacenarlas en /var/lib/asterisk/keys. El parámetro inkey indica la clave a usar en las consultas que nos hace el nodo, y outkey la que emplearemos nosotros cuando enviemos nuestras consultas. En nuestro caso, ya que es un sistema más o menos contralado, usaremos la misma. Las generamos en una de las sedes, y la copiamos al resto.
$ cd /var/lib/asterisk/keys
$ astgenkey -n dundikey
$ rsync dundikey* ip_de_otra_sede:/var/lib/asterisk/keys/
El parámetro include indica para qué recursos usaremos este peer, y permit recursos para los que aceptaremos consultas. Podemos poner en ambos casos all para simplificar.
extensions.conf
Para que nuestra centralita realice las búsquedas de extensiones en la red DUNDi, y para que publique las locales, hay que adaptar nuestro dialplan:
[ext-local] ;extensiones locales
exten => 3001,1,Macro(stdexten,${EXTEN})
exten => 3002,1,Macro(stdexten,${EXTEN})
exten => 3003,1,Macro(stdexten,${EXTEN})
exten => 3004,1,Macro(stdexten,${EXTEN})
;
[from-internal] ; Aqui estan asociadas nuestas extensiones.
include => ext-local ; Llamadas a extensiones
include => out-nacional ; Llamadas nacionales
include => out-internacional
Como vimos antes, en la definición de los mappings en el fichero dundi.conf, el contexto que publicaremos es [ext-local]. Todas nuestras extensiones locales (3001 a 3004) estarán disponibles para los miembros de la red que las soliciten bajo el recurso “extensiones-locales”.
Para poder encontrar nosotros extensiones en seder remotas, debemos hacer la siguiente modificación:
[from-internal] ; Aqui estan asociadas nuestas extensiones.
include => ext-local
include => dundi-extens
include => out-nacional
include => out-internacional
;
[dundi-extens]
switch => DUNDI/extensiones-locales
Creamos el contexto dundi-extens, que contiene una sentencia switch. Ésta permiten utilizar dialplan remoto. En el caso de DUNDI, si una extensión buscada (por ejemplo 3100) existe, sería equivalente a tener:
exten => 3100,1,Dial(<respuesta recibida por DUNDi>)
iax.conf
Para que podamos atender llamadas del resto de sedes, definiremos un peer IAX. Tendrá como usuario “dundi”, una clave guardada en AstDB, y entrará directamente al contexto ext-local.
[dundi]
type=user
context=ext-local
dbsecret=dundi/secret
disallow=all ; a partir de aquí, al gusto
allow=g729
Probando las consultas
Después de replicar estos pasos en otra sede, y configurarse mutuamente como peers de la red DUNDi, podemos hacer algunas pruebas:
CLI> dundi query BB:BB:BB:BB:BB:BB@extensiones-locales
DUNDi Query EID succeeded:
Department: Sede B
Organization: Empresa
City/Locality: Barcelona
State/Province: Catalunya
Country: ES
E-mail: adminSedeB@empresa.es
Phone: +34930111222
IP Address: 1.2.2.2
Hemos pedido la información de contacto del peer con entityid=BB:BB:BB:BB:BB:BB.
CLI> dundi lookup
Usage: dundi lookup
Lookup the given number within the given DUNDi context
(or e164 if none is specified). Bypasses cache if ‘bypass’
keyword is specified.
CLI> dundi lookup 3100@extensiones-locales bypass
301@dundi-extensions
1. 0 IAX2/dundi:5Occfx8Tmx+rbwYtyx4mbQ==@1.2.3.4/3100 (EXISTS|CANMATCH)
from BB:BB:BB:BB:BB:BB, expires in 3600 s
DUNDi lookup completed in 120 ms
Hemos realizado una consulta para localizar a la centralita responsable de la extensión 3100 en el recurso extensiones-locales. Nos responde un solo peer, y con peso “0″ nos dice que podemos encontrarla en IAX2/dundi:****@1.2.3.4/3100. Qué bonito!
Ahora solo falta llamar a esa extensión y comprobar que efectivamente la llamada sale y llega a su destino.
Conclusión
Aunque existen buenos tutoriales sobre DUNDi, todos los que pude encontrar están en inglés. Además, no hay nada como redactar un HOWTO de estos para documentar lo que uno va aprendiendo. No será la primera ni última vez que acudo al blog cuando me olvido de algo
Comunidad
Como dice el dicho, cortando cojones se aprende a capar ;). Dado que mucha gente solo tiene un asterisk en casa con el que va aprendiendo, probar funciones como ésta puede resultar complicadillo (y aburrido). Por eso, si queréis, podemos montar una red DUNDi (asterisk-es), donde cada uno publique una serie de extensiones (con tests de eco, grabaciones, demos, etc), y que a su vez pueda realizar consultas y acceder a extensiones publcicadas por otros miembros de la red.
Si hay gente interesada, abro otro post y publicamos ahi nuestas configuraciones, claves y experiencias 
Muy chulo y didáctico
Aprovecho para comentar que existe un draft de DUNDI (escrito por Mark Spencer):
http://www.dundi.com/dundi.txt
Lo malo es que dicho draft está caduco:
Expires: April 13, 2005
¿Cómo ha acabado esto? ¿no se ha aceptado como RFC?
Comment by Iñaki Baz
— 18 December 2007 @ 10:03
Andaba haciendo pruebas con dundi, y me ha surgido la siguiente pregunta.
Si tenemos espacio de extensiones en varias centralitas que colisionan (100 en ambas) que tratamiento hace asterisk. Habría que tocar el dialplan, supongo, para que si falla en local vaya en remoto?.
Un dundi lookup de una extension remota igual a la local, me da:
no rusults..
Comment by Alberto
— 4 January 2008 @ 13:55
Acabo de hacer la prueba de definir una extensión local igual a una remota, y el “dundi lookup” me sigue funcionando. No hace caso a lo que tengas en tu propia centralita.
Para hacer failover, es decir, que cuando llamamos a la extensión 100 y no existe, salte a la devuelta por dundi, hay que usar regexten y regcontext. Este último es el contexto que publicamos con dundi. El dialplan sería algo como:
exten => _1XX,2,Dial(SIP/${EXTEN}) ; PRIORIDAD 2
Cuando la extension 100 se registre, se creará una extensión NoOp en la prioridad 1, tal que:
exten => 100,1,NoOp
Ahora, conjugando este contexto con extensiones dinámicas, y una sentencia swich, conseguimos que si no existe una extensión en la PBX local, haga la búsqueda en DUNDI.
Comment by julianjm
— 4 January 2008 @ 14:36
Muchas gracias Julian
Eres un pozo de sabiduría .
He vuelto a probar el lookup ya ya me da resultados. Quizá algo de tiempo de propagación de las extensiones me ha jugado una mala pasada.
Gracias por el comentario
Comment by Alberto Sagredo
— 4 January 2008 @ 15:33
Hola Julian. Exelente tutotial.
quiero que me ayudes con lo siguiente:
Tengo que crear una red de tres servidores Asterisk, ubicados en diferentes ciudades. quiero que se comuniquen entre ellos a taves de IAX Trunk. el objetivo es crear una sala de conferencias entre los tres. es para hacer un programa de radio en red. hasta hoy se esta utilizando skype. la sala de conferencias supongo que estara en uno de los servidores y los otros dos llamaran a ese servidor.
Tras mucho esfuerzo he logrado conectarlos todos contra todos (una red mesh) esto lo hice solo en mi laboratorio.
ahora mi pregunta es, que me conviene usar Dundi o solo conectarlos a travez de IAX
saludos
Comment by Jhonny Velasquez
— 7 April 2008 @ 16:29
Hola.
Si me permites una consulta sobre dundi. Tengo una central asterisk con extensiones 60XX. Esta central esta conectada a otra con numeracion 61XX. Hasta aqui todo correcto. La comunicacion es IAX y salvo la perdida de la identificacion de llamada todo lo demas funciona. Mi duda es la siguiente: la primera central esta conectada con un primario a una central MD110 de Ericsson. Con este metodo la primera asterisk es servidor de la “red asterisk” y pasarela hacia la MD110. ¿Que pasa si quiero implemetar dundi?. Hay un plan de marcado un poco extenso que controla la primera asterisk y encamina hacia la MD110. De hecho todo pasa por la MD110, excepto en la segunda asterisk, que tiene una RDSI para supervivencia en caso de caida de la red.
Saludos y gracias.
Comment by Francisco Gil
— 30 April 2008 @ 17:32
En dundi publicas las extensiones de las que se hace cargo el asterisk. Pueden ser extensiones normales, o incluso rutas a la PSTN.
Cuando el otro asterisk haga la consulta, recibirá una cadena de conexión (IAX/asterisk1/loquesea), y hará un Dial.
Es decir, en el asterisk que tienes conectado al a MD110, le entrará la llamada por el contexto que indiques, y ahi haces lo que quieras con la llamada.
Comment by julianjm
— 2 May 2008 @ 16:22
ostias tocayo!!! te veo por el blog de julian también…
Julián, que no era yo, eh…. XDD
Comment by paco gil
— 25 May 2008 @ 21:30
Hola Julian! Ante todo gracias por todos tus comentarios que son mas que utiles.
Mi escenario es: OfiA, OfiB, OfiC, etc. Cada una con su Ast y su primario. Quiero tener una numeracion unica, y que funcione mas alla de donde se registre el telefono. De esta forma, si se cae uno, los telefonos se registrarian en otro, y si se la linea de conexion contra la central, tambien seguiria funcionando. Mi logica dice que no es posible con Dundi, estoy en lo correcto?No soy capaz de teniendo las mismas extensiones en las dos centralitas, que gracias al dundi, encuentre la que esta activa. Necesito personalizar la extension, mas alla de su ubicacion, y que si hoy esta en barcelona, y mañana en madrid, y justo se cae la linea con barcelona, que igualmente tenga telefono. Espero que me haya explicado lo suficiente. En fin, mas alla de todo, muchas gracias por leer este rollo!!!
Comment by Federico
— 13 June 2008 @ 19:26
Federico,
Para eso tienes que combinar dundi con el parámetro regcontext de sip.conf:
Eso lo que hará será crear una extensión NoOp, con prioridad 1, cuando un teléfono se registre, y la eliminará cuando se desregistre.
El contexto “a_extensiones”, que es donde está el diaplan para llamar a una extensión concreta, sería algo como esto, teniendo en cuenta de empezar siempre en la prioridad 2, ya que la 1 la crea asterisk automáticamente:
[a_extensiones] exten => _3XX,2,Dial(SIP/${EXTEN}) exten => i,1,NoOp(Extension no existente) include=> contexto_dundiEn DUNDI, tú publicas el contexto [a_extensiones], de forma que solo se publicarán las extensiones que estén registradas en este servidor. Cuando llamas a la extensión 301, por ejemplo, si está registrada aquí, se hace el Dial correspondiente, si no, se hará una búsqueda DUNDI y contestará la centralita que la tenga registrada.
Por otra parte, además de extensiones (teléfonos) puedes publicar cualquier otro número. Es decir, cada centralita puede publicar las rutas que salen más económicas (si la centralita está en Cataluña, publicará las _93XXXX.). De esta forma, en cada llamada saliente, si haces una búsqueda Dundi antes de salir por el primario que tenga conectada la centralita, si hay una ruta más económica, se usará.
Julian.
Comment by julianjm
— 13 June 2008 @ 20:02
Hola Julian!Gracias por responderme tan rapido. Lo he configurado tal y como me has dicho y funciona correctamente salvo por un pequeño detalle. Cuando la extension esta configurada en el sip.conf, todo funciona sin problemas, cuando esta configurada tirando del mysql,me tira el siguiente error:
[Jun 16 14:56:00] WARNING[29387]: chan_iax2.c:7372 socket_process: Call rejected by 172.17.64.164: No such context/extension
— Hungup ‘IAX2/172.17.64.164:4569-1′
== Everyone is busy/congested at this time (1:0/0/1)
— Executing [202@internal:2] Dial(”SIP/100-081f6af0″, “SIP/202|30|tr”) in new stack
— Added extension ‘202′ priority 1 to internal
— Called 202
— SIP/202-081ef690 is ringing
— Added extension ‘202′ priority 1 to internal
== Spawn extension (internal, 202, 2) exited non-zero on ‘SIP/100-081f6af0′
— Added extension ‘202′ priority 1 to internal
Otra cosa que me tiene mosqueado, es que cuando hago un dundi lookup ext_d_mi_servidor me responde que la tiene el otro, eso no deberia ser asi no??? Desde ya muchas gracias Julian!
Comment by Federico
— 16 June 2008 @ 11:20
Federico,
Hmm, con realtime ni idea… Tienes activada la opción rtcachefriends?
Por otra parte, respecto a tu última pregunta, es normal. Una consula DUNDI no incluye los resultados locales. Por eso tienes que comprobar primero si la extensión es local (o está registrada aquí), y si no, hacer la consulta Dundi.
Comment by julianjm
— 16 June 2008 @ 12:23
Gracias nuevamente! No tengo activada la opcion rtcache porque he ledido por ahi que suele dar problemas haciendo que las consultas sean mas lentas. Igualmente lo probare y te cuento. Nuevamente muchas gracias por compartir tu sabiduria!
Comment by Federico
— 16 June 2008 @ 12:29
Buen día julian, estoy un poco “nuevo” en este asunto del dundi. Sin embargo logre configurar una pequeña prueba y funciona perfectamente. El asunto es que no comprendo muy bien como ajustarla para que realice lo que le explicaste a federico. Este es mi extensions.conf
[lookupdundi] ;en tu ejemplo es dundi-extens
switch => DUNDi/priv ;en tu ejemplo extensiones-locales
[dundiextens] ;en tu ejemplo ext-local
exten => 200X,1,NoOP
[incomingdundi]
exten => 200X,1,Goto(ejemplo|200X|1)
[ejemplo]
exten => 2000,1,Dial(SIP/2000,30)
exten => 2000,2,Hangup
include => lookupdundi
Ahora según entiendo, en el sip.conf debo agregar regcontext=dundiextens y regexten=200X .
Además en dundiextens en el extensions.conf, debo cambiar la prioridad de lo que tengo a 2 y agregar exten => i,1,NoOp ??. Esa es la parte que no comprendo, lo coloque asi y no funciona. Muchas gracias en la colaboración que me puedan prestar.
Comment by Robert
— 7 July 2008 @ 15:53
Robert,
Efectivamente, regcontext=dundiextens. En ese contexto tienes que tener el dialplan necesario para llamar a tus propias extensiones, pero en la prioridad 2. La prioridad 1 la crea asterisk automáticamente cuando el teléfono se registra:
[dundiextens] exten => _2XXX,2,Dial(SIP/${EXTEN}); ; [ejemplo] include => dundiextens include => lookupdundiEl contexto que publicas en dundi es “dundiextens”. Si tienes el teléfono 2001 registrado, asterisk habrá creado la línea “exten => 2001,1,NoOp”, y por lo tanto, pasará a la prioridad 2, que tiene el comando Dial. Al existir este NoOp en la prioridad 1, cuando el servidor reciba una consulta Dundi, respoderá.
Asimismo, los teléfonos que estén en el contexto [ejemplo] que te pongo, harán primero una búsqueda en [dundiextens]. Si existe la extensión, llamarán localmente, y si no, asterisk hará la búsqueda en Dundi (mediante el contexto lookupdundi).
Espero que te haya servido
Comment by julianjm
— 7 July 2008 @ 16:26
Gracias julian, despues de eliminar el include=>dundilookup del contexto de llamadas, e incluirlo en uno nuevo, siguiendo tu ejemplo [from-internal]funciono perfectamente. Aparentemente estaba causando un loop de busquedas, aún teniendo el ttl =1.
Comment by Robert
— 9 July 2008 @ 19:20
Amigo, no he echo la prueba aun de dundi pero lei tu articulo y me surge una duda.. mis ips, son dinamicas y las resuelvo por dyndns. como quedaria esta linea?
ext-local,0,IAX2,dundi:${SECRET}/1.2.3.4/${NUMBER}
EN donde va la ip pongo el nombre q me da dyndns?
ext-local,0,IAX2,dundi:${SECRET}/xxx.dyndns.org/${NUMBER}
Comment by Johans
— 3 September 2008 @ 1:34
Johans… Parece una buena solución
De hecho es la única forma (práctica) que se me ocurre.
Comment by julianjm
— 3 September 2008 @ 7:28
Amigo segui tus instrucciones y funcia perfecto cuando uso las ip que me da el proveedor, pero luego de montar una vpn(openVPN) y colocar las ip locales de cada servidor no se conecta el dundi… quite todas las reglas iptables y nada, no funciona. probe la conexion (ping) entre los equipos y todo perfecto. lo unico que no me funciona es dundi “solo cuando uso las ip locales” con las que me da el isp si me funciona. que puede estar pasando?
Comment by Johans
— 10 September 2008 @ 0:41
hay un pequeño detalle en setear prioridad 2 y dejar a asterisk crear automaticamente la prioridad 1 con el regcontext, cuando recargas el extension.conf , la prioridad 1 desaparece ( y es lógico no esta definida). Esto hace que el sIP que aun está registrado de manera local no se le pueda llamar.
Hay una manera de evitar la perdida de esa prioridad tras una recarga del extension, mientras se mantenga el registro SIP respectivo?
Saludos.
Comment by Giofe
— 5 October 2008 @ 3:51
Hola Giofe,
Pues la verdad es que si es el caso, perdería bastante utilidad el regexten
Entiendo que se trata de un bug en asterisk. Has probado con la última versión? Si es el caso, habría que mirar el código fuente de asterisk, y ver cómo se pueden crear todas las extensiones con prioridad 1 para todos los peers registrados, una vez recargado el dialplan…
Julian.
Comment by julianjm
— 5 October 2008 @ 8:48
Hola Julián. Excelente documento!
Solo una duda, mi * tiene 2 interfaces de red
1- Conexion ADSL
2- Conexion red guifi.net
Tanto por ADSL como por red tengo el mismo dominio.
La pregunta es como puedo hacer esto con dos interfaces de red? Se pueden poner las dos mac?
Gracias
Comment by LinksysDS
— 5 November 2008 @ 1:31