Subject: RE: IP network address assignments/allocations information?

From: [email-masked]
Date: Tue, 30 Nov 1999 09:44:40 -0600

> In any event, I've always personally been of the opinion that
> if applications don't work in the face of NAT, then the
> applications themselves are functionally deficient and should be
> fixed.  :-)

I'm certainly not going to disagree with you about that,
but H.323 does not work through NAT without extremely
sophisticated stateful inspection/rewrite capabilities
in the NAT, and it will not work, period, if the signaling
streams are encrypted.  For better or worse (and let's
not get into that), there's a lot of H.323 out there
and there's going to be much, much more over the
coming years.  RSIP isn't going to work cleanly with
H.323, either (although there are some rather disgusting
things you can do in the application about that).

We can "should" until the cows come home (Hey!  They're
home!), but there's a lot of real software out there that
is broken by network address translation.

Melinda
-- 
Melinda Shore
Member of the Scientific Staff
Nokia IP Telephony
127 West State Street
Ithaca, NY  14850
+1 607 273 0724 (office)
+1 607 275 3610 (fax)
+1 607 227 4096 (mobile)
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Nov 1999 11:50:42 -0500

> things you can do in the application about that).

Agreed.

Any protocol that wants to have out-of-band control will have
difficulties with existing NATs (without ALGs). Thus, by saying "let's
design NAT-friendly protocols", we are effectively ruling out a whole
class of designs and only allow protocols with outgoing TCP connections
(and possibly UDP request-response protocols). In the case of telephony,
it would mean keeping a TCP connection open continuously to some outside
server that would then use that TCP connection to send incoming calls
behind the NAT.

Thus, this is not just a matter of existing software, but fundamentally
restricting protocol design to a very narrow class of design choices,
choices which are basically inappropriate for anything related to
efficient multimedia carriage (real-time multimedia over TCP isn't
exactly a great option).

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Nov 1999 11:50:42 -0500

Agreed.