--- Henning Schulzrinne <[EMAIL PROTECTED]> wrote:
> [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).
Good point. Out-of-band control will require an ALG. No argument there.
But, that is not to say you shouldnt think about 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).
I dont think, that is what is being said at all.
If you could design applications that can work with NAT enroute, without
needing an ALG; that would be great. But, if the applications do require
an ALG enroute (as in the case of voice-over-IP which uses out-of-band
call-control segnalling), then the application designers should also
consider what it takes to build an ALG enroute. This is an issue not just
with NATs, but also with firewalls and perhaps security gateways.
> 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.
>
Are you refering to the TCP connection so you can retain the name-to-address
mapping? I suspect, you need to do more than just that to permite RTP streams
across NAT boundaries. In which case, you are better off monitoring the
name-to-address mapping as part of the ALG, instead of relying on a TCP
call-control session.
> 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).
>
Please see my comments above. Protocol design will be deemed successful
only as they are deployed. It does not harm to think of their impact on
NATs, firewalls and security gateways - all of which are already deployed
in a large number of locations.
> --
> Henning Schulzrinne http://www.cs.columbia.edu/~hgs
>
>
regards,
suresh
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
