This seems to have fixed the problem. I'm not using 224.2.0.0 - 224.2.0.0.2 and my external testers are confirming that this works for them.
On Feb 21, 2005, at 6:22 PM, Thomas D. Uram wrote: > Hi Don: > > I believe (based on other conversations with you) that you're using > multicast addresses similar to 224.0.0.x on your server. This is, > apparently, a problem. > > From the cisco Guidelines for Enterprise IP Multicast Address > Allocation > (http://www.cisco.com/en/US/tech/tk828/ > technologies_white_paper09186a00802d4643.shtml), it looks like you > should avoid 224.0.0.0-224.0.0.255, which "is used by network > protocols on a local subnet segment". > > This same document claims that the 'global' range is > 224.1.0.0-238.255.255.255, so addresses there should work for you. > There are more details in RFC3171, if you're interested. > > Let us (ag-tech) know if this fixes your problem. > > Tom > > > Donald Roeber wrote: >> We're running the latest AccessGrid Toolkit on MacOS X, as both a >> VenueServer and a UniCast Bridge for that VenueServer. The server is >> multicast enabled, and so are clients on the upenn.edu network. >> Clients on the upenn.edu network can connect to the VenueServer and >> use RAT and VIC just fine. Unfortunately, for people outside of the >> Penn network, audio and video doesn't work, but they can still use >> the text chat built into the VenueClient. We don't have any >> firewalls or anything like that in place. Because of a bug in the >> MacOS X version of the AGToolKit we're using manual multicast >> addressing for each venue. Each venue is assigned a unique IP >> address for audio and video, and a unique even numbered port number >> for each service as well. >> Any help would be greatly appreciated. >> -- Donald Roeber ISC Networking
