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

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 4 Jun 2006 17:17:19 -0700

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

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Mon, 05 Jun 2006 10:17:56 +0800

Hello David,
          I'm sorry that I don't agree to set the [bootstrap] as a part of
P2P SIP address, below is my options:
          1.Bootstrap server is used to provide some information about
existing SN to a new ON, so it will be useless for a ON after it has logged
in a P2P SIP overlay network, why should the ON always tell others this
information?
          2.There may be several bootstraps which maintained by volunteers
can be acquired in a DHT , how to select one to fill the address? 
          
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
> Sent: Monday, June 05, 2006 8:17 AM
> 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?
> 
> 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:
> 
> 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: Sun, 4 Jun 2006 20:16:47 -0700

Hi Seaward.

I'd prefer not to debate the specifics at this point -- if we can agree that
there's some kind of "p2psip:<something>" address type, I think that's as
deep as we need to get agreement on the big picture.

Basically, I'm thinking there's some kind of P2PSIP address that can be
printed on a business card, posted on a webpage, sent in an email, and so
on.  Somehow you can plug this into your P2PSIP UA, and it magically figures
out which DHT my UA is registered, then uses it to send me an INVITE.  

I'm less concerned with how this happens than with getting your agreement on
whether or not you share this goal.  This I'll ask:

1) Do you agree there should be some address that you can read off my
business card and type into your UA that somehow causes it to locate my UA
and establish a call?

2) Do you agree (1) should be accomplished by using a special
'p2psip:<something>' address type to differentiate it from a normal
'sip:<something>' address?

-david

> From: Seaward Hu [mailto:hu.xinyu at huawei.com]
> Sent: Sunday, June 04, 2006 7:18 PM
> To: 'David Barrett'; p2p-sip at cs.columbia.edu
> Subject: RE: [p2p-sip] What are we doing, question 2
> 
> Hello David,

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 4 Jun 2006 21:17:34 -0700

My amen for "p2psip:" address scheme!!

It indicates address lookup via DHT instead of via DNS SRV.

Peter

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Mon, 05 Jun 2006 14:01:26 +0800

I also agree with the address format of  "p2psip:<something>", and there
have many things as such Mr.Eunsoo pointed out in his slide need to be
specified, may we pay some attention on that?

by the way, is the iGlance base on  DHT topology?

> From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
> Sent: Monday, June 05, 2006 12:18 PM
> To: David Barrett; 'Seaward Hu'; p2p-sip at cs.columbia.edu
> > I'd prefer not to debate the specifics at this point -- if we can 
> > agree
> that
> > there's some kind of "p2psip:<something>" address type, I 
> think that's 
> > as deep as we need to get agreement on the big picture.
> >
> > Basically, I'm thinking there's some kind of P2PSIP address 
> that can 
> > be printed on a business card, posted on a webpage, sent in 
> an email, 
> > and so on.  Somehow you can plug this into your P2PSIP UA, and it 
> > magically
> figures
> > I'm less concerned with how this happens than with getting your 
> > agreement
> on
> > business card and type into your UA that somehow causes it 
> to locate 
> > my UA and establish a call?
> >
> > >           I'm sorry that I don't agree to set the 
> [bootstrap] as a 
> > > part
> of
> > >           1.Bootstrap server is used to provide some information 
> > > about existing SN to a new ON, so it will be useless for 
> a ON after 
> > > it has logged in a P2P SIP overlay network, why should 
> the ON always 
> > > tell others this information?
> fundamentally, are 
> > > > we trying to do here?  Everything feels very slippery.  
> Is there 
> > > > any consensus on any of the following issues?
> > > >
> > > > 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 
> > > > - P2PSIP 1.0 is an extension to the SIP protocol that 
> enables UAs 
> > > > to connect
> > > > 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
> > > >

---

From: jh at tutpro.com (Juha Heinanen)
Date: Mon, 5 Jun 2006 10:01:53 +0300

> 'sip:<something>' address?

i once proposed that there would be nothing special, just
sip:user at domain, where user at domain is the same as person's email
address.  when someone sends a request to that user, his user agent or
proxy would first try sip:user.domain.p2p.arpa.  this way even if user's
domain does not provide any p2p sip service, user in any domain could
still have it.

-- juha

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 5 Jun 2006 09:27:17 -0400

