Re: RFC: sample reflect.conf for reflector software

Paul S. Troutman (ai456@yfn.ysu.edu)
Tue, 20 Dec 1994 06:59:29 -0500


Ben Anderson wrote:

>why not just send the text?

Just trying to save some bandwith for you CUSM users... But, I found the
uuencode was corrupt anyway.

Let's try it this way:

----<CUT HERE>-----------------------
; Cornell Reflector Version 2.50B1

; DESCRIPTION:
;
; Sample CUSM Reflector configuration file created by Paul Troutman
; (ai456@yfn.ysu.edu), 12/17/94 5:37am, for private administrative and public
; video conferencing. I created this file for my own personal ease and use, but
; it may be helpful for other users to in the process of setting up their
; reflector. You can use it anyway you need to.
;
; Excerpts from Reflector 2.40B4 README file by John Lynn (jal7@cornell.edu)
; and the CUSM Team from Cornell University, that I do not represent.
;
; SUGGESTION (for the CUSM team):
;
; Would you consider using this config file, or one like it, in the next
; Reflector software release? It saves time.

;DEBUG
; [useage: uncomment to enable]
;
; Specifying DEBUG causes the reflector to print out a
; large amount of debugging information. This information
; is probably not particularly meaningful to anyone but
; the reflector programmer and will slow down the
; operation of the reflector, so DEBUG in general should
; not be added to the configuration.

;SELF-REFLECT
; [useage: uncomment to enable]
;
; SELF-REFLECT causes the reflector to send your own
; CU-SeeMe stream back to you. This also is a sort of
; debugging aid, allowing you to make sure your reflector
; is up and running.

;REFMON your.ip.addr.here
; [useage: REMFON ip-addr ]
;
; REFMON is used to specify the IP address of the UNIX
; workstation that is allowed to access the reflector
; using the refmon application. If no REFMON is specified
; in the configuration, then a refmon application running
; on any workstation will be allowed access to your
; reflector. If the IP address is specified as 0.0.0.0,
; then no refmon anywhere will be granted access. The
; refmon application is documented later on As refmon
; can be used to kill the reflector, it's probably best
; to include this parameter in all configuration files.

