Subject: RE: dire outlook on internet and NAT

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Jan 2004 11:32:47 -0800

> Fred Baker wrote:
> Many ISPs are thinking in terms of VoIP as a next generation
> business, the one after "selling bandwidth". But there are
> issues with that as well...

You must be talking about ISPs that are not in bed with a phone company;
at this point in time I don't see how they can compete.

Last month, I dug out the home phone bill to see how many long minutes
we were actually using. It turned out to be 200, which I bought for $5 a
month on my regular phone line; $10 would have bought me 600 minutes and
$20 unlimited long distance.

I do have VOIP (H-323) over my home aDSL line. It works great, because I
control the QOS at the source. I still have to see any ISP giving me
unlimited long distance not only to other VOIP phones but to the entire
PSTN, guaranteeing toll quality even when I'm FTPing a 600MB file out,
for 20 bucks a month.

Michel.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 12 Jan 2004 14:57:45 -0500

Pardon me if I'm missing something obvious here, but couldn't one just 
use either XMPP or Simple for presence, associate your "server name" 
with a Jabber/Simple ID, and automatically have your "server" findable 
via these general presence protocols?  Why isn't that a reasonable 
approach to peer to peer in a NAT world?  I would contend that it's 
even better in a mobile world -- your laptop might change IP address a 
dozen times per day, but if it keeps reconnecting with your presence 
server you could base a stable "host" identity on the IM ID to enable 
peer to peer applications, couldn't you?

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 13 Jan 2004 16:50:37 -0500

> peer to peer applications, couldn't you?

XMPP or Simple solve the problem of dynamic IP addresses.  NAT's
however go beyond dynamic IP addresses, as they multiplex multiple
hosts behind a single IP address.  Many of these systems do not have
an easy way to allow users to accept an incoming TCP connection (and
unexpected UDP packets are often harder) to be happed to a particular
host behind a NAT box.  Doing so often requires administrative access
to the NAT, and if you're lucky there is a manual web interface you
can use to configure such access.  If you're not so lucky there is a
text config file you have to edit.  In either case, this makes peer to
peer much more difficult for the average user behind a NAT.  Some
might say that it is impossible.

One could imagine developing a protocols for discovering NAT boxes,
and making requests that they listen on certain ports and when they
receive an incoming TCP connection, that it be remapped to a
particular address behind the NAT box.  This is not too bad for one
NAT box, but if you start having multiple NAT boxes between the
communicating partners, it starts becoming bad in a hurry.  

Of course, this isn't necessary so as long as one of the parties is
not behind a NAT, but the moment both the sides are behind one or more
levels of NAT, trying to do a peer-to-peer TCP connection between the
two entities is non-trivial.

						- Ted