Difference between revisions of "What is DUNDi"

From TD-er's Wiki
Jump to navigationJump to search
 
(3 intermediate revisions by 2 users not shown)
Line 26: Line 26:
  
 
=== DUNDI lookup schema ===
 
=== DUNDI lookup schema ===
[[image:DUNDi-lookup-schema.gif|center|452px]]
+
[[image:DUNDi-lookup-schema.gif|center]]
  
 
== Basic configuration ==
 
== Basic configuration ==
Line 47: Line 47:
 
*Can use the same context for both advertisements and call handling – or separate contexts (recommended)
 
*Can use the same context for both advertisements and call handling – or separate contexts (recommended)
 
*Can use pattern matching to advertise “ranges”
 
*Can use pattern matching to advertise “ranges”
 
 
  
 
=== Channel configuration file ===
 
=== Channel configuration file ===
Line 54: Line 52:
 
*Usually via <tt>iax.conf</tt>, but not necessarily
 
*Usually via <tt>iax.conf</tt>, but not necessarily
 
*Authentication using <tt>dbsecret</tt> to pull rotating key from AstDB
 
*Authentication using <tt>dbsecret</tt> to pull rotating key from AstDB
 +
 +
== DUNDi Trust Group ==
 +
From [http://www.sineapps.com/news.php?rssid=240 Another DUNDi site]:
 +
 +
DUNDi is essentially a trusted, peer-to-peer system for being able to call any phone number from the Internet. DUNDi works by creating a network of nodes called the "DUNDi E.164 Trust Group" which are bound by a common peering agreement known as the General Peering Agreement or [[GPA]]. The GPA legally binds the members of the Trust Group to provide good-faith accurate information to the other nodes on the network, and provides standards by which the community can insure the integrity of the information on the nodes themselves. Unlike ENUM or similar systems, DUNDi is explicitly designed to preclude any necessity for a single centralized system which could be a source of fees, regulation, etc.
 +
 +
Much less dramatically, DUNDi can also be used within a private enterprise to share a dialplan efficiently between multiple nodes, without incuring a risk of a single point of failure. In this way, administrators can locally add extensions which become immediately available to the other nodes in the system.
 +
 +
In the DUNDi model, there is no central repository. Instead, node participate in a trust system in which each node has a trust relationship with at least one other node in the system. When the client requests a number or extension it does not know how to terminate, it queries the nodes directly connected to it. Those nodes in turn will query nodes which are directly connected to them and so on (care is taken in the protocol to minimize the actual number of transactions and nodes that are queried, while maintaining the same effective answer as querying the entire system). The resulting answers are collated, cached appropriately at each involved node, and passed along to the original requesting party.
  
  
== DUNDi as a routing protocol ==
+
==[[Links#DUNDi_links|DUNDi links]]==

Latest revision as of 14:17, 16 March 2007

What is DUNDi?

DUNDi is a p2p system, used to to translate phone numbers to VoIP-addresses.

It works very much like the DNS system, or a phone book. Only difference with the DNS system is that you are only advertising your own numbers. The difference with the phonebook is that you don't have all pages, but those are spread among the peers in the network.

It can be used in private or public networks. For use in public networks, you will have to agree to the General Peering Agreement.


How does it work?

Dundi call flow.gif

Ask a friend, and they ask their friends until someone knows the answer.

Even if you didn’t request it, remember it for a period of time (cache), in order to put less strain on the network.

This answer to a DUNDi lookup will tell you about how to reach the phone (extension) you want. Most often these directions will not lead you directly to the phone on the other end, but it will lead you to a point where they will connect you.

DUNDi call flow

For a DUNDi-lookup, followed by a call, several config-files will play a role.

  1. Initial DUNDi request from end point and authentication
  2. Internal lookup in dialplan to determine if we should reply
  3. If found, pass information back to DUNDi module
  4. Reply is sent back to requesting node
  5. Incoming call setup and authentication
  6. Call is controlled via dialplan logic

DUNDI lookup schema

DUNDi-lookup-schema.gif

Basic configuration

  • Create a set of keys using astkeygen
  • Place keys in /var/lib/asterisk/keys and distribute public key to DUNDi peers (also be sure to initialize the keys!)
  • Configure dundi.conf to control advertisements and lookups
  • Configure extensions.conf to control what we advertise
  • Configure a channel configuration file (sip.conf, iax.conf) for incoming calls
  • verify pbx_dundi.so module is (re)loaded in modules.conf


dundi.conf

  • Used to control how we reply to requests
  • Controls “DUNDi peers” <= used to control who we will reply to, and who we will use to send requests
  • Can setup multiple groups / networks

Dialplan (extensions.conf)

  • Controls what we advertise and how to handle the call
  • Can use the same context for both advertisements and call handling – or separate contexts (recommended)
  • Can use pattern matching to advertise “ranges”

Channel configuration file

  • Controls the authentication of the incoming call and delivery to incoming context (as per usual Asterisk fashion)
  • Usually via iax.conf, but not necessarily
  • Authentication using dbsecret to pull rotating key from AstDB

DUNDi Trust Group

From Another DUNDi site:

DUNDi is essentially a trusted, peer-to-peer system for being able to call any phone number from the Internet. DUNDi works by creating a network of nodes called the "DUNDi E.164 Trust Group" which are bound by a common peering agreement known as the General Peering Agreement or GPA. The GPA legally binds the members of the Trust Group to provide good-faith accurate information to the other nodes on the network, and provides standards by which the community can insure the integrity of the information on the nodes themselves. Unlike ENUM or similar systems, DUNDi is explicitly designed to preclude any necessity for a single centralized system which could be a source of fees, regulation, etc.

Much less dramatically, DUNDi can also be used within a private enterprise to share a dialplan efficiently between multiple nodes, without incuring a risk of a single point of failure. In this way, administrators can locally add extensions which become immediately available to the other nodes in the system.

In the DUNDi model, there is no central repository. Instead, node participate in a trust system in which each node has a trust relationship with at least one other node in the system. When the client requests a number or extension it does not know how to terminate, it queries the nodes directly connected to it. Those nodes in turn will query nodes which are directly connected to them and so on (care is taken in the protocol to minimize the actual number of transactions and nodes that are queried, while maintaining the same effective answer as querying the entire system). The resulting answers are collated, cached appropriately at each involved node, and passed along to the original requesting party.


DUNDi links