Subject: [Sipping] SIP P2P draft

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Jan 2005 21:51:22 -1000

David Bryan and I have submitted an draft of some early ideas on P2P with
SIP. Until it shows up in the repository, you can find it at

http://p2psip.org/

Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 21 Jan 2005 10:27:26 -0500

Cullen,
thanks for the interesting draft.

Some very high level questions based on first read:

a) Is it possible to avoid sending a user registration for a node and
just rely on node registration for means of communication/location ? I
am not sure if subsequent INVITEs can be routed using the node
information and not the user information if so required (for specific
P2P elements that serve only one static user, for example). I
understand that user registrations have a larger expiry time in sync
with regular SIP registrations (3600 or so) and eliminating this
message may not really have an effect on significant reduction of
message flow - I just want to understand if not doing this would break
subsequent call setups between nodes.

b) Is there a mechanism using which "default routes" (for lack of a
better term) can be used to connect two p2p systems that use the same
protocol (SIP) but do not know about each other ? This is what comes
to mind: p2p n/w A (PA) has a bunch of 100 users while p2p n/w Z (PZ)
has another bunch of 100 users and the users of PA want to "scout" the
SIP network to see if there are other communities willing to join
their "chat" network.   This is different from pro-active joining of a
community.
Ideally, here, it could be possible that there are a network of
standard SIP proxy servers between PA to PZ who can help them reach
each other. However, once PA and PZ touch base with each other, they
would most likely form an extended overlay network and the proxies
that connected them would not be in the loop.
Ideally, the proxies should not have to maintain state or need to
recognize p2p extensions for maximum reachability / scalabilty.

Is there a mechanism to acheive this or is this not the philosophy of
this approach ?

regds
arjun

-- 
Arjun Roychowdhury

---

From: David Bryan <[email-masked]>
Date: Fri, 21 Jan 2005 15:31:38 -0500

On Fri, 2005-01-21 at 10:27, Arjun Roychowdhury wrote:

Hi Arjun, I'm not 100% sure if I understand what you are asking, but
I'll take my best shot.

> subsequent call setups between nodes.

In our current design, node registrations really only allow a node to
enter the overlay. In other words, node registration allows a node to
enter and participate in the sense of storing user registrations,
forwarding messages, etc. Node registration doesn't register any
information about a user at all. 

I think it makes sense to keep those separate. A node may be a p2p sip
enabled UA, in which case 1 user = 1 node, but if you had a proxy that
was p2p aware, it could have many users, each requiring a separate user
registration. In this case, the proxy is the only node, and so only one
node registration would be required. -- many users = 1 node.

Invites are routed based on the hash of the user name, and when that
node is found, the user registration is looked up. The way we structured
it in our draft, eliminating the node registration would break things,
but of course other designs might be different.

> Is there a mechanism to acheive this or is this not the philosophy of

We don't have much in the draft about this, other than the fact we
briefly talk about different overlay names, but yes, ultimately we would
like users in separate overlays to be able to communicate with each
other. One possible approach would be bridge nodes -- nodes that are in
both overlays that serve as intermediaries. Completely merging the
networks is possible, but is actually a pretty thorny problem, and may
not be the desired behavior in most cases. 

We originally had a subsection of section 6 (Architecture) called
"Hierarchy" that was going to deal with discussing this -- how to create
special nodes to bridge between different overlays, but we took it out
because we hadn't gotten very far on thinking about it, and the draft
already had lots of open questions. I agree with you -- we ultimately
need a good way to handle this issue, and hopefully we can get some good
discussion on the best way to do that.

--David

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Jan 2005 10:39:09 -1000

good thoughts - thanks - some comments inline

> subsequent call setups between nodes.

Yes, we probably could do what you suggested - I guess we are still trying
to work how this will all happen with devices behind NATs and TLS sip
signaling - we were thinking it might be useful to have devices that were
registered with some of the nodes but not part of the DHT.

> recognize p2p extensions for maximum reachability / scalabilty.

Interesting - I really don't have my head around how various overlay
networks can connect and also how they can bridge into traditional DNS SIP
routing networks - I think these are good problems to figure out.

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 21 Jan 2005 16:32:04 -0500

Cullen, Bryan,
A parting shot for now:

