Answer: Certainly, but you'll have to use someone else's. Here is a list of Public CU-SeeMe Reflectors.

Answer: Just as we have étiquette in the real world, and "netiquette" on the Internet, there's an desired code of conduct on reflectors.

• Before you use a public reflector send email to the contact person (specified in our public reflector list). Tell them how you intend to use their reflector and approximately how long it'll take. Remember, they may have local rules about (and corporate need of) reflector usage.

• Stay only a short time, unless invited to "hang out" for longer.

• Send video. Leaving a still image or a "crawling" message is very poor manners and a waste of network bandwidth.

• Send live video. Broadcasting a videotape (or other canned video) transmits information better suited to other media. An exception may be to show topical events that could not be captured live. The Burning Man Extravaganza was recorded to tape and rushed to a networked computer. There had been plans to use a satellite, but they fell through.

• Use the "low" resolution mode. It's sufficient for us to admire your haircut. High resolution mode pushes much more data across the wire, and should be used for very special occasions or your own internal facility network.

• Use the default transmissions settings. They work for most people in most situations. Specifically, keep your Maximum Kilobits/Second below 100 kbps and the Change Threshold to below 20.

• Be mindful of your audience. You're in a freely-viewable forum: "inappropriate" content generates backlash. Grade-school children connect to public reflectors, they shouldn't be exposed to adult content. Children need to remember that adults use the reflectors: someone's parents may be watching what they do!

• Be respectful of people trying to run an organized conference of a reflector you've connected to. Please don't hang around; allow them to get their business done. The "CU-SeeMe Events List" contains conferences and happenings that you're invited to.

Answer: Generally CU-SeeMe conferences are open to viewing by anyone who connects to the active reflector. There are ways of making restricted sessions (by using a session ID) and ways of restricting who may transmit.

Answer: Tim Dorcey said:

CU-SeeMe automatically adjusts its video transmission rate (by varying the frame rate) to adapt to the currently available bandwidth, as determined by packet loss reports returned by video recipients. Since the current version is only capable of generating a single resolution video stream, it averages the loss reports and adjusts the rate on that basis. Hence, to the extent that they effect the average packet loss, video recipients with low capacity network connections will slow down the video for everybody. Unfortunately, there is a bug in the current release (0.60b1) that generates faulty loss reports and makes this problem appear much more severe than it should be. The version soon to be released fixes this bug and should produce more reasonable behavior, particularly if recipients on low capacity links close all but 1 or at most 2 video windows. Eventually, CU-SeeMe will be capable of generating a hierarchially encoded video stream so that the reflector can select a different transmission rate for each recipient.

Answer: Tim Dorcey said:

When you close a connection, the applications sends a repetative series of "Close Connection" messages. Hopefully, at least one of these gets through, but on a bad connection, they might all be lost. Hence, the reflector will also kill a connection if it hasn't received anything from a participant for some time. Now, it is the nature of the CU-SeeMe protocol that the control packets used to maintain a connection are indistinguishable from those used to initiate it. So, when an application closes a connection, it ignores anything from that same address for some period of time, to prevent any left-over (maintenance) packets from the original connection from being interpreted as initiation of a new connection. The different time-out parameters are chosen so that, in theory, the reflector time-out should occur before the application begins accepting packets from that address again. With a bad connection or a bogged down reflector, this logic apparently fails, and we need to re-examine it. As a work-around you can:

1. Connect immediately to some other reflector, or
2. Quit the application

A similar problem that occurs with bad connections is that video windows that you close keep popping back open. What happens here is you close a window, but then, as a result of packet loss, you hear nothing from that participant for some time and "time them out." When something does happen to get through from them, it is treated as a new participant and their window is automatically opened (as it is for all "new" participants). In the recently released version 0.70b1, there is a preferences item where you can set the maximum number of windows that you want displayed at any time. With a low capacity connection, this should be set to a very low number. You can then select the partipant(s) you want to watch from the Participants menu. Note that the packet-loss/time-out phenomenon will still occur, but the participants will be coming and going from the menu instead of your monitor.

Another source of reflector mis-behavior to look for is a full file system where the reflector is writing its log file. This generates a system error each time the reflector tries to update the log and slows it down enough to disrupt the connection protocol. If you don't specify a LOG-LIMIT in the reflector configuration file, the default is 10,000 lines. Make sure you have room for it on your system.

Answer: Calvin Chi said:

I just got my reflector set up and successfully tested with CU-SeeMe on both Mac and PC...

1. The reflector can be compiled WITHOUT -DMULTI should be emphasized somewhere in FAQ, not just one line in the Makefile.

   Multicast function is a great hurdle to most people even the sysadmins. But one can compile reflector in UNICAST mode and see the wonder of CU-SeeMe.

2. The explanation for CU-SeeMe's audio window control is VERY un-CLEAR. It took me a while to figure out what to do to send my voice out and receive audio.

3. While we are testing we encountered strong echo effect on Mac. Turned out it is becuase that the new microphone is too sensitive and it will pick up the sound from Mac if you put it too close to the machine. Thus form a loop and cause echo effect. This is somewhat related to the fact that we don't know how audio control works.

   • when Push-to-talk is OFF, only voice volume higher than the threshold will be trasmitted. BUT...

   • when Push-to-talk is ON, threshold does not filter sound. All volume levels will be transmitted.

   • I still not very clear what kind of effect the Lurkers have.

Answer: Julian Humphries said:

To make a version for Solaris...loose the -lucb on the LIBC line, as Solaris really hates to do any Berkeley UNIX stuff (despite hype to the contrary). In addition, take out the define for BSD in the make file. I also had to add CC=gcc because I use the gnu compiler. Finally, the important part is to add a define for solaris in the makefile and then add this to reflect.h:

#ifdef SOLARIS
#define bzero(str,size) memset (str,0,size)
#define bcopy(s,d,c)  memcpy(d,s,c)
#endif /* SOLARIS */

These are the only real BSD'isms in the code, although I got lots of warnings about stuff without casts and a few others that probably should be checked out. Seems to work, although my testing has been minimal. BTW, my test was on the just released version 3.00B1. Your mileage may vary.