The message may not have been as clear as I would have liked (an aside - what is the contraction for 'I would have'? I'd've? I'dve?) - written in pieces amidst many other things going on. And yes, I think that the appropriate interpretation is not bridge but proxy. There are really two separate concerns. The multicast issue will be with us as long as the commodity Internet doesn't supply this as a matter of course. So making sure, as much as possible, that the aspects of the AG that are truly multicast (and I'm showing my ignorance here, but I'm assuming that this is mainly the audio and video, right?) can be used over some sort of unicast/multicast bridge.
The other issue is the addition of services. With our security conscious world, and especially behind corporate firewalls, there is a definite problem with additional ports. And there is even a growing concern with the overloading of port 80, and the possiblility of problems with web services. In one document, I think the AGEP about firewalls, there is a statement that the venue client need not accept incoming packets on the 8000/2/4/6 ports, but there will be a loss of some of the collaborative richness. I guess my concern is that there not be a proliferation of ports that fit into this category. I haven't even started the process of discussing breaching our official corporate firewall to allow AG sessions between external and internal sites. I will have a significant problem convincing the powers that be that the 8000/2/4/6 regime is acceptable, let alone the fact that we will also have to bridge. (If this becomes an acceptable tool, then it is feasible that Boeing might create its own external bridge). That is why the idea of a proxy for the potentially many ports. Hope that clears up my previous note. -randy At 06:31 AM 5/5/2004, Ivan R. Judson wrote: >There are multiple facets needed to answer your question; let me try to >catch as many as I can. First let me try to break apart what you're asking >about to see if I can capture it correctly. You're mentioning multicast and >firewalls, and concerned about users who need to work around issues related >to them. Additionally the use of 'Bridge' in your subject line is not a like >we've ever used the word before, it's really a proxy, right? > >If these assumptions are correct, I can answer your questions pretty easily. > >--Ivan > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Randy Groves > > Sent: Wednesday, May 05, 2004 8:25 AM > > To: [email protected] > > Subject: [AG-TECH] 'Bridge' for venue services, etc.? > > > > I'm looking into the future here, and wondering how many of > > the new services that might be coming down the pike are going > > to fit into the > > 8000,2,4,6 port scheme of the Venue Server/Client as it is > > presently designed. I know that on the top end of all this, > > the fact that some of the participants are > > multicast-challenged will mean that they just lose out on > > some of the newest features. If the participants are > > multicast-challenged and firewall-challenged (behind a > > restrictive firewall, with a long process to go through > > before changes can be made, long security justifications for > > just opening up any port in the first place, etc.), I see > > them potentially falling further and further behind. > > > > What is the priority, when design decisions are made, as to > > what emphasis is placed on making sure that these situations > > are dealt with? > > > > Is there a possibility of a venue service proxy in the future? > > > > -randy > > > > > >
