So we are still faced with the question of how to deploy multicast to the end user. Sad. I have two circuits running into my home office, and both providers (one a major telco) are so cranially-rectally inverted that they have no clue what multicast is much less how to deploy it. What does it take, someone to go to berkeley and hack a server onto the network to act as a tunnel broker? Scott On Wed, 3 Mar 2004, Dean Anderson wrote: > On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote: > > > > I'm all for eating our own dog food, but IMO workable remote > > > access is more > > > important. > > > > The point about eating the dog food is so that you improve it > > to the point where it is acceptable. > > > > 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. It will be useful perhaps > to the large organization that has a potential for multicast. But it > certainly isn't useful in any potentially "hostile" environment. To abuse > some more buzzwords, multicast is not a "global" technology. Its more an > "enterprise" technology. Or, as MBone is today, arranged as tunnels to > participating and interested organizations. > > > 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. 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. > > > This thing is not rocket science. There are lots of folk > > with the little cameras and the ISPs do not want to have > > their bandwidth wasted needlessly. But trying to do multicast > > in the network layer has failed. The Internet considers > > complexity in the network to be stupidity and does not route > > it. > > Perhaps. But it didn't fail because it was too complex. "Failed" probably > isn't the right word. "Adopted" or "Allowed" are probably more > appropriate. It isn't allowed by ISPs because it isn't suitable to the > environment. It may be allowed by cooperating organizations, which have > to create tunnels between them. I don't a big problem with that. > > --Dean > > > > sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/