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>