Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 18 Jan 2006 14:40:09 -0500

David:

I fully agree with your first scenario:
> 1) On the internet where some global bootstrapping service is  
> available, and
> some or all non-bootstrapping nodes are behind NATs.

Regarding your second scenario:
> 2) Off the internet where UDP broadcasts work, no nodes are behind  
> NATs, and
> no bootstrapping service is available.
I would suggest that this be replaced by the statement that a  
bootstrapping service
(Rendezvous Server) will not the only way for a new node to locate a  
peer on the network.
Other methods, like multicast, buddy lists, and even manual  
configuration should also
be tried.

A few other minor comments below.

On 18-Jan-06, at 13:37 , David Barrett wrote:

>> -----Original Message-----
>> From: Philip Matthews
>> Sent: Tuesday, January 17, 2006 9:33 AM
>> Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG
>>
>> However, in smaller networks and/or in enterprise settings, I believe
>> that
>> assumption is not reasonable. On the contrary, I believe it will be
>> normal
>> for EVERY peer to be located behind a NAT.
>
> In an enterprise setting it's likely all nodes will be behind the  
> *same*
> NAT, but unlikely they'll be behind different NATs.

I disagree. What about a small company with offices in different
cities and no corporate VPN? Or a small company with teleworkers?

>
> Indeed, I think it unlikely there will *ever* be a deployment where  
> each and
> every node is behind its own unique NAT.

Again, I disagree. What about a group of friends with phones at their  
homes
who want their own private P2P network?
Or a small company where everyone works from a home office?

But these are minor points and I think we agree that a network where  
all the phones
are all located behind NATs (with some of the phones are behind one  
NAT and
other phone are behind other NATs) is quite possible.

- Philip

---

From: dbarrett at quinthar.com (David Barrett)
Date: Thu, 19 Jan 2006 23:45:00 -0800

> From: Philip Matthews [mailto:philip_matthews at magma.ca]

Ok, good point.  I was thinking of global internet-based networks, or tiny
non-internet networks.  I hadn't considered very tiny internet-based
networks like this.

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 20 Jan 2006 12:27:44 -0600

> non-internet networks.  I hadn't considered very tiny internet-based

Of course, there may be nothing we can actually DO for people who are  
all behind separate non-cooperative NATs that doesn't require having  
at least one node somewhere actually publicly visible somehow.

This is kind of like the question "If tress fall in several different  
woods scattered around the planet and nobody is there to hear them,  
does this make the sounds of the percussion section of an orchestra?"

--
Dean

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 20 Jan 2006 14:51:54 -0500

On 20-Jan-06, at 13:27 , Dean Willis wrote:

> Of course, there may be nothing we can actually DO for people who  
> are all behind separate non-cooperative NATs that doesn't require  
> having at least one node somewhere actually publicly visible somehow.
>
> This is kind of like the question "If tress fall in several  
> different woods scattered around the planet and nobody is there to  
> hear them, does this make the sounds of the percussion section of  
> an orchestra?"
>
> --
> Dean

If:
1) The peers are behind NATs with the "Endpoint Independent mapping"  
behavior
     (to use the terminology of the BEHAVE UDP draft);    AND
2) There is a Rendezvous server with a public IP address (either  
static or with a DNS entry)
      which can remember the mapped address and port of ONE peer in  
the P2P network
      that the new node X wishes to join
then it is possible to solve the problem.

Briefly, things work as follows.
Here we assume there is just one Rendezvous Server that supports all  
the P2P-SIP networks,
but this could be easily generalized to allow different servers for  
different networks.
1) A P2P-SIP network elects one peer P to maintain a connection to  
the Rendezvous server.
      The server remembers (a) the name of the network (b) a password  
(if access to the network is restricted)
      and (c) both the private and the mapped address and port of P.
      Peer P refreshes its info with the server frequently to keep  
the pinhole in its NAT open.
2) A node X which wishes to join the network contacts the server.  
Node X provides (a) the name of the network
      it wishes to join, and (b) the password (if required).
