Subject: [p2p-sip] Concepts draft: Open Issue #2: Adding NATs

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 7 Dec 2006 12:48:21 -0500

Open Issue #2:  Right now, the Concepts document says
there can be NATs between peers. However, the examples
in section 3.4 ignore the fact that it is generally not possible
for an arbitrary node to send a message (e.g. a SIP INVITE)
to destination node that is behind a NAT.

Proposed Resolution:  The P2PSIP Overlay provides a message
relaying service. In other words, the sending peer/client can send
a SIP message through the Overlay in some manner that causes
it to be delivered to the destination peer or client.

Consider the example in section 3.4.2 where client C sends an
INVITE to the user U residing on peer F. Since client C connects
to the Overlay via peer Q, client C might pass this INVITE to peer Q
which then passes somehow through the overlay so that it gets
delivered to peer F.  (If client C somehow knows how to reach
another peer R, it might choose to send the message to that peer
for relaying instead).

There are a number of ways that such a relaying service might
be implemented. Some have suggested that the lookup might return
a route vector to the destination. Others have suggested that the
routing might be done as part of the search. However, in the
next revision, we are proposing to not give details, but just say
that such a mechanism exists.

Comments?

- Philip

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Fri, 8 Dec 2006 07:26:50 -0600

Hi, Philip,

What would you see as alternative proposed resolutions?

Obviously, one alternative is dropping support for NATs in arbitrary places 
in the overlay topology, and I agree that that's the wrong alternative.

Are there other alternatives?

Thanks,

Spencer

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 11:18:20 -0500

> Are there other alternatives?

One alternative, of course, is to say that all peer must reside in  
the same address realm
(for example, all peers must have public IP addresses). At this  
point, this would
be a charter change.

The other alternatives that I can think of are impractical or  
undesirable.
They include such things as: (a) requiring all peers behind NATs to  
maintain connections
to all other peers and clients, or (b) requiring a peer behind  a NAT  
(of any kind) to have
an associated TURN server, but a TURN server with endpoint- 
independent filtering
(something deliberately ruled out by the current  TURN spec).

Note: If you assume that there is a reasonable number of peers in the  
same address realm X
(e.g., the public Internet), then we could require that each peer  
behind a NAT maintain
a connection to a peer in realm X. Then a message from peer A to peer  
D is sent to peer C
in realm  X, to which peer D is connected to. The phrase "routing  
through the overlay" is
intended to be general enough to include this approach.

- Philip

PS. Personally, I don't think that all P2PSIP networks will have such  
an address realm X available,
which is  what I think is a problem for the DNS-based approach that  
has been discussed
so much in the past two weeks.