Subject: [p2p-sip] What are we doing, question 2

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Mon, 5 Jun 2006 08:43:18 -0700

My view of the P2P-SIP world ...

> - P2PSIP 1.0 is an extension to the SIP protocol that enables UAs to
connect to and participate 
> in a DHT that performs the basic functionality of a SIP proxy.
<KS>
	DHT is not important, but the P2P nature is. "participate in a
Peer-to-peer network" is more accurate. DHT is one such mechanism. There
could be (and will be) others ...
</KS>
> 1) Does P2PSIP require DNS?
<KS> 
	May be. As a well known anchor point, DNS is a good choice than
any other bootstrap mechanism. One good use is the Bonjour/zeroConf.
</KS>
> - P2PSIP 1.0 does not provide any built-in authentication framework. 
<KS>
	We should.
</KS>
> 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? 
<KS>
	Yep, definitely. Might not be that easy 
</KS>
> 5) Does P2PSIP require any central servers (other than, potentially,
DNS)? 
<KS>
	Nope 
</KS>
> 6) Does P2PSIP use a DHT?
<KS> 
	Yes, but not essential. We are looking for a scalable P2P
substrate.
</KS>
> 7) Does P2PSIP work with non-P2PSIP UAs? 
<KS>
	yep.
</KS>
> 8) Does P2PSIP use modified SIP messages or some new syntax? 
<KS>
	Nope
</KS>
> 9) Does P2PSIP support secure authentication? 
<KS>
	Yep
</KS>
> - Nodes can choose whether to participate in or only query the DHT.
<KS>
	Too much into DHT. Not needed. 
</KS>
> - A new SIP address type is created to differentiate between
client/server
>   and P2P proxies: p2psip:<username>[@<dhtname>@[<bootstrap>]]
<KS>
	Absolutely not. Why do we need this ? Whether it is a P2P SIP or
"normal" SIP should be transparent.
</KS>
> - <bootstrap> is the IP:port or domain name of any P2PSIP UA; if left 
> unspecified it is assumed to be any of a well-known 
> collection of public bootstrapping nodes maintained by volunteers.
<KS>
	Sounds OK. Possibly a DNS based substrate
</KS>
> - Resolving a P2PSIP address consists of contacting the bootstrapping
node,
>   joining the named DHT, and looking up the IP:port of the username.
<KS>	
	Essentially Yes 
</KS>
> - Any number of DHTs can exist in parallel on the same network. 
<KS>
	Yes
</KS>
> - P2PSIP 1.0 is not intended for production use; it is a prototype
protocol 
<KS>
	Nope
</KS>
> - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is 
> finalized, not before.
<KS>
	But we can discuss P2PSIP 3.0 while 1.0 is in progress ;o)
</KS>

Cheers
<k/>

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
> Sent: Sunday, June 04, 2006 5:17 PM
> To: p2p-sip at cs.columbia.edu
> Subject: [p2p-sip] What are we doing, question 2
> 
> I'd like to reitereate Cullen's question: what, 
> fundamentally, are we trying to do here?  Everything feels 
> very slippery.  Is there any consensus on any of the following issues?
> 
> 1) Does P2PSIP require DNS?
> 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses?
> 3) Does P2PSIP work for 2 devices?
> 4) Does P2PSIP work for 2B devices?
> 5) Does P2PSIP require any central servers (other than, 
> potentially, DNS)?
> 6) Does P2PSIP use a DHT?
> 7) Does P2PSIP work with non-P2PSIP UAs?
> 8) Does P2PSIP use modified SIP messages or some new syntax?
> 9) Does P2PSIP support secure authentication?
> 
> I don't mean this as a critique, but I don't feel like we're 
> gathering toward consensus on any of these points.  Thus 
> perhaps we should choose a new tactic?
> 
> I like Enrico's quick enumeration of his vision for P2PSIP.  
> I expect were we all to give it a shot, we'd find 2-4 basic 
> variations.  Maybe once we have those we can name them in a 
> totally vague way and grapple with the subject from a new perspective.
> 
> Thus here's my quick-bullet summary of the P2PSIP I'd like to 
> see standardized; I'm eager to hear yours:
> 
> - P2PSIP 1.0 is an extension to the SIP protocol that enables 
> UAs to connect
>   to and participate in a DHT that performs the basic 
> functionality of a SIP
>   proxy.
> - Nodes can choose whether to participate in or only query the DHT.
> - A new SIP address type is created to differentiate between 
> client/server
>   and P2P proxies: p2psip:<username>[@<dhtname>@[<bootstrap>]]
> - <dhtname> is any string; if unspecified it is assumed to be 
> "global".
> - <bootstrap> is the IP:port or domain name of any P2PSIP UA; if left
>   unspecified it is assumed to be any of a well-known 
> collection of public
>   bootstrapping nodes maintained by volunteers.  
> - Resolving a P2PSIP address consists of contacting the 
> bootstrapping node,
>   joining the named DHT, and looking up the IP:port of the username.
> - Any number of DHTs can exist in parallel on the same network.  
> - P2PSIP 1.0 does not provide any built-in authentication framework.
> - P2PSIP 1.0 is not intended for production use; it is a 
> prototype protocol
> - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is 
> finalized, not before.
> 
> I have no idea if this is similar to anyone else's vision, 
> but I'll name this stake in the ground the "decentralized 
> proxy" proposal given that it aims to do no more than 
> decentralize the most basic client/server SIP proxy functions.
> 
> How would you summarize and name your vision?  How does it 
> differ from mine and everyone else's?
> 
> -david
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 09:15:02 -0700

Hi Krishna, I agree with most of your points should eventually be covered by
P2PSIP, but I disagree they should be part of P2PSIP *1.0*.

In other words, are you proposing we can't do *anything* until we accomplish
*all* of your requirements?

I like the idea of using Bonjour/zeroConf.  Same for generalizing for
multiple P2P networks, DHT algorithms, mobile IPs, address transparency,
etc, etc.  But I do not like the idea of holding up the boat until *all* are
on board.

So what I'm really asking is for more aggressive prioritization.  What is
the smallest set of requirements that you believe should be in the 1.0
release?  What is the absolute smallest set of functionality that can be
built and standardized in order to help us learn how to make P2PSIP 2.0?

-david

> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com]
> Sent: Monday, June 05, 2006 8:43 AM
> To: David Barrett; p2p-sip at cs.columbia.edu
> Subject: RE: [p2p-sip] What are we doing, question 2
>

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 5 Jun 2006 17:37:40 -0700

On Jun 5, 2006, at 9:15 AM, David Barrett wrote:

>  What is
> release?

My personal opinion ... Interoperable communications between devices  
from different vendors while minimizing the expense of any "central"  
server equipment that is not operated/owned by the end user. I  
believe we could achieve a system where after initial enrollment, no  
"central servers" were needed for operational calls between P2P  
enabled clients.