> agree that

I think this is a fundamentally bad idea. I shouldn't have to change  
my address (and business card) just because I'm changing some low- 
level technical detail of how signaling requests are routed. In any  
event, just like many web pages are simply listed as  
www.something.com (instead of http://www.something.com), I expect  
that many business cards and directories will simply contain  
alice at something.com.

It's the role of protocols to make these resolution details  
transparent to the user. This isn't terribly difficult in this  
particular case.

Henning

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 5 Jun 2006 08:48:34 -0500

I agree with Henning at this point, especially since I would expect many 
people would have both anyway, but my comment is based on architectural 
purity, not on technical discussions.

We DO use two different schemes (sip and sips) when it seems to make sense 
to do so. Based on discussion to date, I don't understand why using the same 
scheme for SIP-CS and SIP-P2P is a problem, and why using two different 
schemes is a solution.

Please keep talking, of course.

Spencer

---

From: jh at tutpro.com (Juha Heinanen)
Date: Mon, 5 Jun 2006 16:56:52 +0300

Spencer Dawkins writes:

 > to do so. 

the discussion on sip list seems to indicate the opposite, i.e., it does
not make sense to have both sip and sips.

-- juha

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 05 Jun 2006 16:05:10 +0200

David,

> to do here?

We are trying to "leverage the distributed nature of P2P to allow for
distributed resource discovery in a SIP network".  We _have consensus_
on this because it is the definition of P2PSIP (p2psip.org) and this is
the P2PSIP mailing list.

> [..]

Ok.

> - Nodes can choose whether to participate in or only query the DHT.

In my very personal opinion, nodes should not be able to choose whether
or not to participate in the DHT.  Instead, the DHT should be smart
enough to not require resources from nodes more than they could share,
i.e. it should apply policies based on performance metrics (e.g. uptime,
bandwidth, load...) for promoting ordinary nodes to super nodes.

>   joining the named DHT, and looking up the IP:port of the username.

Your solution is not doable in P2PSIP.  P2PSIP _is SIP_ in that:
+ both P2P and conventional UAs use SIP for communcating (INVITE,
  MESSAGE, BYE...).  This implies that they should be identifiable by
  means of sip: URIs;
+ when they are not isolated, P2PSIP domains _must_ be located by
  conventional SIP elements using procedures defined in RFC 3263.

> - Any number of DHTs can exist in parallel on the same network.  

Sure.

> - P2PSIP 1.0 does not provide any built-in authentication framework.

Not a framework, but possibly some mechanisms for achieving some level
of authentication.

> - P2PSIP 1.0 is not intended for production use; it is a prototype protocol

No.  It should be a "standard track" protcol, addressed to consumer
electronics devices as well as open source softphones.

> - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is finalized, not before.

Ok, let's start from version 0.0 ;-)

Enrico

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 5 Jun 2006 10:29:03 -0400

I would agree, and would add a subtly different objection that a
traditional SIP UA will be better able to interact with a P2PSIP
endpoint if we have a simple "sip:" or "sips:" (however that debate
hashes out).

David

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 5 Jun 2006 09:30:25 -0500

> not make sense to have both sip and sips.

(way off topic for this list, but I believe that what doesn't seem to make 
sense on the SIP list is having a "secure SIP" that provides no SIPS 
guarantees beyond what SIP guarantees - but the point I was trying to make 
was that we have chosen two different schemes when we THOUGHT there was a 
good reason, ignoring whether we were correct or not. Juha's summary of the 
current viewpoint on sip/sips matches my understanding.

Thankks,

Spencer

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Mon, 5 Jun 2006 11:19:41 -0400

David:

You made many good points, but the idea of "p2psip:<something>" address
type is the anti-thesis of the very idea of  p2psip.

If it uses address other than sip, it is not sip - it can be pip, spip or 
whatever;-)
If it uses a server in the network, then it is not a p2p but something else.
If it uses a server to boot, it is not meant for ad-hoc networks.
If it is not meant for ad-hoc networks, then someone will ask for asip (a 
sip of adhoc
networks and a new address asip:<something>  ;-))
and the list goes on..

Address mapping from one domain to another can easily be incorporated in any
protocol design (example, email to sms  and vice versa. It is done all the 
time) . But
that is not where most of the problemsof p2p sip are, the problems are in 
other areas
that  you  have excellently listed in your mail.

