Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 17 Mar 2006 13:44:18 -0800

For p2p-sip to be accepted by enterprises where there are often hundreds of
nodes behind (normally symmetric) nats, do we need to standardize the
"radius" of probabilistic port-scan so that their network administrators
won't treat port scanning by p2p-sip nodes as a security threat?

Does it seem also better to recognize the multiplexing media streams with
SIP signaling stream as a valid and encouraged option in next RFC for
(non-p2p) SIP/3.0 :-)

peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Peter Pan'" <huang-ming.pan at comcast.net>; "'Roy, Radhika R.'"
<RADHIKA.R.ROY at saic.com>; "'Michael Slavitch'" <slavitch at objectworld.com>;
"'Greg Daley'" <gregd at research.panasonic.com>; "'Michael Slavitch'"
<slavitch at gmail.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Friday, March 17, 2006 1:03 PM
Subject: RE: [p2p-sip] SIP, ICE, and an Overlay Network

> > -----Original Message-----
> > From: Peter Pan [mailto:huang-ming.pan at comcast.net]
> > Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network
> >
> > Maybe my limited knowledge of nat penetration leaves us on different
> > pages.
> >
> > Just few questions:
> >
> > 1. If peers behind all types of nats can establish direct connection
> > between
> > each other *easily or anyway", why TURN comes up? (even Skype seems
using
> > some kind of TURN relay)
>
> Even the best NAT penetration isn't 100% reliable, so the TURN service is
> the fall back plan.  But NAT penetration over 75% is straightforward, and
> high 90% is possible -- even >99% has been claimed.
>
>
> > 2. If using two internal ports doubles risk of failure of connection
> > establishment, does it mean that, for two hosts behind a nat, after one
> > host
> > gets connected (inward or outward), another will be double harder to get
> > connected??
>
> Ah, no I'm referring to the prospect of partial failure.  For example, in
> iGlance you can text-chat, voice-chat, videoconference, screen share, and
> send files.  Were each of these using a different connection, the risk
that
> at least one of these channels fails to penetrate the NAT goes up.  And
then
> you're faced with the problem where your video channel is direct P2P,
while
> your audio channel is relayed through a TURN server.  This leads to all
> sorts of odd behavior for the user.
>
> By having everything either completely work or completely fail, it gives a
> cleaner experience for the user.
>
>
> > 3. If the overhead to open a udp socket can be ignored (it can be
> > usually),
> > does it need double cpu/bandwidth to use the udp socket to communicate
> > with
> > two peers?
>
> The setup cost isn't so much in creating UDP sockets, it's in conducting
the
> connection process.  In the worst case of symmetric NATs, this can involve
> doing a probabilistic port-scan of the remote host.  Thus setting up one
> connection between two peers could conceivably involve hundreds of packets
> going back and forth over many seconds time.
>
>
> > 4. From the sentence, "I *love* the idea of standardizing this behavior.
> > It
> > works great for me and my users", I thought one-port approach will loved
> > to
> > be standardized. Sorry, I misunderstood your *love* :-)
> >
> > I do (+ did) *love* the idea of port convergence, though. Actually when
a
> > secure transport layer is necessarily beneath all packet streams for p2p
> > security, one-port approach is indeed as sweet as you love to suggest.
>
> Heh, I guess what I meant is I'd like my beloved approach to be recognized
> as a valid and encouraged option, but by no means the only option.
>
> -david
>