Speak Freely for Unix
by John Walker
SFREFLECT(1) User Commands SFREFLECT(1)
NAME
sfreflect - Speak Freely conference reflector
SYNOPSIS
sfreflect [ -du ] [ -hpath ] [ -iinterval ] [ -mhost[:port]
] [ -pport ] [ -rinterval ] [ -vtimeout ]
DESCRIPTION
sfreflect implements a rudimentary multiparty conferencing
facility. Running on a server (which need not have audio
hardware), it accepts connections from users and, whenever
sound is received from any connected user, immediately re-
transmits it to all others. Users may join and leave the
conference at will simply by opening or closing a connection
to the reflector. The reflector can automatically publish
an HTML file listing members currently in the conference,
which can be examined by any user with a Web browser.
A reflector can invite connections by publishing its ex-
istence on one or more directory servers. See the ``Look
Who's Listening'' section in the sfspeaker manual page for
details on how to set the environment variables.
OPTIONS
-d Enables debug output.
-hpath
An HTML file is written to the given path name (a fully
qualified file name, less the .html suffix), listing
all users currently connected to the reflector. Pub-
lishing this HTML file as a World-Wide Web document on
the server allows easy access to a list of all active
users on the reflector. Unlike sflwld, sfreflect al-
ways includes the identity of connected users in its
HTML output, even if they have requested ``exact match
only''. Participating in a conference is equivalent to
connecting to another user, in which case identity is
also always shown.
-iinterval
The HTML file written by the -h option will be updated
every interval seconds if a change has occurred during
that period. If interval is set to zero, the file is
updated immediately after any change.
-mhost[:port]
Audio received by the reflector will be sent, in addi-
tion to the connected hosts, also to the specified port
on host. If no port is given, the default sfspeaker
port of 2074 is used. The monitor facility is primari-
ly intended to permit participating in a conference
from the same machine on which sfreflect is running,
but can be used to relay the conference to any host and
port on the network. See the section ``Single Machine
Set-up'' below for additional details.
-pport
Causes sfreflect to listen on the specified port number
instead of the default port of 4074.
-rinterval
The HTML written by the - h option will contain a
client-pull request which causes the user's Web browser
(if it supports client-pull) to automatically refresh
the document every interval seconds. If no -r option
is specified or interval is set to 0, no client-pull
updating will occur. Note the distinction between the
-i and -r options; -i specifies how frequently sfre-
flect updates the HTML file on the server, while the -r
option determines the interval between automatic down-
loads of this file to users displaying it in their Web
browsers. It doesn't make sense to set the - r option
to a shorter interval than the -i option, but to reduce
network traffic it may be eminently reasonable to up-
date the HTML file every 30 seconds or so, but only
have users refresh their browser display every two to
five minutes.
-u Prints how-to-call information.
-vtimeout
When sfreflect receives a packet from a host it hasn't
heard from in timeout seconds, it will attempt to
resolve the host name and print a message on standard
error noting the new connection and what compression
mode is being used. If the host name can't be deter-
mined, the numeric IP address is shown. After timeout
seconds of inactivity a message is issued indicating
the host is idle. If no timeout is specified, 180
seconds is used.
FILES
The -h option creates an HTML file with the given base name
and an extension of .new, then swaps the new file for any
previously-existing file with an extension of .html. The
file update process avoids the risk of a user's receiving a
file in the process of being written.
APPLICATION NOTES
To participate in a sfreflect conference, you must determine
the host name running the reflector and the port number it
listens to. Start sfspeaker with the -pport option specify-
ing the reflector's port number. If you don't specify the
reflector's port number, sfspeaker will listen on the de-
fault port of 2074; if the reflector uses a different port
you will not hear the packets it returns to you. Then start
sfmike specifying the reflector host name and port number as
hostname:port. The reflector will not forward sound from
the conference until you connect to it with sfmike; starting
sfspeaker is necessary but not sufficient.
Users of Speak Freely for Windows can join a conference sim-
ply by opening a new connection window and entering the
reflector's hostname:port. Speak Freely for Windows au-
tomatically listens for packets on all ports to which is has
open connections.
sfreflect works by simple packet replication; sound packets
received from any user connected to the reflector are im-
mediately resent, unmodified, to all other parties to the
conference (but not to the originator), with whatever proto-
col, compression, and encryption modes were selected by the
sender. This has several consequences you need to be aware
of in order to run a successful conference. First of all,
the site running the reflector needs to have sufficient
bandwidth in its connection to the Internet backbone to per-
mit sending a copy of every packet received to each member
in the conference. For example, suppose you routinely use
GSM compression to communicate over a 28.8 Kb dial-up link
to your Internet Service Provider, having no bandwidth prob-
lems because GSM compression uses only slightly more than
half of your available bandwidth. If you attempted to run
sfreflect and had three parties in the conference, perfor-
mance would be marginal since each packet received would
have to be sent to the other two people, and that would
exceed the capacity of the 28.8 Kb line. To avoid lost
packets (at least with long individual transmissions) you'd
need a faster modem link. Reflectors for conferences with a
large number of participants can be run successfully on fast
local networks, but are only usable across the Internet if
the reflector site has high bandwidth connectivity.
It is essential that all participants in a conference, even
if they have full-duplex audio hardware, operate in push-
to-talk or Voice Activation (VOX or squelch) mode whilst
connected to the reflector. Transmitting continuously, as
can be done on a full-duplex connection, will flood the re-
flector with packets and disrupt the transmissions of oth-
ers. As is the case with half-duplex point-to-point connec-
tions, it's a good idea for all participants in a conference
to verbally indicate the end of a transmission by saying
``over'' or the equivalent.
Connections to reflector sites should use Speak Freely pro-
tocol exclusively, not RTP or VAT. sfspeaker assumes a
given sender will use only one protocol at a time. Since
the reflector is considered a single connection, sfspeaker
has no way to determine the correct protocol if it receives
an intermixed stream of packets in various protocols. Using
the default Speak Freely protocol guarantees participants in
the conference will be able to hear packets from all
senders.
sfreflect relays packets in a variety of compression schemes
without difficulty, and sfspeaker will decompress them with
the appropriate algorithms and play them properly. If, how-
ever, a given compression scheme overloads the network
bandwidth or CPU capacity of one or more participants in the
conference, they will hear garbled audio even though others
may receive the same transmission perfectly. When setting
up a conference, it's best to specify a recommended compres-
sion mode appropriate to the computers and connectivity of
the expected participants and urge them to adopt that mode.
sfreflect correctly forwards encrypted packets. As long as
all participants in a conference have received and supply
the correct key, they can communicate secure against eaves-
dropping by others who may connect but do not know the
conference key. The automatic key generation and exchange
using PGP (-z option on sfmike) cannot be used in a confer-
ence, as it is strictly a two-party transaction. Instead,
distribute keys to participants in advance by electronic
mail encrypted with PGP.
Like all the other components of Speak Freely, sfreflect is
intended for communication among cooperating individuals.
sfreflect contains no ``social engineering'' mechanisms to
deter or prevent abuse. Users connected to the reflector
can interrupt one another just as they can in a conference
room, and a user who transmits incessantly can disrupt the
proceedings as effectively as a heckler in an auditorium.
One can easily envisage a variety of technological fixes
which would minimise the impact of this kind of behaviour;
indeed, systems intended for general public access have in-
corporated them for many years. sfreflect is neither in-
tended nor recommended for open access ``chat'' applica-
tions. It can, if adequate bandwidth is available and par-
ticipants understand the constraints of the medium and
cooperate with one another, permit small conferences where
people can come and go as they like without any central ad-
ministration other than a machine running sfreflect.
SINGLE MACHINE SET-UP
In the simplest configuration of sfreflect, it runs on a
server distinct from any machine used to access the reflec-
tor. You can host as many different conferences as you wish
on the same server (assuming it has adequate Internet con-
nectivity for the aggregate bandwidth) simply by running
multiple copies of sfreflect with each conference assigned
its own unique port.
Many potential users of sfreflect may not have the luxury of
a machine to dedicate to it. sfreflect's ``monitor host''
facility (-m option) permits hosting and participating in a
conference on a single machine. It's a little confusing to
set up, but once properly configured it will get the job
done. The fundamental problem which must be overcome is
that sfreflect listens and transmits on the port assigned to
the conference; users on other machines simply start
sfspeaker and sfmike specifying that port, and the reflector
does the rest. But on the machine running sfreflect, one
cannot start sfspeaker on the conference port because it has
already been assigned to the reflector. To work around
this, use the -m option on sfreflect and specify the local
machine name (normally you can omit the optional port
specification and use the default port of 2074). You can
now start a copy of sfspeaker which listens on that port,
and connect to the conference in the usual manner with
sfmike. The reflector is careful never to forward audio to
the host on which it is running, and the monitor host facil-
ity doesn't forward monitor packets from the local machine,
so you can listen to the conference without feedback, echo,
or locally duplicated packets. Here's a concrete example of
how to set everything up: assume your machine has a host
name of ``gizmo'' and you wish to host a conference on port
5214. You routinely run sfspeaker on the default port of
2074 for regular conversations. So, you'd start the reflec-
tor and sfspeaker as follows:
sfreflect -v -p5214 -mgizmo &
sfspeaker -v &
which will copy all audio the reflector receives on port
5214 to the default port of 2074 on gizmo, where sfspeaker
will play it. You can now join the conference with the com-
mand:
sfmike gizmo:5214
and transmit and receive in the usual manner. If you wish
to announce the conference and/or yourself on a Look Who's
Listening server, set the environment variables for the
conference prior to starting sfreflect and for yourself be-
fore starting sfspeaker. See the ``Look Who's Listening''
section of the sfspeaker manual page for additional details.
BUGS
It is easy to imagine thousands of zowie features which
might be added to this program, including transforming it
into a complete mixer which could receive packets from con-
nections in a variety of protocols and compression modes,
mix or interleave them in an intelligent fashion, and re-
transmit the composite audio stream in a specified protocol
and compression. Since at present it's unclear how many po-
tential users of a conferencing program such as this have
adequate connectivity to make effective use of it, it's un-
wise to invest the much greater effort such an elaborate
program would require without first getting some experience
with a much simpler tool.
ACKNOWLEDGEMENTS
The implementation of MD5 message-digest algorithm is based
on a public domain version written by Colin Plumb in 1993.
The algorithm is due to Ron Rivest. The algorithm is
described in Internet RFC 1321.
SEE ALSO
sfecho(1), sflwld(1), sfmike(1), sfspeaker(1)
by John Walker
September 17, 1998