Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00

[Philip Matthews <[e-mail]>]

Hannes:

Thanks for the references.

 From a quick read of your documents, it seems like they might form  
the basis
of some extensions to our proposal.

However, your document is talking about Client-Server SIP, while ours  
is talking about P2PSIP,
and this seems to  allow us to  do things that you cannot do.

For example, one of the things we like about our approach is
that we can mostly hide the application the face that it is running  
in an overlay.
In other words, we want to take existing applications that work in
a non-overlay environment and make them work in a P2PSIP overlay  
without  change.
We are trying to do this by doing the HIP stuff behind existing APIs  
to the extent possible.
We don't succeed in every case, but the degree to which we do succeed  
is interesting.

- Philip

On 17-Jun-07, at 15:07 , Hannes Tschofenig wrote:

> Hi Phillip,
>
> you might also find these two documents of interest for you:
>
> Interaction between SIP and HIP
> http://www.tschofenig.com/svn/draft-tschofenig-hiprg-host- 
> identities/draft-tschofenig-hiprg-host-identities-05.txt
>
> Using SRTP transport format with HIP
> http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-srtp/draft- 
> tschofenig-hiprg-hip-srtp-02.txt
>
> Ciao
> Hannes
>
> Philip Matthews wrote:
>> Folks:
>>
>> Eric Cooper, Alan Johnston, and I have just written a draft that  
>> suggests what we think
>> is an interesting direction for the P2PSIP working group.
>>
>> We argue that a P2PSIP overlay should use HIP (the Host Identity  
>> Protocol)
>> to provide a number of the basic features in an overlay, namely:
>>     o  Peer IDs;
>>     o  Transporting messages around the overlay;
>>     o  Signaling new overlay connections;
>>     o  Supporting mobility and multi-homing of peers;
>>     o  Providing message security.
>>
>> One of the reasons we really like this idea is because, using the  
>> approach
>> described in the draft, many existing applications don't require  
>> any modifications
>> and "just work" in an overlay.
>>
>> We describe this idea in a draft that has just been submitted.
>> Until the draft appears in the archives, you can get a copy at
>>     http://www.magma.ca/~philip_matthews/draft-willis-p2psip- 
>> concepts-04.txt
>> or for the html version
>>     http://www.magma.ca/~philip_matthews/draft-willis-p2psip- 
>> concepts-04.htm
>>
>> Here is the abstract from the draft:
>>    This document examines a P2PSIP architecture where the peer-to- 
>> peer
>>    (P2P) layer is separate from and lies below the SIP layer.  We
>>    discuss the functions of the P2P layer in such an architecture,  
>> and
>>    focus in on the Distributed Transport function - the function that
>>    allows a peer to exchange messages with any other peer in the
>>    overlay, even in the presence of NATs.  We list the features  
>> that the
>>    Distributed Transport function needs to provide, and observe  
>> that the
>>    Host Identity Protocol (HIP) already provides a number of these
>>    features.  We then propose extensions to HIP that allow it to  
>> provide
>>    the missing features.  We discuss how a complete P2PSIP  
>> architecture
>>    can be built around HIP, and contrast this approach with other
>>    approaches for implementing a P2P layer.  Two of the advantages of
>>    HIP approach are that (a) most existing applications can run in an
>>    overlay without needing any changes and (b) peer mobility and NAT
>>    traversal are handled in a way that is transparent to most
>>    applications.
>>
>> - Philip
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>


_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip