[p2p-sip] P2PSIP, Kademlia and caching

[gregd at research.panasonic.com (Greg Daley)]

Hi Enrico,

Enrico Marocco wrote:
[cut]
>> 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.


It's not about OpenDHT.  I think it was being discussed for
illustrative purposes.

One of the primary reasons people may want a logical separation between
the overlay infrastructure and SIP, is because most Infrastructure SIP's
not all about NAT traversal services, while P2P infrastructure services
(which may just happen to be running on publically addressed SIP
devices) may be heavily involved.

Does someone have to implement the full SIP stack to run a STUN Relay?
How about providing a robust way to discover these Relays, and
distribute loads, etc?  Is SIP required for these functions?

I'd guess not.

So if the function of the NAT traversal services aren't necessarily
tied to SIP protocol, why would the distributed lookup service?

Now, if the protocol does end up being SIP or SIP-like, that's OK,
it's just that architecturally, it's not needed.

>>>> 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?

Do you mean apart from section 3: Architecture Overview, which starts:

    A peer in the P2P SIP system is comprised of two layers: the P2P
    overlay layer and the SIP layer.  The P2P overlay layer handles all
    the P2P overlay functions.  The P2P overlay layer does not interpret
    semantic meanings of the resources placed or looked up by the higher
    layers including SIP.  But its design goal is serving SIP and thus
    SIP-based real-time media applications.  That is, other applications
    may use the P2P overlay layer presented here but the architecture and
    the algorithm used for this P2P overlay layer may not necessarily be
    optimal for all applications.

Sure this is our take on it, but the tie between the P2P lookup function
and SIP is, at best, one of convenience.

Greg