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

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 16 Mar 2006 21:11:09 -0500

All,
 
The main assumption of HTTP, WevDev, and Web application standardirization
have been to cross the firewall/nat. So, they have done this very easily
without worrying about the fw/nat crossing problems. One advantage, I think,
they have is this: Both signaling and media are in the same plane.
 
In SIP, we could do the same if we would make our number one requirement
that both signaling and media in SIP need to cross the fw/nat, I think.
Since we forgot this most essential requirement during the protocol
development of SIP, we are paying the heavy price now.
 
So, let me turn around the discussion a little differently as follows:
 
What would we do in developing the SIP protocol in the beginning if the
number one requirement would have the crossing of the fw/nat by both
signaling and media?
 
Best regards,
Radhika
 
  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of Michael Slavitch
Sent: Thu 3/16/2006 8:20 PM
To: Greg Daley; Michael Slavitch
Cc: P2P-SIP
Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network

I'm not sure how limited WebDAV is.  An entire industry is built around 
it. 

It gives me encrypted r/w access to a whole file system with local 
security credentials, replacing the need for a VPN or configuring NAT 
firewalls as long as I have accessed to a common server. No more worry 
about NFS, SMB, whatever. All I need is WEBDAV and credentials. This is 
a good thing.  A Mac that doesn't run SMB can get data from an XP box if 
it can log in. No more futzing or fussing or configuring. It is 
automatic. 

It allows a company in Cupertino to actually make money selling music by 
making it easier to buy than steal. 

My local university uses Webdav to offer video archives to its students 
so they can catch up on lectures. 

Whiteboard collaboration, remote terminals, database read/write, all can 
and is being done with WEBDAV, which is RFC status.  WEBDAV is hardly 
trivial because it allows you to do pretty well anything over port 443, 
except for real-time streaming media.  

That it cannot do, for real time media doesn't work with get/put except 
at teletype rates. 

P2PSIP adds media, once done an entire Internet experience can be 
encapsulated using two IETF standard protocols.  

All over a single port that is secured and well understood with a 
well-described and well-respected protocol, something so well respected 
it is used for financial transactions by big conservative banks.   

"I don't know why you're so against it." 

Because in practise it no longer exists. It existed in an ancient static 
internet that didn't have session establishment protocols and protocol 
overloading. Fixed ports were needed pre-SIP and pre-HTTP because there 
was no better alternative.  Applications decide on content, not the 
protocol. 

If the argument is that it cannot be done then the WEBDAV RFC must be 
deprecated. There is no alternative. 

If WebDav is allowed to remain then P2PSIP should be allowed to follow 
its lead. You just can't say yes to one and no to another, especially 
when the truth in the field is that well-known numbering no longer 
exists in practise except for DNS, SMTP, and HTTP/HTTPS.  

M 

Michael Slavitch           Lead, Strategic Initiatives 
slavitch at objectworld.com   Objectworld Communications Corp. 
+1.613.599.9698 .225       Ottawa, Ontario, Canada

---

From: dbarrett at quinthar.com (David Barrett)
Date: Thu, 16 Mar 2006 18:34:37 -0800

> -----Original Message-----
> From: Roy, Radhika R.

Interesting.  Well, this is certainly doable -- in fact, that's what I do
with iGlance: each client only listens on a single port.  Thus all SIP
requests and responses, all RTP/RTCP (across 4 different profiles), from all
peers, all comes in on a single port.  There's some trickiness in
classifying and dispatching incoming packets (need to look at the binary
signature to figure it out), but it works great.

The nice thing about this approach is you do NAT traversal exactly once per
peer, and then re-use that connection for everything.  Given how cumbersome,
non-deterministic, and costly it is to establish and maintain each
connection, it's a huge complexity, time, CPU, and bandwidth savings to
multiplex everything over a single connection.

And it can all be done without any on-the-wire protocol changes: the actual
SIP, RTP, and RTCP packets sent can be fully compliant with their
specifications.  They all just happen to arrive on the same port.

I *love* the idea of standardizing this behavior.  It works great for me and
my users.

-david

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 17 Mar 2006 09:49:52 -0800

> signature to figure it out), but it works great.

Multiplexing packet streams of different types on one UDP port seems no
different from (and no more helpful than) on separate udp ports when a UA is
behind symmetric nat, regarding nat penetration.

When a node is behind symmetric nat, if its signaling msg can be forwarded
via one supernode while its media msg can be via another, the two msg
streams actually create two external port mappings.

Especially for p2p-sip nodes to be backward compatible with client/server
sip world, where proxy/ua/getway are normally separately located and anyway
there are different external port mappings for all types of packet streams,
standardizing one single port for all msg streams may hinder modular design
of p2p-sip applications.

peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'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: Thursday, March 16, 2006 6:34 PM
Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network

---

From: dbarrett at quinthar.com (David Barrett)
Date: Fri, 17 Mar 2006 11:32:23 -0800

> From: Peter Pan [mailto:huang-ming.pan at comcast.net]

Hm, I'm not sure I follow you:

- Assuming it costs X (time, CPU, bandwidth, risk of failure) to establish a
connection between two peers, and 

- Assuming I need to establish 5 different connections between each pair of
peers (SIP, RTP-audio, RTP-video, RTP-filetransfer, RTP-screenshare), then

- It's 5X (longer, more expensive, more bandwidth-intensive, greater risk of
partial failure) to use separate UDP ports than to re-use the same port.

And this is true regardless of what kind of NAT or firewall you're behind
(obviously, the more complex the environment, the more advantageous
multiplexing becomes).

Am I misunderstanding what you were saying?  I'm saying it's better to do a
risky and expensive operation once, rather than five times.

> streams actually create two external port mappings.

Perhaps this is the hangup: I'm suggesting that once the *direct* connection
is established between peers, *no* supernode does forwarding.

Again, relay is *not* the same as NAT penetration.  NAT penetration is the
art of establishing a direct P2P connection between *two* peers, without
relying upon a third middleman (except for the connection establishment, but
then he gets out of the picture).

> standardizing one single port for all msg streams may hinder modular

I'm not sure we're talking about the same thing, but I'm suggesting that
each UA be able to specify an arbitrary set of (ip:port) for its services.
A UA can optionally use different ports for all services like today, or it
can optionally use the same (ip:port) for all services.

Anyway, I'm just following Roy's suggestion that in a P2P environment when
the connection setup cost is so high, it's useful to reuse a single
(ip:port) for everything.  But I'm certainly not proposing that we mandate a
single (ip:port) for everyone.  I'm merely suggesting we might standardize
'best practices' along these lines to simplify and regularize SIP in a P2P
environment.

-david