The reasoning behind why I wondered how regular SIP entities would
help such a network was  simpler: Besides the fact that SIP messages
are being used for a P2P network, is there anything else common
between the traditional SIP architecture/goals and this ?

In otherwords, if every interaction between traditional SIP and p2p
SIP must happen via adaptors, what really is the advantage of using
SIP here ? Why not just use an existing p2p protocol and write an
adaptor for the same ?

I would like to see the motivation better explained in the draft of
the benefits of using SIP here as well as how an existing SIP
infrastructure may be re-used to leverage additional functionality
(hence  "scout for networks" came to mind as one example)

I understand that the work is just beginning, but do you think it may
be worth discussing how such an overlay network can benefit from an
existing network & an existing architecture somewhere in the draft ?
If its already described somewhere, apologies, I may have missed it.

regds
arjun

-- 
Arjun Roychowdhury

---

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Jan 2005 17:25:58 -0600

David, Cullen -

Thanks for putting all the effort you have into this draft so far.
I'm very excited about the potential a more p2p oriented use of SIP has,
and will be contributing to the discussions this draft is bound to kick 
off.

I especially appreciate the "early ideas" disclaimer you put in this
announcement (and wish the draft had done so more explicitly).

One of the things were going to discover is that this whole problem 
space
is especially prone to discussion by jumping to mechanism. This draft 
has
quite a bit of under-motivated mechanism in it, and I ask anyone that's
interested in this topic to dive into "why we're doing this" before 
diving
into arguments about "what's in this header".

This is an effort where the desire to skip a requirements document step
will be fatal. When we look at those requirements, I suspect we'll 
decide
that a lot of the mechanism that went into the proof-of-concept work 
isn't
quite right and that mechanism will change in drastic ways (I'm betting 
that
if we get to the end-game, we'll find ourselves leveraging SIP-Events 
for
example).

Here is a subset of the requirements discussions we're going to need to 
have
before a serious shot a mechanism should be attempted:

   - Foremost: What does this really buy us that we don't already have? 
You've provided
     a start, but we need to capture this in much more detail before any 
of this conversation
     is really going to make any sense.

   - What does identity mean in such a network? How will assertions of 
identity
     be made, and what aspects of participation will rely on those 
assertions
     (Can you join anonymously, or only with a trusted identity 
assertion? Once you're
      in, can you store state on a peer anonymously? What does it mean 
to have more
     than one identity service involved? How do you deal with assertions 
of an identity
     from more than one authority?)

  - Is there one p2p network using SIP or many? (i.e. is there more than 
one thing
    in the universe with node-id 1). If one (and I think there are 
compelling reasons
    for just one), how do allow for subsetting the namespace? (In the 
draft, you name
    overlay networks, but don't talk about how that namespace is 
managed).

  - How do you address extensibility and versioning? Once one of these 
is in the
    wild, we're going to need good tools to affect its behavior.

  - How does this leverage or replace DNS? Where does the role for 
finding things
    really live? I expect this to be one of the more spirited 
discussions and will
    have quite a bit of impact on mechanism.

  - What's required of a node that's storing stuff for other peers? What 
are the requirements
     on the system for reacting to things like, say, a node that 
unwittingly finds itself responsible
     for a _very_ popular resource.

  - What are the kinds of state this network will hold? You're already 
talking about presence
    over this network - I've seen early discussions about having a 
voicemail-like application
    live in this space. I suspect we'll be talking about storing our 
buddy-lists off on other peers
    before long.

  - What are the privacy and security requirements we're going to place 
on such a network?
     (Do we ask peers to store state they cannot inspect? You call out 
the Sybil attack - are
     we required to be resilient against it? How about just individual 
nodes that are intentionally
     introducing bad state.)

- What are our requirements for dealing w/ firewall,nat, or other 
network inequities?
    If we follow the suggestion in Henning's reports of having things 
behind nats
    work through a relay that's on the ring and in a public space, what 
control do we
    give clients over what relay they use? What control do we give those 
peers that
    could be these relays over who they relay for?

This isn't a meant to be a comprehensive list of issues, but I hope it 
starts to point out
the need for and scope of the requirements discussion that will be our 
first step.

Thanks again for kicking this off. I look forward to finding out how 
much interest there
is in this concept and working with those that find the potential as 
exciting as I do.

RjS

---

From: "Banibrata Dutta" <[email-masked]>
Date: Mon, 24 Jan 2005 19:43:25 +0530