3) The server responds with both the private and mapped address and  
port of P.
4) At the same time, the server sends a message to P telling it the  
private and mapped address and port of X.
5) Node X and peer P now try to establish a connection (either TCP or  
UDP) using a method vaguely
      similar to that used in ICE (i.e., try all possible address  
combinations).
      Provided that both are behind NATs with the "Endpoint  
Independent mapping" behavior
      and assuming the NAT topology isn't too crazy (and/or the NATs  
in question support hairpinning)
      then things should work.

At this point, node X can talk to peer P, and can use P to establish  
connections with other peers.

There are situations where a Rendezvous server is not required, and  
techniques like multicast,
buddy lists, or manual configuration work. However, a Rendezvous  
server is the most general solution.

What I see us (the P2P-SIP group) doing is specifying the protocol  
used between the Rendezvous Server,
peer P, and node X.  Then some P2P-SIP networks may decide to use one  
server, and other networks
may decide to use another server. Node X will then have to know (a)  
which server to contact, (b) the name
of the P2P-SIP network it wishes to join, and (c) the password (if  
any) to join.

- Philip

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Fri, 20 Jan 2006 13:24:59 -0800 (PST)

Philip is right. If all NATs are BEHAVE compliant, P2P conenctivity could be
established directly even with the end nodes behind NAT devices. However, if a
NAT is not behave compliant, the end nodes behind that NAT could still get P2P
connectivity through a relay service from the super node. Clearly, intervention
of a super node in the data path is not desirable from perfromance
perspecective.

cheers,
suresh

--- Philip Matthews <philip_matthews at magma.ca> wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 20 Jan 2006 17:54:26 -0500

In fact, Suresh and a couple of others wrote a nice paper that  
describes this technique in detail
with an analysis of when it does and does not work.
"Peer-to-Peer Communication Across Network Address Translators"
http://www.brynosaurus.com/pub/net/p2pnat/

- Philip

---

From: dbarrett at quinthar.com (David Barrett)
Date: Fri, 20 Jan 2006 15:50:55 -0800

> of the P2P-SIP network it wishes to join, and (c) the password (if

I think I agree with this, but I'm unclear what you are specifically
proposing.  Are you suggesting the P2P-SIP group:

a) Adjust SIP to implicitly solve the NAT penetration issues, thereby making
every SIP proxy naturally serve as a "rendezvous server", ultimately doing
away with STUN, TURN, and ICE entirely?
	- (Incidentally, I think this is the right course.)

b) Create a new protocol that replaces STUN, TURN, and ICE, then implement
this new protocol in a new "rendezvous server" that is separate from the SIP
proxy, and then find a way to bridge SIP and this new server?

c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new
protocol that somehow simplifies the NAT penetration issue?

Which of these is the closest?

-david

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Fri, 20 Jan 2006 16:55:28 -0800 (PST)

I am in favor of option b). Create a new protocol that ultimately replaces
STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. The
"rendezvous server" or "super node"  that runs the protocol need not be a SIP
proxy. 

cheers,
suresh

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Fri, 20 Jan 2006 20:25:26 -0500

This seems conceptually similar to the ICE approach, except that ICE  
uses out-of-band mechanisms to test the possible address bindings,  
rather than in-band ones. Or is there some other fundamental difference?

---

From: dbarrett at quinthar.com (David Barrett)
Date: Fri, 20 Jan 2006 18:01:29 -0800

I understand.  Thanks.

I totally, 100% support a unified STUN/TURN/ICE replacement.  And I
completely endorse a single specification for the total functionality of a
rendezvous service.

However, I'd go one step further and suggest that we can accomplish this
with minor alterations to SIP itself, and with minor additions to the SIP
proxy.  Thus I think we can do this without creating a new protocol or
server from scratch.

My reasoning (possibly not fully thought through) is that virtually all SIP
deployments will occur over the internet, and thus will require a
NAT-penetrating rendezvous service.  The SIP proxy seems a natural place to
do this (as it is virtually always publicly accessible), and it'd be great
if P2P-SIP-compliant clients "just worked" across NATs without major changes
to the overall syntax and state machines that have been refined with SIP.

