Subject: [p2p-sip] New I-D: The effect of NATs on P2P SIPOverlay Architecture

From: marc1.bailly at francetelecom.com (BAILLY Marc RD-CORE-LAN)
Date: Wed, 1 Mar 2006 16:35:08 +0100

Hi Philip, 

Comments and questions inline.

> >
> > sec 4.3: just to understand: is static connection == pointers in  
> > DHT routing table? and dynamic == call setup? Otherwise, what does  
> > static mean?
> 
> We see two types of connections.
> The first type is used to maintain the overlay, do lookups, and for  
> signaling. These follow the partial mesh
> pattern described in the paper. We see these as static, meaning that  
> they are long-lived (assuming
> the peers at either end are long-lived) and do not change as calls  
> are set up and torn down.
> Since these are just a partial mesh, messages flowing over these may  
> need a number of hops to reach
> their destination.
> The second type is used for the media in the call. These go from the  
> calling peer to the called peer
> and are dynamically set up when the call is established and 
> torn down  
> immediately afterwards.
> 
> It would be possible to have a third type. These would be set 
> up when  
> the called party receives the initial
> Invite message and would be used for all the subsequent signaling  
> messages. However, the cost to
> set up a direct connection for the subsequent signaling messages  
> seems to outweigh the benefits,
> at least in my mind.
> 

If I understand well, you suppose that all the SIP signaling messages
should be routed via the overlay connection rather than using the
overlay as a location service and then establish a SIP connection?

In section 4.1 : Mesh -- Once connected into the peer network, nodes
exchange
      messages with selected other peers periodically to keep NAT
      pinholes open.  SIP messages are either sent directly to the
      destination peer, or are sent indirectly via intermediate peers.

I guess that the last sentence of this paragraph mention this two
architecture possibilities?
If it's right, maybe we could make it clearer.

> What section 4.3 discusses is the question of whether the first type  
> of connections should be dynamic.
> This is possible, but the overhead in setting up a connection seems  
> to outweigh any advantages in
> making the first type of connections dynamic.

I think dynamic connections might be used as an optimization (i.e. set
up additional dynamic connections with people you're often calling). Is
it your vision of dynamic connections? (I understand it as Kundan did).

Regards

Marc

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 1 Mar 2006 11:06:57 -0500

Hi Marc:

See replies inline.

- Philip

> overlay as a location service and then establish a SIP connection?

There is another option which we forgot to mention in the paper:
use the overlay as a location service, and when peer A wants to call  
peer B,
peer A sends a ConnectionRequest message (via the overlay) to peer B.
This tells peer B to start trying to punch a hole through the NAT  
back to
peer A. Once the direct connection between peer A and B is established,
it is used for all SIP signaling.

When considering all these options, the important point to note is  
that peer B
needs to know that peer A wants to establish a connection, so B can  
open a
pinhole in its local NAT. The message conveying this information to  
peer B
must go through the overlay, because that is the only way to reach  
peer B.
Whether this message is a ConnectionRequest (as described above) or is
a SIP Invite message is something we can decide.

> If it's right, maybe we could make it clearer.

You are correct.
We can try to make this clearer in the next revision.

> it your vision of dynamic connections? (I understand it as Kundan  

If peer A is frequently calling peer B, then peer A could establish a  
direct connection
to peer B. Most obviously this would be used for SIP signaling, but  
it could
perhaps be used for lookups as well.

Off the top of my head, I would guess is that A would have to be VERY  
frequently calling B (e.g., once
every few seconds or so) to make this really worth while, but there  
may be applications
where this will happen and peer A can figure this out in advance.

Part of the decision on whether this is worth it or not hinges on how  
many total
connections we think that a single peer can support. This is a  
question that Eric
and I have been trying to look for data on. Some people have  
suggested that
a peer could not support more than about 10 connections, while other  
think the
number might be more like 100 or 200. I think this will be an  
important number
for the group to investigate and decide on.

If the number is only 10 or so, then setting up a dedicated signaling  
connection like
this would be much harder to justify. However, if the number is 200  
or so, then this is more
reasonable.