[p2p-sip] P2PSIP, Kademlia and caching

enrico.marocco at telecomitalia.it (Enrico Marocco) Mon, 29 May 2006 10:38 UTC

From: "enrico.marocco at telecomitalia.it"
Date: Mon, 29 May 2006 12:38:08 +0200
Subject: [p2p-sip] P2PSIP, Kademlia and caching
In-Reply-To: <447A7346.1080102@research.panasonic.com>
References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> <447A7346.1080102@research.panasonic.com>
Message-ID: <447ACF10.30502@telecomitalia.it>

Greg Daley wrote:
>>> ...or (2) just to start, one can use openDHT as an emerging _DHT
>>> service_.
>>
>> Is an external DHT service really different from a traditional location
>> service (e.g. a SIP registrar or a dynamic DNS service)?  I can
>> understand it only as a temporary solution; if the location service
>> wasn't distributed across SIP UAs, would this work have any real value?
> 
> There are two logically distinct roles:
> 
> SIP UA (perhaps with the ability to access the P2P location service)
> 
> and
> 
> distributed P2P location storage (for example, using DHT).
> 
> These may end up being on the same box, but there's no
> logical constraint for them to be.  I mean: it's just a
> data storage service, for small blobs of data.

Sure, but what could be achieved using a free storage service such as
OpenDHT could also be achieved using a free conventional SIP provider or
a free dynamic DNS service (e.g. dyndns.org).  Instead, the most
relevant use-cases for which conventional SIP doesn't work require the
Location Service to be distributed among some/all of the SIP phones;
such a solution should be the main goal IMHO.

>>> I guess we need to evaluate the criteria what to use in the DHT
>>> layer. SIP in the DHT layer is wrong IMHO. This is explained in:
>>>
>>> http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt  
>>
>> Perhaps you mean:
>> http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-02.txt
>>
>>
>> The list in sec. 8 is arguable IMHO, but now it's not time for
>> discussing how to transport bits.
> 
> Actually, I think he meant the former.

I should have read it more carefully ;-)  Alan's draft explicitly lists
issues with P2P SIP implementations (sec. 8 "SIP P2P Implementations");
can you please point out where it is explained in the architecture draft?

Enrico