Specifically, I think the existing SIP protocol and proxies already do 90%
of what is necessary to pierce NATs.  The particular message flow I'd
recommend is:

- All user agents use a STUN-like protocol on the SIP proxy to find both
public and private (ip:port) tuples.

- All user agents REGISTER both (ip:port) tuples with the SIP proxy.

- All clients maintain a punched UDP hole (or persistent TCP connection) to
one or more SIP proxies, thereby ensuring proxies can contact clients at
will.

- User agent A sends INVITE to the SIP proxy, as always.
 
- The proxy gives A a provisional response to the INVITE with a "300
Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples
associated with user agent B.

- The proxy forwards A's INVITE to B, appending A's (ip:port) tuples.

- A, on receiving the "300 Multiple Choices" begins punching holes to both
(ip:port) tuples of user agent B, thereby ensuring B can contact A.

- B, on receiving the forwarded "INVITE" request from the proxy, begins
responding "200 OK" to A along both of A's (ip:port) tuples, implicitly
punching holes to A and ensuring it can contact B.

- Eventually, A and B have each punched holes to each others' public and
private (ip:port) tuples.  Whichever (A(ip:port),B(ip:port)) route along
with A receives "200 OK" first is used for P2P communication.

In summary, I suggest:
- SIP be expanded with a STUN command that proxies MUST implement
- User agents REGISTER multiple (ip:port) tuples with the proxy
- Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch
- Proxies append all of A's (ip:port) tuples when forwarding to B
- B replies "200 OK" direct to all of A's (ip:port) tuples

Obviously there are more minor issues (TURN integration, symmetric NAT
piercing, etc), but this is the core algorithm.  And this *works today* in
iGlance (www.iglance.com), so it's not an abstract proposal.  The relevant
logic is implemented here (though obviously it won't make much sense without
the context of the rest of the architecture):

	http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp

The benefit is:
- You don't need a separate syntax/grammar for STUN/TURN (in SIP)
- You don't need a separate STUN/TURN server (in the proxy)
- You don't need ICE at all (implicit in message flow)
- Clients needn't implement STUN servers (as ICE requires)
- Client state machines are vastly reduced in complexity over ICE

Furthermore, this is *entirely* compatible (indeed, orthogonal) to a
decentralized SIP proxy.  By combining NAT rendezvous service with the SIP
proxy service, the same supernode structure can be used for proxying as for
NAT penetration (potentially even TURN relaying).

Basically, NAT penetration isn't really that hard, and SIP *almost* already
does it.  It'd be a shame to create a whole new layer of protocol complexity
to solve such a minor, universal problem as this when very slight
adjustments to SIP itself can make the problem go away.

-david

> From: Pyda Srisuresh [mailto:srisuresh at yahoo.com]
> Sent: Friday, January 20, 2006 4:55 PM
> To: David Barrett; 'Philip Matthews'; 'Dean Willis'
> Cc: 'P2P-SIP'

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Sat, 21 Jan 2006 07:18:40 -0800 (PST)

You are right, conceptually they have similarity, but there are differences.
Both casess seek the aid of super nodes (ex:  STUN/TURN nodes in the case of
ICE). Below are a couple of differences between ICE and P2PNAT proposals.

1. ICE focus is on UDP based media connenctions. ICE also does not address how
the signalling (ex: SIP) agents themselves connect from behind NAT devices. The
P2PNAT proposal is not specific to SIP or media flow and is applicable to all
types of P2P sessions, including TCP or UDP based on-line games, file
transfers, signalling and multimedia-sessions.

2. ICE tries all possible connection scenarios between candidate endpoints to
see which of them would click. For example, if node-L and node-R need to setup
a connection and each had a list of candidate endpoints to peer with, each
candidate goes through exhaustive connectivity trials, until one of them
succeeds. The connection that succeeds first (say, TURN-to-TURN connection)
need not be the most optimal connection. With the P2PNAT proposal, the
connectivity trials are less chaotic, and the most optimal connectivity is
attempted first. For example, if each of Node-L ad node-R is behind a Cone NAT,
a direct end-to-end conenction is setup without a relay node in between, using
the simultaneous hole punch techniqiue.

