Subject: [p2p-sip] I-D: An Architecture for P2P SIP

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 02 Mar 2006 14:21:37 -0500

|| That's why I'm wondering if it could be possible to use NAT traversal mechanisms in the P2P overlay in order to be able to || include NATed nodes in it (I know this is not a SIP problem but it has impact on the P2P SIP architecture).
|| Is it possible with a DHT? If possible, what are the impacts on the DHT efficiency?

I think it is possible to build a DHT including NATed nodes.
We did not consider it for simplicity.
Added complexity, in particular, for the DHT join process, seems to be a 
bigger concern than any decrease in lookup efficiency.
Philip asked about it in p2p-hackers mailing list and some people talked 
about on-going work.
Thanks.

Eunsoo

Sathya Narayanan wrote:

>>I have some questions about the supernode selection criteria. It is mentionned in your draft that "it is recommended that SNs should be on the public internet" in order to receive P2P messages.
>> 
>>
>>    
>>
>The text in the first half of this sentence provides the context to this
>recommendation. The complete line is,
>
>   When a P2P overlay network spans
>   over the global Internet and contains peers private IP addresses as
>   well as peers with public IP addresses, SNs need to perform STUN, and
>   possibly TURN server operations thus it is RECOMMENDED that SNs
>   should be on the public Internet, and publicly addressed [5][10].
>
>In this line, we are specifically talking about a P2P overlay spanning
>the global Internet. For use cases where the P2P overlay is within a
>private network, as pointed out my Phillip, this recommendation doesn't
>apply. The only mandatory requirement is,
>
>      1) MUST be able to receive messages on predetermined protocols
>      and ports from other SNs on the overlay network.
>
>If all the nodes are within a private network, they must be able to
>exchange messsages without any problem and most of the nodes can become
>a SN.
>
>We struggled with the wording for this requirement to make it applicable
>to all  use-cases. If somebody has a better suggestion, we will be happy
>to revise the text.
>
>- Sathya
>
>  
>
>>>-----Message d'origine-----
>>>De : p2p-sip-bounces at cs.columbia.edu 
>>>[mailto:p2p-sip-bounces at cs.columbia.edu] De la part de Eunsoo Shim
>>>Envoy? : mardi 28 f?vrier 2006 00:22
>>>? : P2P-SIP
>>>Objet : [p2p-sip] I-D: An Architecture for P2P SIP
>>>
>>>We submitted an I-D that describes an architecture for P2P SIP.
>>>You can get it from the link below until it appears in the IETF I-D 
>>>directory.
>>>We hope this draft can help the architecture and charter 
>>>discussion in BOF.
>>>Your comments will be appreciated.
>>>Thanks.
>>>
>>>Eunsoo
>>>
>>>http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-
>>>p2p-arch-00.txt
>>>
>>>Abstract
>>>
>>>  This document describes an architecture for peer-to-peer 
>>>SIP systems
>>>  in which a separate and independent peer-to-peer overlay layer
>>>  provides a distributed resource placement and search 
>>>service for SIP.
>>>  It also aims to help identify what should be specified for
>>>  interoperation.
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>p2p-sip mailing list
>>>p2p-sip at cs.columbia.edu
>>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>>
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>> 
>>
>>    
>>
>
>
>  
>