The another big problem is that, the  proposed charter is badly defined with 
people
proposing multiple versions of sip based on different architectures, 
different type of DHTs,
and this and that. There is neither a clarity nor any consensus here.

cheers,

--bk

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon, 5 Jun 2006 10:46:39 -0500

> My amen for "p2psip:" address scheme!!

Banish this thought for the reasons explained by Henning Schulzrinne.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Peter Pan
Sent: Sunday, June 04, 2006 11:18 PM
To: David Barrett; 'Seaward Hu'; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] What are we doing, question 2

Peter

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 08:57:59 -0700

Ok, I'll totally agree that it'd be nice to hide the details of P2PSIP
behind a standard "sip:" address (expressed or implied).  I just haven't
envisioned how to accomplish this in conjunction with the other
requirements, and I'm trying to avoid proposing what I can't figure out how
to build.

The problem I see isn't one of technology, but usability issues caused in
the adoption period.  Clearly, P2PSIP isn't going to happen overnight.
There will be period of years where it is slowly rolled out to SIP UAs.  And
during this period, I think it's important for a UA to differentiate between
invalid SIP addresses, and P2PSIP addresses that it doesn't know how to
handle.

For example, let's assume I put my P2PSIP address on a business card as
"sip:dbarrett at quinthar.com" (or just "dbarrett at quinthar.com" with the "sip:"
implied).  A P2PSIP-aware UA might first look for a traditional SIP proxy at
"quinthar.com" and then, not finding one, use some DHT-based mechanism.  I
love that idea.

But a P2PSIP-unaware UA will just break.  It'll say the address is valid and
supported, but broken.  I don't love this idea.

Thus I'm proposing, at least at the start while P2PSIP is getting its legs,
we use "p2psip:<something>".  A P2PSIP-aware UA will work, and a
P2PSIP-unaware UA can clearly say "I don't support this address type".  The
blame is placed on the UA (where it should be), rather than the address.

Maybe in the future, once P2PSIP is more established, UAs would
automatically retry all failed "sip:<something>" addresses on some P2PSIP
framework, and then the two addresses would converge down the road.  

But I'm not sure how we can start out converged without just confusing the
user and, ultimately, hurting the SIP community as a whole -- P2P and
otherwise.

Have I missed something?  Can you see a way to roll out P2PSIP atop a
standard "sip:<something>" address without appearing totally broken
throughout the deployment period?

-david

> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On Behalf Of
> David A. Bryan
> Sent: Monday, June 05, 2006 7:29 AM
> To: Henning Schulzrinne
> Cc: David Barrett; p2p-sip at cs.columbia.edu

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 5 Jun 2006 09:01:31 -0700

>   conventional SIP elements using procedures defined in RFC 3263.

Why is P2PSIP restricted to sip/sips?

Unless failover (from DHT to DNS, or vice versa) time can be "optimized" to
both care user experience (not timeout too slow, eg. 64*T1) and false
positive (not timeout too soon), leaving ambiguity in uri scheme seems
unnecessary.

Or, forked lookup is anticipated? Why should I wear two pants if I live in
Taiwan only??

> > - Any number of DHTs can exist in parallel on the same network.

Impractical. Wishing for miracle, still.

> Not a framework, but possibly some mechanisms for achieving some level

Not a problem likely, if link-layer (p2p, not L2) security is included from
day one.

> Ok, let's start from version 0.0 ;-)

0.0=A.A (Amateur.Academic)?

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 5 Jun 2006 09:13:05 -0700

----- Original Message -----
From: "Spencer Dawkins" <spencer at mcsr-labs.org>
Sent: Monday, June 05, 2006 7:30 AM
Subject: Re: [p2p-sip] What are we doing, question 2

> current viewpoint on sip/sips matches my understanding.

SIPS seems less feasible in P2P SIP than in CS SIP, because TLS can copy the
scalability problem seen in real world (almost none uses TLS or even TCP in
commercial practices), unless SIPS will be use SSL/TLS over UDP and nodes
can learn themselves outside NAT in advance, SIPS uri scheme seems
theoretically useful in P2P SIP.

---

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

