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

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Tue, 28 Feb 2006 14:14:21 -0500

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

---

From: s.schaelle at redus.ch (Stefan Schälle)
Date: Tue, 28 Feb 2006 20:45:04 +0100

To solve the NAT Problem, read this Articel:
http://www.brynosaurus.com/pub/net/p2pnat/

I think, with this solution, yout can solve the problem without any relays.

Stefan

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Tue, 28 Feb 2006 15:13:06 -0500

This only applies to a certain subset of NATs, namely those where STUN 
is sufficient.