Hi Arjun:

I think the P2P adaptor's purpose is to adapt regular SIP UA's, i.e. which
are not P2P aware,
thus allowing a migration-path for the existing users, providers protecting
their present investments.

best regards,
Banibrata Dutta.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Arjun Roychowdhury
> Sent: Saturday, January 22, 2005 3:02 AM
> To: Cullen Jennings
> Cc: sipping
> Subject: Re: [Sipping] SIP P2P draft
> 
> Cullen, Bryan,
> A parting shot for now:
> 
> The reasoning behind why I wondered how regular SIP entities 
> would help such a network was  simpler: Besides the fact that 
> SIP messages are being used for a P2P network, is there 
> anything else common between the traditional SIP 
> architecture/goals and this ?
> 
> In otherwords, if every interaction between traditional SIP 
> and p2p SIP must happen via adaptors, what really is the 
> advantage of using SIP here ? Why not just use an existing 
> p2p protocol and write an adaptor for the same ?
> 
> I would like to see the motivation better explained in the 
> draft of the benefits of using SIP here as well as how an 
> existing SIP infrastructure may be re-used to leverage 
> additional functionality (hence  "scout for networks" came to 
> mind as one example)
> 
> I understand that the work is just beginning, but do you 
> think it may be worth discussing how such an overlay network 
> can benefit from an existing network & an existing 
> architecture somewhere in the draft ?
> > networks can connect and also how they can bridge into 
> traditional DNS 
> > SIP routing networks - I think these are good problems to 
> figure out.
> > 
> 
> --
> Arjun Roychowdhury
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 24 Jan 2005 09:25:58 -0500

Thanks Banirban - I understand that.

My point, which was further amplified by Robert's mail, was that as of
now, there is not enough motivation in the draft to explain why SIP is
being used when the only communication between standard SIP and p2p
SIP networks is via an adaptor and it does not seem to be leveraging
the benefits of standard SIP networks.

I'm sure its an exciting area though I'd like to take a step back as
well to understand the requirement and the motivation for SIP.

regds
arjun

-- 
Arjun Roychowdhury

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jan 2005 19:00:13 -0500

I also appreciate this work, and think it is worth continuing discussion 
on documentation on the subject.

Robert lists potential requirements below. However, I don't see them as 
requirements per se; mostly they seemed like questions around how a 
particular problem is addressed when building a p2p network.

The real requirements question is whether our aim is to build p2p just 
for sip, or to build a generic p2p protocol (i.e., an implementation of 
chord and bootstrapping techniques) that provide a generic p2p service. 
In particular, one might imagine a protocol that effectively exposes an 
API on participating hosts which, given a resource name, a hashing 
mechanism, and a p2p system ID (i.e., which p2p network), it returns the 
IP address of the place where that resource can be found. Such a generic 
protocol would support joins, leaves, and so on. From my brief reading 
on p2p literature it seems like this decomposition is common.

In essence, is the goal to build a generic, standardized p2p toolkit 
ontop of which we can build lots of p2p applications, or is it just to 
make sip p2p and do it in a sip specific way?

I will note that, even once you have developed such a toolkit, serious 
questions remain about how it could be used by SIP for the purposes of 
building a p2p network. The primary issue is security, of course. SIP 
specifies its behaviors logically speaking; a proxy is just a role, and 
it runs on a host at a specific IP address. Same with registrars, 
presence servers, etc. If you envision that the p2p protocol effectively 
  provides an alternative to DNS - a way to find my proxy, or find my 
presence server - then we could make SIP p2p by just replacing rfc3263 
with that mechanism.

But it wouldn't work, of course. The reason is entirely security. SIP 
assumes a trust relationship that has proxies and presence servers as 
privileged systems - ones that users implicitly trust. p2p breaks that. 
Thus, the challenge is entirely how to adapt sip to trust models whereby 
the provider is an untrusted element by the user. Such an "extension" to 
address doing that might even be useful in systems where the server is 
still centrally located via DNS - for example a sip proxy run by a 
coffee shop I happen to step into. Why should I trust them?

A fair question to ask is whether certain features we want (like dialing 
911 or protecting presence data from prying eyes) can ever reasonably be 
accomplished in the differing trust models provided by p2p systems.

