[EMAIL PROTECTED] wrote:
>
> > 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).
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