cheers,
suresh

---

From: huang-ming.pan at comcast.net (PP)
Date: Sat, 21 Jan 2006 11:59:08 -0800

Quoted: "
    (1). Clients needn't implement STUN servers (as ICE requires)
    (2). By combining NAT rendezvous service with the SIP proxy service, the
same supernode structure can be used for proxying as for
NAT penetration (potentially even TURN relaying). "

It sounds that the terms "clients" and "supernode" referred to two different
types (implementations/functionalities) of p2p-sip nodes.

Questions of mine are:

Q1: how to know in advance during software build/release or hardware
manufacture phase that a node will be running as "a client only" or as a
supernode?

Q2: when a node (soft or hard phone) is "made" to be working specifically as
a supernode, won't the scenario become another flavor of client/server
deployment?

I thought what p2p-sip working group would plan to propose is a "ultimate
utopia" where all nodes (soft/hard) are "homegenerous" in implementation,
functionality and deployment aspects, and what we (:either poor implementors
or lucky architect:) were going to benefit is to "DO ONE THING ONCE FOR ALL
AND EVER". It seems I might have thought wrong and the thing seem moving
back toward some kind of client/server ugliness.

peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Pyda Srisuresh'" <srisuresh at yahoo.com>; "'Philip Matthews'"
<philip_matthews at magma.ca>; "'Dean Willis'" <dean.willis at softarmor.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Friday, January 20, 2006 6:01 PM
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

> > "rendezvous server" or "super node"  that runs the protocol need not be
a
> > SIP
> > > this new protocol in a new "rendezvous server" that is separate from
the
> > SIP

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sat, 21 Jan 2006 18:59:39 -0800

> From: PP [mailto:huang-ming.pan at comcast.net]
> 
> It sounds that the terms "clients" and "supernode" referred to two
> different types (implementations/functionalities) of p2p-sip nodes.

"client" and "supernode" functionality is certainly different.  It's
possible that a single node is able to do one, the other, or both.  The
ideal P2P deployment would have every node capable of performing both roles,
and some algorithm exists for promoting normal nodes into supernodes as
befits the network.

Today's SIP has "supernode" functionality firmly in the realm of the proxy,
and "client" functionality firmly in the user agent.  However, there's no
reason to prevent a user agent from behaving like a proxy.  But then again,
there's no reason to mandate that it do so, either.  The protocol should
support both, and then leave it up to the programmer to decide how far a
given node will go.

> manufacture phase that a node will be running as "a client only" or as a

Ideally, any node that can act as both should act as both.  However, not all
nodes *can* implement both functions.  For example, some very trim device
might not have the computational resources to act as a supernode, but should
still be capable of acting as a normal client.

> a supernode, won't the scenario become another flavor of client/server

Yes, just as an implementer should have the option of making a pure client,
he should have the option of making a pure server.  But again, the protocol
should allow a single node to act in either or both supernode and client
capacities. 

Does this answer your questions?

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sat, 21 Jan 2006 22:30:18 -0600

On Jan 20, 2006, at 1:51 PM, Philip Matthews wrote:

> 1) The peers are behind NATs with the "Endpoint Independent  
> mapping" behavior

I fail to see how the requirement of #2 "A rendezvous server with a  
public IP address" is not "at least one node somewhere actually  
publicly visible".

--
Dean

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 24 Jan 2006 23:35:56 -0800

I like this work and think it is the right path for us but I consider it to
architecturally be the same as  STUN (for UDP) and STUNT (for TCP).

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 24 Jan 2006 23:36:12 -0800

> protocol that somehow simplifies the NAT penetration issue?

I have not heard a  concrete proposal for something that solves and is not
isomorphic to ICE. (Actually there is one proposal that I do hear and that
is the port prediction but other WG rejected it as not working). If there is
a good concrete alternative that is better, let's take it to the appropriate
WG and get them to use it.