<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
Hello Florian,<BR>
<BR>
Perhaps we should think about modifying the DUNDi protocol to resolve the problems that have been uncovered through implementation. I know the guys at messinet have similar problems but the purpose of the network is to resolve them as they arise. Below are some of my thoughts:<BR>
<BR>
<BR>
The first problem is the GPA; it prevents mapping of the system. There should be a means of testing each node and have it return its exposed dialplan so we know what numbers a person is presenting to the rest of the peers. Also, a person should be able to perform this same action locally so they can see what they are exposing. <BR>
<BR>
A second addition that seems to be evolving out of usage is the need for a blacklist. Perhaps there should also be a means of detecting invalid dialplans. I'm not sure how to do this as I don't know what the definition of an 'invalid dialplan' is and am not sure if there is such a definition. Its possible that failed connections to a lookup-response could be reported back to the originating node through the dundi chain and each node in the chain could store that failed connection message. If a node doesn't fix its failed connections in a reasonable number of failed attempt reports or number of days then that node would be blacklisted automatically. It would be more fair if the maintainer were notified of failed connections through email.<BR>
<BR>
Thirdly, it seems to me that DUNDi requires too much structure. Its apparent that it must be organized in a top-down methodology. One should be able to attach to a cloud by way of a key or password, but not be constrained to a single node. At present each connection requires hard-coded configuration changes on both ends of the DUNDi link. If a 'hub' node goes down, all peers connected to that node will lose their connection to the cloud. I believe DUNDi should be more 'gnutella' or 'torrent' like where requests can go out into the cloud, but the path isn't fixed and each node in the cloud should prevent query loops by caching results passing through that node. The cloud should also self-organize by balancing their available (or configured allowable) bandwidth and their activity. Each node in the cloud should be able to attach dynamically to any other node in the cloud and a configurable number of 'maximum active connections' should be maintained. <BR>
<BR>
For security, the shared key method can be used, but the key should be cloud-wide. I'm not sure how to accomplish this method of security, perhaps a simple 'network password' could be defined so only peers that have been accepted would be given the cloud password. A public password has its disadvantages so a system could be devised to automatically change it.<BR>
<BR>
Another possible method of security is to have a system of automatically sharing the 'allowable public keys' amongst all the nodes in the cloud. if an existing node adds a new node to the cloud, it will push that new node's public key to all other nodes in the cloud. Then the new node can connect to any of the participating nodes. It could be configurable on a particular node whether you accept new node keys automatically or if they have to be manually installed. If a node on the network is misbehaving, that node's key or node ID could be blacklisted and that blacklist could be pushed to all nodes in the same way as the keys are shared. This way, it only takes one node to approve a new node the cloud, but any node in the cloud could blacklist any other node. <BR>
<BR>
Any thoughts?<BR>
<BR>
- Kirk<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Florian Overkamp <<A HREF="mailto:florian@speakup.nl">florian@speakup.nl</A>><BR>
Reply-to: Distributed Universal Number Discovery <<A HREF="mailto:dundi@lists.digium.com">dundi@lists.digium.com</A>><BR>
To: Distributed Universal Number Discovery <<A HREF="mailto:dundi@lists.digium.com">dundi@lists.digium.com</A>><BR>
Subject: Re: [Dundi] Core Members?<BR>
Date: Tue, 24 Aug 2010 17:36:36 +0200<BR>
<BR>
Hello,<BR>
<BR>
On 08/24/2010 05:16 PM, Kirk Wolff wrote:<BR>
> Hi all, I'm trying to join your DUNDi cloud. I'm already a member of<BR>
> messinet.<BR>
><BR>
> I've tried contacting all of the 'core members' listed on your website,<BR>
> all of their websites no longer exist with exception to voicepulse.<BR>
<BR>
I think you will find our website also still really works :)<BR>
<BR>
> I appears there is no DAHDI cloud other than a few very private ones.<BR>
<BR>
The actual usage of DUNDI peering using the GPA'ed e164 context is <BR>
indeed very thin. The biggest downside of this technology as we can see <BR>
it, is the fact that there is no easy and verifyable means to block <BR>
faulty routes for remote members. For telco's to put their trust into <BR>
such a system requires this, because hunting after customer complaints <BR>
is fun once, but a nasty drag the second time around. I must admit our <BR>
usage of DUNDI has been fairly limited these last few years, mainly <BR>
because I see no movement on the problematic field mentioned above.<BR>
<BR>
In the meantime, DUNDI has indeed been put to very good use in building <BR>
privately controlled clusters. So I think DUNDI can continue to be used, <BR>
but not in the sense that Mark envisioned it years ago....<BR>
<BR>
-- <BR>
Met vriendelijke groet,<BR>
<BR>
Florian Overkamp<BR>
SpeakUp BV<BR>
T: 088-SPEAKUP (088-7732587)<BR>
T: 053-4305842<BR>
<BR>
</BODY>
</HTML>