[Dundi] Core Members?

[Kirk Wolff]

What patents cover voip peering?



-----Original Message-----
From: Kevin P. Fleming <kpfleming at digium.com>
Reply-to: Distributed Universal Number Discovery
<dundi at lists.digium.com>
To: dundi at lists.digium.com
Subject: Re: [Dundi] Core Members?
Date: Tue, 24 Aug 2010 12:58:22 -0500


On 08/24/2010 12:43 PM, Kirk Wolff wrote:

> 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:
> 
> 
> 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. 
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> 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. 

What you are describing has a great deal of overlap with the P2PSIP work
being done in the IETF already, which unfortunately is a long way from
being usable, and also infringes on a number of patents based on IPR
claims that have been published.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/dundi/attachments/20100824/be704d9a/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/dundi/attachments/20100824/be704d9a/attachment-0001.pgp