>> I think it is time to accept that the MBONE technology is >> fatally flawed and is not going to be deployable. >There is nothing wrong with Mbone, per se--though, as someone mentioned, >it might be nice to have better codecs. The problem is that multicast is >flawed, and not going to be globally deployable. Well that was my real point, it is a bogus concept. The fact it still does not work for all but a tiny fraction of the net shows that. 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... >> 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. If you think about it the port number is utterly irrelevant bandwidth wise. > 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. 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). There was a group looking at this type of idea, seems that it is a feature that is going to be deliberately withheld to make sure that the incentive to upgrade to IPv6 does not get lost accidentally. So the current state of play is that this is proposed for the IPv6 NAT boxes. Phill