On Sun, Oct 24, 2004 at 08:07:27PM -0500, Ivan R. Judson wrote: > > > Hey Frank, > > In one respect I agree, the details are not completely implemented, in > another I disagree, since it's entirely conceivable that a client can call > the "enter" operation on the venue, but not the "negotiate_capabilities" > call which would give them stream information.
So you would let clients enter the venue, and view, say, shared apps, but the media streams? Neat! > We're currently considering how to support these calls in the next release > and the ideas we have might support exactly what you're pointing out as a > use case. We'll have to make sure. > > In any case, if the venue can provide this functionality, it's much easier > :-) The real problem, as I see it, is that there's no way to push out a "Let anyone recieve this multicast stream, but only these addresses transmit to it" setting out to the router infrastructure. Hm. I have no idea how feasible this might be, but an alternative might be to use asymetric encryption for the multimedia streams. Official participants would get both the encryption and decryption keys, while the peanut gallery would only get the decryption keys. The traffic would still go everywhere, but they wouldn't be able to wander in, leave rat transmitting with a radio blaring, and then go to lunch in the middle of an SCGlobal meeting. -- Frank Sweetser fs at wpi.edu WPI Network Engineer GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
