On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote:
If the IETF put a tenth the effort that has gone into multicast into
fixing the spam problem, or something the end users (not geeks) care
about...
Hmm. That would be real work... ;-) ;-)
Equally flawed and useless are the H.323 protocols that do not
tunnel through NAT or even work with a firewall in a remotely
acceptable fashion.
There is nothing wrong with h323. There are good reasons for the IP
address of the client to be embedded in some h323 control messages. In
most cases, this is a good thing, and an advantage for call control and
call routing systems. Indeed, this is what gives h323 its scalability and
ability to compete and work in tandem with the PSTN.
This design feature seems to be a work arround the rule that
reserved ports can only be accessed with system privileges.
There are much better work arrounds.
??? It has nothing to do with reserved ports. The "normal" ports are
1720 and 1721. The problem is that the client's IP and port are embedded
in the setup messages, so that they can be passed to several intervening
gatekeepers which may (or may not) handle the stream themselves, or
arrange for the two endpoints to communicate directly.
Do you mean the feature of having gatekeepers for distributed call
control/call routing?
But when passing
through a NAT, those addresses and port numbers have to be properly and
statefully translated---That's what a proxy does. The problem is that
your NAT doesn't (or most likely, /didn't/ until the last year or two or
three) support h323 proxy. You need h323 proxy support just like you need
proxy support for many non-trivial protocols. Either upgrade your NAT
software, or if you run linux/bsd/etc, install an open source h323 proxy
on your NAT gateway.
Schemes that require NAT boxes to implement ad hoc kludges for each
protocol are not a good plan. I would much rather have one protocol
that gives my machine to request a port be opened on the NAT box.
The problem with NAT is the need for ad hoc kludges. Deal with the
fact that NAT is here to stay and the problems can be eliminated
trivially.
These two statements are contradictory. 'Schemes that require NAT to
implement ad hoc kludges' / 'The problem with NAT is the need for ad hoc
kludges.'
Anything that requires state on the part of the NAT, and the NAT to look
inside the protocol to make changes for external/internal translations is
going to require a proxy. Clearly, there is a need for protocols to have
IP addresses and port numbers inside the protocol payload, and there is no
generic way to describe that to the NAT. Proxies are unavoidable in NATing
non-trivial protocols.
This could be done with a trivial mod to DHCP (hey buddy, this IP address
I just gave you is behind a NAT) and a very simple UDP request/response
protocol (give me an external port in the range 3000 to 3050) (OK
you have 3002, the IP address is 10.2.2.2).
This is clever and I think it could be useful for some things, and I
wouldn't argue against it being standardized, but it doesn't solve the
problem for h323 because the h323 client doesn't know if the eventual
remote endpoint will be an external or internal address. The gatekeepers
(and proxy's) need to figure that out, and similarly for the other client.
The client can't do it, except in the trivial case without gatekeepers.
The client can only say "I'm listening on this IP and port". Only in the
trivial case, going through a NAT, does it look like an unnecessary
complication.
But we don't want to give up our distributed call routing and call control
capabilities, so we aren't going to optimize for the trivial case which is
basically only used in proof of concept "2 cups and string"
demonstrations, anyway. Though, basically, that's exactly what the SIP
group did, and has been adding 'necessary complication' ever since.
People always groan about the complexity of h323 but the basic complexity
is there for good reason, and there are rational points of optional
additional complexity (such as h.450x extensions). Certainly, there has
been optimization between version 1 and version 4, and there may even be
room for optimization still. But the basic requirements are, well, 'basic
requirements'. To throw some platitudes out: "Make things as simple as
possible, but no simpler". And really, most of the problem plaguing h323
had been the lack of good, free asn1 tools, but that is changing, too.
--Dean>