Difference between revisions of "What is DUNDi"
| (20 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == 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 [[GPA|General Peering Agreement]]. | ||
| + | |||
| + | |||
| + | == How does it work? == | ||
| + | [[image:dundi call flow.gif|right|300px]] | ||
| + | ''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. | ||
| + | #Initial DUNDi request from end point and authentication | ||
| + | #Internal lookup in dialplan to determine if we should reply | ||
| + | #If found, pass information back to DUNDi module | ||
| + | #Reply is sent back to requesting node | ||
| + | #Incoming call setup and authentication | ||
| + | #Call is controlled via dialplan logic | ||
| + | |||
| + | === DUNDI lookup schema === | ||
| + | [[image:DUNDi-lookup-schema.gif|center]] | ||
| + | |||
| + | == Basic configuration == | ||
| + | *Create a set of keys using astkeygen | ||
| + | *Place keys in <tt>/var/lib/asterisk/keys</tt> and distribute public key to DUNDi peers ('''also be sure to initialize the keys'''!) | ||
| + | *Configure <tt>dundi.conf</tt> to control advertisements and lookups | ||
| + | *Configure <tt>extensions.conf</tt> to control what we advertise | ||
| + | *Configure a channel configuration file (<tt>sip.conf</tt>, <tt>iax.conf</tt>) for incoming calls | ||
| + | *verify <tt>pbx_dundi.so</tt> module is (re)loaded in <tt>modules.conf</tt> | ||
| + | |||
| + | |||
| + | |||
| + | === 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 <tt>iax.conf</tt>, but not necessarily | ||
| + | *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]: | 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. | + | 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. | 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. | |
| + | |||
| + | |||
| + | ==[[Links#DUNDi_links|DUNDi links]]== | ||
Latest revision as of 14:17, 16 March 2007
Contents
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?
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.
- Initial DUNDi request from end point and authentication
- Internal lookup in dialplan to determine if we should reply
- If found, pass information back to DUNDi module
- Reply is sent back to requesting node
- Incoming call setup and authentication
- Call is controlled via dialplan logic
DUNDI lookup schema
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.
