<!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>
What patents cover voip peering?<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
</PRE>
<BR>
</TD>
</TR>
</TABLE>
-----Original Message-----<BR>
<B>From</B>: Kevin P. Fleming <<A HREF="mailto:%22Kevin%20P.%20Fleming%22%20%3ckpfleming@digium.com%3e">kpfleming@digium.com</A>><BR>
<B>Reply-to</B>: Distributed Universal Number Discovery <dundi@lists.digium.com><BR>
<B>To</B>: <A HREF="mailto:dundi@lists.digium.com">dundi@lists.digium.com</A><BR>
<B>Subject</B>: Re: [Dundi] Core Members?<BR>
<B>Date</B>: Tue, 24 Aug 2010 12:58:22 -0500<BR>
<BR>
<PRE>
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: <A HREF="mailto:kfleming@digium.com">kfleming@digium.com</A>
Check us out at <A HREF="http://www.digium.com">www.digium.com</A> & <A HREF="http://www.asterisk.org">www.asterisk.org</A>
</PRE>
</BODY>
</HTML>