One of the big technical issues is NAT traversal. I think that is 
actually not so hard. We have all of the tools already - ICE in 
particular is a p2p traversal technique. ICE relies on STUN and TURN. 
Currently, it assumes that the STUN and TURN servers are centralized. 
But, they need not be. Instead, we could have them as peer components, 
and we use the p2p network to locate those too. There, finding them is 
interesting. The requirement is that you can be a TURN or STUN server if 
you are on the public Internet. Thus, its not really a search for a 
single resource by name, but rather a search for any resource with a 
particular property. Not sure how that could be done in chord, worth 
considering some more.

Once you place the TURN and STUN server functions in peer nodes, ICE can 
be used as is for the media traversal. You need to apply it to SIP 
registrations and signaling as well. The first step is to use the 
methodology for registered contacts; you'd register sevreal of them. 
Thus, when the caller gets the 302 from the registrar, it sends an 
INVITE to all contacts and picks the one with the highest priority that 
succeeded.

Thus, the problem reduces to dealing with the case where the proxy 
itself doesn't have a public IP. I'd argue that this is probably a 
problem that needs to be solved in the generic chord protocol I mention 
above; what to do when a node has a private ID? The answer is TURN, I 
think; certain servers known to be on the public nework (i.e., 
supernodes) are always-available TURN servers. A new node joining the 
network finds these, and can determine whether it is on the public 
network by an ICE-style connectivity check with known TURN servers 
(though as folks know I dislike checking for whether you are behing a 
nat, but I don't see how to avoid it here). If that check succeeds on 
multiple servers (and fails on none), it adds itself to the TURN server 
list. Nodes not on the public Internet would then allocate an IP/port 
from a TURN server that it finds. That IP/port would be used as its 
identifier in the chord algorithm. My guess is that there are security 
and naming implicatoins there, need to think about it.

Anyway, these are just some initial thoughts.

Thanks,
Jonathan R.

Robert Sparks wrote:

> One of the things were going to discover is that this whole problem space
> is especially prone to discussion by jumping to mechanism. This draft has
> interested in this topic to dive into "why we're doing this" before diving
> will be fatal. When we look at those requirements, I suspect we'll decide
> that a lot of the mechanism that went into the proof-of-concept work isn't
> if we get to the end-game, we'll find ourselves leveraging SIP-Events for
> example).
> 
>      in, can you store state on a peer anonymously? What does it mean to 
> have more
>    overlay networks, but don't talk about how that namespace is managed).
> 
>  - How do you address extensibility and versioning? Once one of these is 
> in the
>    really live? I expect this to be one of the more spirited discussions 
> and will

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Jan 2005 19:15:29 -0600

On Jan 27, 2005, at 6:00 PM, Jonathan Rosenberg wrote:

> Robert lists potential requirements below. However, I don't see them 
> as requirements per se; mostly they seemed like questions around how a 

Agreed - I wasn't listing requirements, I was pointing to some of the
discussions we would have to have to figure out what the actual
requirements are.

RjS

---

From: "Jason Arnold" <[email-masked]>
Date: Thu, 27 Jan 2005 17:41:11 -0800

Couldn't an altered open source mechanism like OSP (Open Settlement
Protocol) utilizing OSP tokens potentially satisfy the security issues, QoS,
resolve separate P2P settlement issues and potentially more items listed by
Robert?

Jason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Rosenberg
Sent: Thursday, January 27, 2005 4:00 PM
To: Robert Sparks
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] SIP P2P draft

Thanks,
Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 28 Jan 2005 17:28:21 -0800

I did look at OSP a bunch and thought about the P2P aspects of. (I even
helped on one of the implementations of OSP). I think the thing about OSP,
is that the clearing house becomes the central server. David and I were
trying to make a system that allowed the rendezvous function of SIP without
a central server.

---

From: "Jason Arnold" <[email-masked]>
Date: Sat, 29 Jan 2005 14:27:48 -0800

Perhaps from a service provider's point of view, a central server deployment
"could" work today as they (service providers) already utilize SBC's not
creating an unknown issue.  It is clear that in its present form OSP does
not meet your objective however the scenario that Jonathan described below
is a possible solution for Proxy NAT Traversal, It would seem that this idea
could be extended to an OSP model, substitutions required:

"Thus, the problem reduces to dealing with the case where the proxy itself
doesn't have a public IP.  I'd argue that this is probably a problem that
needs to be solved in the generic chord protocol I mention above; what to do
when a node has a private ID? The answer is TURN, I think; certain servers
known to be on the public nework (i.e., supernodes) are always-available
TURN servers. A new node joining the network finds these, and can determine
whether it is on the public network by an ICE-style connectivity check with
known TURN servers (though as folks know I dislike checking for whether you
are behing a nat, but I don't see how to avoid it here). If that check
succeeds on multiple servers (and fails on none), it adds itself to the TURN
server list. Nodes not on the public Internet would then allocate an IP/port
from a TURN server that it finds."

Question: Could required OSP server functions be incorporated in to client
software?  

If it was possible to extend OSP server functions to the client (which would
in effect become a "mini node") each mini node could authenticate between
other mini nodes or nodes utilizing a public network (super node) to "join"
the network/super community. 

I feel that there is a potential to utilize OSP to overcome many issues, if
this idea has been thoroughly explored already and I am off track, please
let me know.

Jason

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: Friday, January 28, 2005 5:28 PM
To: Jason Arnold
Cc: sipping
Subject: Re: [Sipping] SIP P2P draft

Jason 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]
<mailto:[email-masked]%5d>  On Behalf 
Of Jonathan Rosenberg 
Sent: Thursday, January 27, 2005 4:00 PM 
To: Robert Sparks 
Cc: Cullen Jennings; sipping 
Subject: Re: [Sipping] SIP P2P draft 

Thanks, 
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 30 Jan 2005 09:36:45 -0500

I don't understand what the role of OSP would be in a model where the 
"clearinghouse" is on a client. The entire OSP model is built on a trust 
relationship that has providers A,B,C.. and a central provider X. There 
is trust between A and X, B and X, C and X, but each of the regular 
providers (A,B,C) does not trust each other. By placing the OSP server 
in an endpoint, that trust relationship changes and thus OSP seems 
pointless.

-Jonathan R.

Jason Arnold wrote:

> Perhaps from a service provider’s point of view, a central server 
> deployment “could” work today as they (service providers) already 
> utilize SBC’s not creating an unknown issue.  It is clear that in its 
> present form OSP does not meet your objective however the scenario that 
> Jonathan described below is a possible solution for Proxy NAT Traversal, 
> It would seem that this idea could be extended to an OSP model, 
> substitutions required:
> 
>  
> 
> “Thus, the problem reduces to dealing with the case where the proxy 
> from a TURN server that it finds.”
> 
>  
> 
> Question: Could required OSP server functions be incorporated in to 
> client software? 
> 
>  
> 
> If it was possible to extend OSP server functions to the client (which 
> would in effect become a “mini node”) each mini node could authenticate 
> between other mini nodes or nodes utilizing a public network (super 
> node) to “join” the network/super community.
> 
> 
> I feel that there is a potential to utilize OSP to overcome many issues, 
> if this idea has been thoroughly explored already and I am off track, 
> please let me know.
> 
>  
> 
> Jason
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Cullen Jennings
> *Sent:* Friday, January 28, 2005 5:28 PM
> *To:* Jason Arnold
> *Cc:* sipping
> *Subject:* Re: [Sipping] SIP P2P draft
> 
>  
> 
> 
> helped on one of the implementations of OSP). I think the thing about 
> OSP, is that the clearing house becomes the central server. David and I 
> were trying to make a system that allowed the rendezvous function of SIP 
> without a central server.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2005 18:17:54 -0800

I would bet we want a generally mechanism. I like how STUN can be used by
voice applications but also online gaming and many other things.

But I don't know about how likely a generally toolkit is. It would be very
nice if possible but I don't think this stuff is understood well enough yet
to know if you want very different approaches for different types of
problems and query problems. For example, by carefully selecting what the
user can not change as influencing the location in search space, you can
stop the user from being able to insert themselves in an arbitrary locations
which greatly improves the security of the scheme. It may be that it can all
be generalized into s small number of parameterized solutions, may not.

Say just SIP is bit braod too. The characteristics of a system to solve
rendezvous is probably much different than saving address books and buddy
lists which is probably much different from sharing PowerPoint presentation
in a conference. 
 
Most of today work is somewhat centered around sharing files and making it
difficult to shut down such a network while offering some level of
obfuscation of who the users are. These properties may or may not be useful
requirements.