I think that makes sense.  Thinking about it a bit, if you want to  
try to establish a direct connection using ICE, the only requirement  
for ICE to work is to have a rendezvous node to relay the connection  
request.  So if a client could identify another client (say an  
existing client behind the same bad NAT) with a connection to a peer,  
it could route the ICE request (CONNECT in reload) through that  
client to its associated peer (and around the overlay if the two  
clients don't want to associate with the same peer). If it's only one  
unfriendly NAT (the peer isn't behind one), that should be enough to  
establish a direct connection.

 From reload's perspective, this is a good example of a benefit of  
the via list---it can store the route through a client as well as  
through the peers and the response will then follow the same path  
back.  Even if a direct connection isn't achieved with the associated  
peer, the new client could continue to relay methods indirectly  
through the connected client.  I should mention that supporting this  
type of forwarding is an intended capability of the protocol, but  
actually implementing it does make the client code a bit more  
complicated than it might be otherwise since it needs a complete  
forwarding (but not DHT) layer.  There are also some implications  
that need to be fully thought out (wouldn't really want to do a long  
chain of clients or anything overly complicated).

I don't see a reason why TURN wouldn't work either, but I actually  
prefer using the peer protocol a bit here because I think the routing  
is more natural.

Bruce


On Mar 13, 2008, at 10:52 PM, Victor Pascual Ávila wrote:

> Up to now we've considered the client protocol -independently of its
> functions- to be the protocol used between a client and its associated
> (one, few, many) peers. What I'd like to discuss is: May clients be
> able to connect each other using the p2p layer? e.g. if a client is
> behind a non-friendly NAT, it could use other clients (providing
> STUN/TURN services) to reach its associated peer.
>
> Does it make sense for you?
>
> Cheers,
> -- 
> Victor Pascual Ávila
> Research Engineer
> Tel.  +34 93 542 2906
> Fax. +34 93 542 2517
>
> Research Group on Network Technologies and Strategies (NeTS)
> Universitat Pompeu Fabra (UPF)
> Pg. de Circumval·lació, 8
> Office 358
> 08003 Barcelona (Spain)
> http://nets.upf.edu/
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to