;CONF-ID 0
; [useage: CONF-ID conference-id msg-string //]
;
; Specifying CONF-ID allows you to have a measure of
; privacy on a public reflector. In any Mac version of
; CU-SeeMe above 0.70 or any PC version above 0.34,
; the application will allow the user to optionally
; specify a conference id when opening a connection. The
; default conference id is 0 which is also the reflector's
; default conference id. When the reflector is
; configured, defaulted, or set to zero all user
; configuration ID's are accepted. If the reflector is
; configured with a conference ID other then 0, then any
; incoming CU-SeeMe conference id must match the
; conference id in the reflector. If the conference ids
; do not match, then that participant is not added to the
; conference. To have a private conference, without
; uninvited participants, you would pick a random
; conference id, add it to the configuration file,
; make this number known to all of your invited guests,
; and ask them to specify this conference id when
; connecting to the reflector. The conference id is in
; the range from 0 to 65536. The msg string is an ascii
; string terminated by a carriage return followed by two
; back slashes. This is the string that will appear on a
; participant's screen if he tries to connect with the
; wrong conference ID. Also see CONF-MGR below.

;CONF-MGR 0
; [useage: CONF-MSG ip-addr]
;
; The CONF-MGR ip address, is the ip address of a
; participant that is permitted to set the conference
; id when he connects. This allows a designated
; participant to dynamically establish a restricted
; conference without having to manually reconfigure the
; reflector. When the conference god connects to a
; reflector he can specify a non-zero conference ID
; number. All participants currently connected with this
; correct ID number will remain connected. All
; participants currently connected with the wrong
; conference ID or zero will be disconnected and the
; message string that was specified in the CONF-ID
; configuration paramater will appear on their screen.
; All future connection attempts will also have to
; contain the correct conference ID or else they will not
; be allowed to connect. The conference ID remains in
; effect until the conference god resets it to another
; number or perhaps 0 to make it an unrestricted
; conference.

;CAP
; [useage: CAP cap hold-down-time msg-string //]
;
; CAP is used to enforce transmission rate limits for
; those participants that connect to your reflector.
; If a participant sets his maximum transmission
; rate above the cap that you specified he will
; automatically be disconnected from the reflector and
; prohibited to reconnect for the specified hold-down-time.
; Cap is specified in kilo bits per second and hold-down
; time is specified in minutes. The default value for
; cap is 80 kilo bits per second and the default
; value for hold-down-time is 1 minute.

;ADMIT
; [useage: ADMIT ip-addr msg-string //]
;
; ADMIT is another mechanism you can use to limit the
; participants in a conference. By adding an ADMIT IP
; address line for each invited participant, the
; reflector will restrict the conference to only those
; participants who have an IP address which matches one
; of the IP addresses specified by an ADMIT line.
; The msg string is an ascii string terminated by a
; carriage return followed by two back slashes. This
; is the string that will appear on a participant's
; screen if he tries to connect but he is not on the
; admit list. Currently, there must be a message string
; specified with each ADMIT in the configuration file, but
; only the message string associated with the last ADMIT
; in the configuration file will be used. For now, that
; means you should just enter in some dummy string for
; each ADMIT in the configuration file except the last
; one. In some future version of the reflector all the
; message strings will be optional so that this nuisance
; will go away.

;MAX-PARTICIPANTS
; [useage: MAX-PARTICPANTS maxallowed msg-string //]
;
; MAX-PARTICIPANTS allows you to limit the load on your
; reflector to the specified number of participants. The
; maxallowed range is 0 to 40, with the default equal to
; 20. The msg string is an ascii string terminated by
; a carriage return followed by two back slashes. This
; is the string that will appear on a participant's
; screen if he tries to connect but the maximum number
; of allowed participants has been exceeded.

;LOG
; [useage: LOG filename]
;
; The reflector logs a small amount of information such
; as each participants arrival and departure from the
; conference in a log file. The default name for this
; file is reflect.log. To change the name of this file
; specify the LOG parameter with a different file name.

;LOG-LIMIT 5000
; [useage: LOG-LIMIT log-file-line-limit]
;
; If you have a busy reflector running for several days
; the log file can grow quite large. Use LOG-LIMIT to
; limit the number of lines in the log file. The default
; is 10,000 lines of log information. After the log file
; line limit is reached the reflector will erase the log
; file and start a new one with the same name. If you
; specify a log file line limit of 0, no log file will
; be created.

MOTD You made it, glad to see you stop by!
//
; [useage: MOTD ASCII motd-string //]
;
; MOTD is used to specify the message of the day. In any
; Mac version of CU-SeeMe above 0.70, or an PC version
; above 0.34 the application will display any motd
; messages when a user first connects to a reflector. The
; motd can be up to 800 characters in length. The
; message of the day string is an ascii string terminated
; by a carriage return followed by two back slashes.

;MAVEN
; [useage: MAVEN maven-port]
;
; Use MAVEN to allow the reflector to process Maven audio
; packets. The argument, Maven port, (the default Maven
; port is 3456) is the same port that is used when
; starting up the Maven application. When the reflector
; is configured with MAVEN, all Maven clients that
; connect to the reflector will automatically have their
; audio sent to all of the other Maven clients connected
; to the reflector. In addition any CU-SeeMe audio
; capable participants will have their audio sent to all
; of the Maven clients and any Maven clients that are
; also connected with a non-audio capable version of
; CU-SeeMe will have their audio sent to the CU-SeeMe
; audio capable clients.

;ADMIT-BCC-CLIENT
; [useage: ADMIT-BCC-CLIENT ip-address]
;
; ADMIT-BCC-CLIENT is used to cause the reflector to send
; a blind carbon copy of all of the CU-SeeMe streams to
; another reflector. This is used if you are putting on
; an event where there are a small number of active
; participants and a large number of passive viewers.
; The primary conference is run off of the main reflector.
; This reflector is configured with one or more
; ADMIT-BCC-CLIENT lists causing it to send CU-SeeMe
; streams to other reflectors. The passive audience then
; connects to these other reflectors on the "reflector
; net" to watch the main event.

;OBTAIN-BCC
; [useage: OBTAIN-BCC ip-address]
;
; OBTAIN-BCC is used to configure a reflector to receive
; a blind carbon copy feed from another reflector, as
; explained above.

;MC-OUT
; [useage: MC-OUT ttl multicast-addr]
;
; MC-OUT and MC-IN (see below) are similar to
; ADMIT-BCC-CLIENT and OBTAIN-BCC client, but take
; advantage of IP Multicasting. To use any of the
; multicast capabilities of the reflector, you must first
; make sure that your reflector has been compiled with
; the -DMULT switch, this causes the multicast code to
; be compiled into the reflector. Second, the reflector
; host must support multicast. Consult with your local
; UNIX guru to find out if your system is multicast
; capable or not. MC_OUT will send all CU-SeeMe streams
; to the specified multicast address using the specified
; ttl (time to live).

;MC-IN
; [useage: MC-IN multicast-addr]
;
; MC-IN is used to configure a reflector to receive a
; multicast stream put out by another reflector, as
; explained above. MC-IN and MC-OUT should not be used
; together on the same reflector.

;UNICAST-REF
; [useage: UNICAST-REF ip-address]
;
; UNICAST-REF is used to "tie together" two or more
; reflectors. This feature is useful if you are running
; a conference whose participants are spread out across
; the country. For example, if you have some folks on
; the east coast, another group in California, and
; perhaps a third group in the south, each group can
; connect to their local reflector and using UNICAST-REF
; you can connect all three reflectors together. This
; makes for a more efficient use of network bandwidth,
; rather than having everyone connect to a single
; reflector. Each reflector should have a UNICAST-REF
; for each other reflector.

;MC-GROUP
; [useage: MC-GROUP ttl multicast-addr]
;
; MC-GROUP is similar to UNICAST-REF, but takes advantage
; of IP Multicasting. Two or more reflectors can be
; "tied together" using IP multicast. Reflectors
; configured with MC-GROUP will send out all CU-SeeMe
; streams to the specified multicast address using the
; specified ttl, in addition they will accept incoming
; CU-SeeMe streams from that multicast address.

;NO-LOCAL-SENDERS
; [useage: uncomment to enable];
;
; NO-LOCAL-SENDERS is used in a configuration file that
; also contains either OBTAIN-BCC or MC-IN.
; NO-LOCAL-SENDERS sets up a reflector that is only used
; in viewing a conference taking place on a primary
; reflector. Since the purpose is to view the main event,
; you can disable local interaction among those who have
; connected to watch the main event. This will reduce
; the load on your secondary reflector.

;MC-TO-NV
; [useage: MC-TO-NV ttl multicast-addr]
;
; MC-TO-NV is used to send CU-SeeMe streams to nv. Nv is
; a UNIX based video conferencing application. nv must be
; started with the UDP port number that CU-SeeMe uses
; which is 7650. PLEASE NOTE THAT CURRENTLY nv CAN
; DISPLAY CU-SeeMe VIDEO, BUT CU-SeeMe CAN NOT DISPLAY
; nv VIDEO. This has been a point of confusion in the
; past.

;MIN-MAC-VERSION
; [useage: MIN-MAC-VERSION version-number msg-string //]
;
; MIN-MAC-VERSION is used to ensure that all of the Mac
; clients connecting to your reflector are at least at
; some minimum version number. This is useful if you
; are running a conference and there is some feature in a
; later version of CU-SeeMe, like audio, that you want to
; use during the conference. By setting a minimum version
; number only those clients with a version of CU-SeeMe
; greater or equal to the one designated, will be allowed
; to connect to the reflector. The msg string is an ascii
; string terminated by a carriage return followed by two
; back slashes. This is the string that will appear on
; the user's screen if the version he using is less then
; the specified version-number. The current version
; number for Mac based CU-SeeMe.70b1 is 12.

;MIN-PC-VERSION
; [useage: MIN-PC-VERSIION version-number msg-string //]
;
; MIN-PC-VERSION is used to ensure that all of the PC
; clients connecting to your reflector are at least at
; some minimum version number. This is useful if you
; are running a conference and there is some feature in a
; later version of CU-SeeMe, like audio, that you want to
; use during the conference. By setting a minimum
; version number only those clients with a version of
; CU-SeeMe greater or equal to the one designated, will
; be allowed to connect to the reflector. The msg string
; is an ascii string terminated by a carriage return
; followed by two back slashes. This is the string that
; will appear on the user's screen if the version he using
; is less then the specified version-number. The current
; version number for PC based CU-SeeMe0.34 is 2.

;DENY
; [useage: DENY ip-address msg-string //]
;
; Deny causes the reflector to deny access to the client
; at the specified IP address.
---<END CUT HERE>------------------------

--
  Paul S. Troutman                E-mail: paul.troutman@launchpad.unc.edu,
  ai456@yfn.ysu.edu                       ptro@freenet.scri.fsu.edu,
                                          ai456@yfn.ysu.edu