(iGlance uses a central server, btw.  Some details at
http://www.iglance.com/code.html)

> Sent: Sunday, June 04, 2006 11:01 PM
> To: 'Peter Pan'; 'David Barrett'; p2p-sip at cs.columbia.edu

---

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

> Or, forked lookup is anticipated? Why should I wear two pants if I live in

Forked lookup sounds like a good long term strategy, but a confusing short
term strategy.

> Impractical. Wishing for miracle, still.

I'm not sure it's impractical, though I agree it might not be necessary for
1.0.

> Not a problem likely, if link-layer (p2p, not L2) security is included

Despite arguments that it's impossible, virtually all of the most widely
used protocols successfully added security after 1.0.  TCP, HTTP, FTP, RSH,
SMTP, POP, IMAP.  I'm skeptical that our problem set is so much more
challenging that we need to tackle it up front (or that we're so much
smarter that we can, or so much dumber that we cannot add it later). 

> 0.0=A.A (Amateur.Academic)?

Whatever the nomenclature, we should have prioritization and protocol
versioning at the top of our mind.  Otherwise we continue trying to be all
things to all people right off the bat.

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 5 Jun 2006 23:54:45 -0500

> supported, but broken.  I don't love this idea.

If you intend your P2PSIP overlay to be useful, you'd better have a   
resolver/introducer/rendezvous/whatever server at quinthar.com to  
make this route resolve for a stadnard SIP client.

Otherwise, we're not defining P2P uses of SIP, we're defining some  
new protocol that, well, isn't SIP.

--
Dean

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 6 Jun 2006 00:10:17 -0700

> From: Dean Willis [mailto:dean.willis at softarmor.com]
> 

I totally agree that in the long term, the gulf between P2P and
client/server SIP needs bridging.  But I'm not sure it *needs* to be done in
v1.0 of P2PSIP.  I think useful work can be done on a v1.0 P2PSIP standard
that doesn't address this problem.

For example, in my previous email, I sketched out a vision for how P2PSIP
could be used in an environment totally devoid of client/server SIP.  If
that's the best we can do for v1.0 P2PSIP, I count that as a success even
though it means your CS-only UA couldn't call my P2P-only UA because I
haven't registered an address on a traditional SIP proxy.

However, it's easy to imagine that my P2P UA could call your CS UA: I click
"Add a buddy" and enter "sip:dean.willis at softarmor.com", and my P2P UA
recognizes it as a client/server address and treats it accordingly.

Likewise, the reverse is also easy to imagine: I click an "Add an address"
button and type "sip:dbarrett at softarmor.com", and register my UA on your
traditional SIP server.

And finally, it's easy to imagine that I (the founder of the 'quinthar' DHT)
enable non-P2P UAs to contact P2P users on my DHT by putting up a P2P
gateway at "quinthar.com".  Thus when you type "sip:dbarrett at quinthar.com"
into your non-P2P UA, your UA treats my gateway as if it's a standard SIP
proxy.  But when someone types "sip:dbarrett at quinthar.com" into a
P2P-enabled UA, it uses my gateway as a bootstrapping server to join the
"quinthar" DHT, and then never talks to it again.

Basically, for v1.0, it seems useful and easiest to not worry too much about
interoperation between traditional and P2P SIP UAs.  There exist a variety
of options to bridge the gap down the road.

-david

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 6 Jun 2006 08:32:31 -0700

I wonder why interoperation between traditional and P2P SIP UAs is a worry
when P2P SIP UAs have SIP stack inside. The interoperation seems tiny
compared with most other P2P issues.

I wonder too why security cannot be in 1.0 when security seems the paramount
in modern p2p networks (even unencrypted file sharing networks use some way
or other to assure file integrity), SPKI technology is growing rapidly (you
can say Skype uses it) and voip in 21th century without security seems like
a homework (or a joke).

Peter

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 6 Jun 2006 10:03:25 -0700

I totally agree they're important and not difficult.  But they're nonzero
effort (discussion, documentation, review, standardization, implementation,
testing, verification, etc, etc.) and we need to focus on the smallest
possible set of features in order to make headway.

Once P2PSIP v1.0 is established, then these are critical priorities for
v2.0.

-david

> Sent: Tuesday, June 06, 2006 8:33 AM
> To: David Barrett; 'Dean Willis'
> Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'
> > client/server SIP needs bridging.  But I'm not sure it *needs* to be
> done
> in