Thebridge is an EchoLink compatible conference bridge that runs under FreeBSD, Linux, QNX, Mac OS X, Windows and hopefully most other Posix compatible operating systems.
GNU General Public License v2.0
5
stars
4
forks
source link
readme
Welcome to thebridge, a member of the CQiNet family.
Thebridge is an EchoLink compatible conference bridge that runs under
FreeBSD, Linux, QNX, Mac OS X, Windows and hopefully most other Posix
compatible operating systems.
If you've never hear of EchoLink then this software probably won't make
much sense to you. See: http://www.echolink.org then if you are still
interested continue here.
The EchoLink system, and by extension this software, are for Ham radio
operators. Unfortunately unlike "real" Ham Radio SWLs (short wave
listeners) are not welcomed so if you're not already a licensed ham it is
unlikely that you will find much of value here, sorry.
If you haven't given up yet and are running Windows give up now ... No wait!
I'm just kidding ! But seriously folks ... read the file README.txt
instead of this one.
############################################
Updating from previous versions of thebridge
############################################
New versions of thebridge are usually backwards compatible with configuration
files from earlier releases HOWEVER new variables are added frequently. Since
the sample tbd.conf.sample file includes documentation on some features which
are not mentioned elsewhere it is worthwhile to review the sample configuration
file with each release to discover new capabilities which you may want to
take advantage of.
###########
Portability
###########
A quick word on portability: I've tried to the best of my ability and means
to make thebridge as portable as possible. I've tested it under several
versions of FreeBSD and Linux, however ALL testing has been on the Intel x86
architecture. I hope the code will work on big endian machines as well, but it
has not been tested on one yet. If you try this software on a big endian
machine I would be very interested in hearing of your success or failure.
###################
Building on a *nix:
###################
"make install"
Requirements:
The only known requirement to build thebridge is the GNU GCC compiler or
something compatible, a make program and a Bourne shell to run the configure
script. GNU make is not required, any old make should be fine. I tried to
avoid the use of exotic compiler features, hopefully any version of GCC
will work.
As of this writing thebridge has been built and run successfully on
FreeBSD 2.2.7, FreeBSD 4.4, Red Hat 7.3, Suse 7.3, Slackware 8.0,
QNX RTP 6.1 and Mac OS X.
If for some reason either configure or the make should fail please
send me the details and I'll try to help you correct the problem.
Extract:
The distribution tar file extracts into a version specific subdirectory so
different releases do not conflict with each other. Substitute the actual
version number for "{VERSION}" above. The ".tgz" extension signifies a
Gzip'ed TAR file.
GNU configure:
Thebridge uses a GNU autoconfig generated configuration script to generate a
site-specific Makefile that is then used to build thebridge. The configuration
script is written to be as portable as possible by only assuming the
availability of the most generic Bourne shell features. A suitable shell
should be available on just about every *nix system. It will certainly be
available on any system using other GNU tools.
The configuration script provides a great deal of flexibility in the way
the target program is built and installed, run "./configure --help" for the
gory details. Luckily most of the features are seldom needed and running
configure without any options is usually sufficient.
If you have the GNU readline library (libreadline) you can configure tbdcmd
to use it by specifing the --with-readline switch. The readline library
adds features such as command history and curses based line editing to
tbdcmd and tbdchat.
Once the configure script has been run you should have a config.h and Makefile
appropriate for your system. With any luck you should see something similar
(but probably not identical) when you run configure:
--- snip ---
% tar xzf thebridge-0.10.tgz
% cd thebridge-0.10
% ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for socket in -lsocket... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for sys/time.h... yes
checking for unistd.h... yes
checking for sys/signal.h... yes
checking for sys/timeb.h... yes
checking for working const... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for strdup... yes
checking for getopt... yes
checking for ftime... no
checking for gettimeofday... yes
checking for stricmp... no
checking for strcasecmp... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating config.h
%
--- snip ---
Make:
The generated makefile provides several useful targets, the default "all"
builds thebridge. The other frequently used targets include "install",
"clean", "distclean", and "uninstall".
--- snip ---
% make
make all-recursive
Making all in src
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c avl.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c conference.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c configfile.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c configvars.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c dirclient.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c main.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c thebridge.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -c users.c
gcc -Wall -DSYSCON_DIR=\"/usr/local/etc\" -g -O2 -o tbd avl.o conference.o configfile.o configvars.o dirclient.o main.o thebridge.o users.o
%
--- snip ---
There shouldn't be any errors or warnings displayed during the build process.
If you get warnings or errors I'd be interested in hearing about them. The
final output of the build process is the thebridge daemon "tbd" which is built
in the src subdirectory. The name of thebridge executable is tbd for "TheBridge
Daemon (and it's also a good excuse to create yet another TLA). We'll test it
before installing it. Before we test it we need to edit the configuration file.
#######################
thebridge Configuration
#######################
There is a single text file "tbd.conf.sample" that is used to configure
thebridge. Fire up your favorite editor and change the various variables to
appropriate values. Refer to the comments in the file for guidance.
Most sites will only need to change the ConferenceCall, ConferencePass,
ConferenceQth and WorkingDir settings.
NOTE: the EchoLink directory servers *WILL NOT ACCEPT* a conference style
callsign like "*W1AW*" unless you have specifically registered as a conference
by the EchoLink administrators. I suggest that you test the conference
using your usual callsign first. See www.echolink.org/el/conf.htm for more
details.
Lines beginning with ';' or '#' are comments, if you decide to set any of the
optional settings be sure to delete leading ';' character before the
configuration variable.
--- snip ---
% cp tbd.conf.sample tbd.conf
% vi tbd.conf
--- snip ---
Since daemons are not connected to any console they must communicate with
the sysop in some other manner. As with most *nix daemons thebridge uses
the syslog system. Thebridge uses "LOG_LOCAL5" as the facility when opening
the log and generates messages with priorities LOG_INFO, LOG_WARNING and
LOG_ERR. It's up to the user to decide which message if any he wants to log,
but unless you are a psychic I would strongly suggest that at least the LOG_ERR
messages be logged.
Lets assume we want to log all messages and that we also want to put them into
a separate log file. To accomplish this we need to reconfigure the syslog
daemon. The reconfiguration consists of nothing more than adding two lines
to the bottom of /etc/syslog.conf. You will need to edit the file as root.
Most daemons load their configuration files at system boot time and do not
check for changes while running. In most cases sending the hangup signal (HUP)
to the daemon will cause it to re-read the configuration file. Both syslogd
and thebridge work this way. In order to send a signal to a daemon we need
to know its process identification (pid) number. For convenience most daemons
store their PID number in a file /var/run/{daemon name}.pid to make it easier
for scripts to send signals to them. Again both syslogd and thebridge follow
this convention.
Some versions of syslog seem to require that a log file to exist before they
will use it. Lets be safe and create the file before issuing the HUP.
--- snip ---
%su
Password:
fastbsd# vi /etc/syslog.conf
(add the following at the end of the file)
!tbd
*.* /var/log/tbd.log
(save the file and exit vi)
fastbsd# touch /var/log/tbd.log
fastbsd# kill -HUP `cat /var/run/syslog.pid`
fastbsd# exit
%
--- snip ---
Syslog should now be ready to log the messages from tbd. Refer to the
syslog(3), syslogd(8), and syslog.conf(5) man page for more details.
#######
Testing
#######
The daemon has two command line switches to aid testing. The first switch -f
specifies where the tbd.conf configuration is located.
The second switch -d enables debug mode, causing the daemon to run in the
foreground as a user process while displaying debug information on the screen.
The debug switch may be used multiple times to increase the detail level of
the information displayed up to a maximum of three times.
For our purposes a single -d suffices.
--- snip ---
% src/tbd -d -f tbd.conf
PullerLoginAck(): Client 2 successfully updated status.
ParseStationList(): completed successfully, 376 stations listed.
--- snip ---
The first message indicates that the daemon was successful in logging into the
directory server. Note: the EchoLink servers indicate a successful login
even if the supplied callsign/password combination is unknown, invalid or
banned. But the success does indicate that tbd was able to establish an TCP
connection to the server.
The second message is the real good news, our directory request returned 376
stations. If your callsign or password were not recognized there would be
0 stations.
If you are not able to get a station list, check the configuration file. You
might also want to rerun the test using more "-d" switches to help determine
what when wrong.
Unfortunately, due to the nature of the EchoLink protocols it is not
possible to test thebridge further using a single computer. In particular
the client program uses the same ports as the server so it's impossible to run
a server and a client on the same host at the same time.
Even if you have multiple computers you can't test the program unless you also
have multiple *external, routable* IP addresses. You can't connect to
thebridge from another computer on your local LAN if your local LAN is
connected to the Internet using a NAT box or other form of Internet sharing
where all of your computers appear to be coming from the same IP address.
The easiest way to complete the testing is to have a couple of friends connect
to thebridge and see if they can talk to each other. When a station connects
to thebridge you'll see a message similar to the following:
--- snip ---
WD4NMQ JEFF logged into conference.
W7NTF GARY logged into conference.
--- snip ---
Once you've verified that thebridge is operating correctly we're ready to
complete the installation. Hit Ctrl-C to abort thebridge.
--- snip ---
^CReceived SIGINT, shutting down
PullerLoginAck(): Client 4 successfully updated status.
Logged out, exiting.
%
--- snip ---
############
Installation
############
Thebridge is designed to run as a system daemon, i.e. a background program
that's loaded automatically by the system as part of the bootup process.
If you are not familiar with the system startup scripts or you are not
comfortable starting thebridge automatically you can always start thebridge
daemon manually when desired. Starting thebridge automatically is primarily
needed when the host is unattended and it is desired to run thebridge 24/7.
Refer to the "Running without Root access" section if you would rather not
modify your system's startup behavior.
Unfortunately my installation rules and knowledge are not complete enough about
all of the various *nix variations to complete the installation without manual
assistance.
Most Posix operating systems start system daemons using approaches similar
to either FreeBSD (i.e. the BSD camp) or RedHat (i.e. the System V camp).
Scripts to install thebridge on FreeBSD and RedHat Linux have been provided.
Start with the scripts that are the closest match to your system and then
modify them if necessary. I will be happy to include installation scripts
for other operating system that are sent to me with future releases.
Configuration files for daemons are kept in different places on different
systems. It doesn't really matter where the configuration file is as long
as tbd can find it. If you want to put it somewhere other than where
the GNU autoconf tools think it belongs just specify the full configuration
file path on the command line using the -f switch.
FreeBSD
Local (not part of the standard distribution) daemons on FreeBSD systems are
started by placing a shell script /usr/local/etc/rc.d directory with an ".sh"
extension. During startup each script is called with an argument of "start".
During system shutdown they are called again with an argument of "stop".
If you are running on FreeBSD run the installation scripts from the FreeBSD
subdirectory. The installation script will copy tbd, tbd.conf.sample and
tbd.sh into the appropriate subdirectories. You will need to be root to
when running the installation script.
--- snip ---
%cd FreeBSD
%su
Password:
fastbsd# ./install
+ cd ..
+ make install
Making install in src
/bin/sh ../config/mkinstalldirs /usr/local/libexec
/usr/bin/install -c tbd /usr/local/libexec/tbd
/bin/sh ./config/mkinstalldirs /usr/local/etc
/usr/bin/install -c -m 644 ./tbd.conf.sample /usr/local/etc/tbd.conf.sample
+ cd FreeBSD
+ cp tbd.sh /usr/local/etc/rc.d
fastbsd#
--- snip ---
Since the installation process only copies tbd.conf.sample (to prevent
accidents when thebridge is updated in the future) we must manually copy
or configuration file to the "standard place":
--- snip ---
$ cp tbd.conf /usr/local/etc
--- snip ---
RedHat Linux
If you are running on RedHat Linux run the installation scripts from the
RedHat subdirectory. The installation script will copy the tbd executable,
tbd.conf.sample, and tbd shell scripts into the appropriate subdirectories.
It will then create links from /etc/rc.d/rc*.d subdirectories the
/etc/rc.d/init.d/tbd shell script to start tbd in run levels 2, 3, 4 and 5 and
to stop tbd in run levels 0, 1 and 6. You will need to be root to when
running the installation script.
--- snip ---
$ su
Password:
[root@linux73 RedHat]# ./install
+ cd ..
+ make install
Making install in src
make[1]: Entering directory `/home/skip/thebridge-0.10/src'
make[2]: Entering directory `/home/skip/thebridge-0.10/src'
/bin/sh ../config/mkinstalldirs /usr/local/libexec
/usr/bin/install -c tbd /usr/local/libexec/tbd
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/skip/thebridge-0.10/src'
make[1]: Leaving directory `/home/skip/thebridge-0.10/src'
make[1]: Entering directory `/home/skip/thebridge-0.10'
make[2]: Entering directory `/home/skip/thebridge-0.10'
/bin/sh ./config/mkinstalldirs /usr/local/etc
/usr/bin/install -c -m 644 ./tbd.conf.sample /usr/local/etc/tbd.conf.sample
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/skip/thebridge-0.10'
make[1]: Leaving directory `/home/skip/thebridge-0.10'
+ cd RedHat
+ ln -s /usr/local/libexec/tbd /usr/sbin
+ '[' '!' -d /etc/rc.d/init.d ']'
+ cp tbd /etc/rc.d/init.d
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc0.d/K73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc1.d/K73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc2.d/S73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc3.d/S73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc4.d/S73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc5.d/S73tbd
+ ln -s /etc/rc.d/init.d/tbd /etc/rc.d/rc6.d/K73tbd
[root@linux73 RedHat]# exit
$
--- snip ---
Since the installation process only copies tbd.conf.sample (to prevent
accidents when thebridge is updated in the future) we must manually copy
or configuration file to the "standard place":
--- snip ---
$ cp tbd.conf /usr/local/etc
--- snip ---
Running without Root access
If you don't have root access to the system you will not have the necessary
rights to modify the configuration files necessary to start thebridge at boot
time. Since the EchoLink protocols do not use any privileged ports you
will still be able to run thebridge. Just execute it manually in debug mode
specifying the location of the configuration file and redirecting the output
to a log file or the bit bucket.
--- snip ---
%src/tbd -d -f tbd.conf > /dev/null &
%
--- snip ---
#############
User Commands
#############
A few commands are available to users that are unique to thebridge. Commands
are entered on the message line in the same way as a text message, by
prepending a '.' (period). Commands are not forwarded to other conference
users so they are non-intrusive to normal operations. The command must begin
at the first character on the line.
Commands may be abbreviated to the shortest length that is still unique. For
example ".stat", ".sta", and ".st" are valid abbreviations for the
".stats" command, but not ".s" since there are two commands that start with
the letter 's' (.stats and .sysop).
".help" and ".?"
This command does much as you would guess, it lists the available commands.
".list" (not available on all conferences)
This command lists any bulletins or recorded nets that may be available to
be played back.
".lookup "
This commands displays the node number, Qth and busy status for a specified
station. The station must be online or have been online recently for the
information to be available.
".play ", ".stop" (not available on all conferences)
This command starts playing the selected bulletin or recording. Any text
messages that were sent during a net are also replayed sent. While you are in
playback mode you will not be listed on the station list of thebridge and
you will not receive any live conference traffic, voice or text. To end the
playback enter the .stop command or simply disconnect.
".showip"
This command dumps the user list with IP addresses.
Format: <'S' | 'R' | 'E'>
The list is terminate by a blank line. The final character indicates the
users protocol, SpeakFreely, RTP, or EchoLink. The callsign field will
also contain the user's IP address if the protocol does not provide a callsign.
".stats"
This commands displays interesting (to some) technical statistics about
the operation of the conference bridge such as when the maximum number of
users were connected.
".lurk" and ".delurk" (not available on all conferences)
The EchoLink system is very different than "real" radio in one important way...
everyone knows who is listening. Sometimes you might only want to monitor a
channel, but not get involved in a conversation. This is particularly useful
for nets when you want to listen, but don't have anything to contribute.
The ".lurk" command allow you to suppress the listing of your callsign as an
active member of the conference, but you will still be able to listen. You
can rejoin the conference at any time by using the ".delurk" command or by
simply transmitting.
".uptime"
This command displays the amount of time thebridge has been running since it
was loaded. I'll admit it, the primary purpose is for bragging rights... "my
conference bridge has been up for ..."
".version"
This command displays the version of thebridge software and the type
of operating system it's running on.
".test" (not available on all conferences)
This command causes thebridge to record your next transmission and then play
it back to you when you stop transmitting. This allows you to test your setup
and adjust audio levels etc without assistance. Audio quality is a very
subjective thing, it's always best to hear it yourself.
Note: The UDP protocol used for conferencing is not 100% reliable, the
".test" command will send you the response "Your next transmission will
be recorded and played back." to indicate that your command was received.
Please do *NOT* make a long test transmission unless you receive the response!
Otherwise your test transmission will be sent live over the conference bridge.
##############
Sysop Commands
##############
".sysop "
None of the sysop commands are available until you identify yourself as
an sysop by using the .sysop command and supplying the sysop's password.
Additionally sysop's are allowed to transmit during the pausetime to give
them slightly higher priority on the channel than normal users.
When using this command please *make* sure that you enter the leading '.' and
start the command at the beginning of the line, otherwise you may send the
sysop's password to everyone logged into the conference!
Once you have logged in successfully you will be greeted with a welcome
message. You will remain logged in as an sysop only as long as you are
connected to thebridge, if you disconnect you will have to login again.
WARNING: Please do not use a "valuable" password for the administrator
password, it is sent in clear text via UDP to the RTP port. i.e. it can be
sniffed.
".admins"
This command simply lists the users who are logged in as administrators or
sysops. This is a good way of verifying that you are logged in as an sysop
before issuing commands. It's also a good way to determine if it's time to
change the passwords (grin).
".busy [on | off | status]"
This command controls the conference's busy status. The conference's busy
status is listed in the station directory, additionally connection
requests from new stations are refused when the conference is busy. The
status option allows a conference to indicate that it is busy to the directory
servers, but actually continue to accept connections for special purposes.
".connect [-m] [-p ] [-s] [-r] "
".disconnect "
".disconnect ALL"
".disconnect last"
".disconnect ."
These commands allow conference rooms to be linked to increase the capacity
beyond what is available on a single server. The .connect command will accept
either a station callsign, conference ID, or IP address.
The .connect command establishes a permanent connection between until a
.disconnect command is entered by an administrator (of either conference). If
the connection fails the connect will be reestablished automatically when the
path returns.
When thebridge is linked to another thebridge running version 0.33 or later
then user's callsign and name will be displayed on the linked conference next
to the conference's callsign in the station list.
The .connect command can actually be used to connect to any station it is
not restricted to conferences. If a connection is established to an user
station he will be able to disconnect using the usual method, this is
equivalent to an administrator entering the .disconnect command.
The -m option specifies that a connection started in the .monitor mode. The
".monitor disable" command can be used to set the connection to full transceive.
The -s option specifies that the connnection should be made using the speak
freely protocol rather than the default EchoLink protocol. The speak
freely protocol is provided for compatability with other applications.
The -r option specifies that the connection should be made using the RTP
protocol rather than the default EchoLink protocol. The RTP protocol is the
prefered protocol for anything other than EchoLink connections.
The "ALL" option to the ".disconnect" command disconnects all users, not just
users who were connected to using the ".connect" command.
The "LAST" option to the ".disconnect" just disconnects the last station that
connected leaving any other users connected.
The "." option to the ".disconnect" disconnects the station that is talking
currently.
".lurk disable" ".lurk enable" ".lurk " ".delurk "
Lurking is one of my personal favorite capabilities of thebridge, infact it
was the first command. However not everyone shares my opinion. The ability
to disable lurking has been the most requested feature. The disable option
disables (duh!) the ability for stations to "lurk", the enable option restores
the capability. By default lurking is enabled. Stations attempting to lurk
when lurking is disabled will be sent a messages informing them that the
lurking feature has been disabled.
Sysops can set a specified station's lurking mode. This is useful to restore
a stations state after thebridge has been (quickly) rebooted.
"message [message text]"
This command may be used by the scripting interface to send text messages
to conference users. Unlike the normal EchoLink text mode messages received
from the command port are assumed to be commands and need not be prefixed
by a period.
".monitor [disable] "
This command allows you to put a station in to a talk only mode. This command
is basically the opposite of the ".mute" command, the monitored client can
talk, but not listen. This is useful in certain (unusual) situations such
as the recent shuttle disaster when you want to listen to a conference, but
while ensuring local traffic does not interrupt it.
The disable option is used to return a station to full transceive operation.
".mute" ".mute ." ".mute [ ...]"
".unmute ["
This command allows the configuration variable PauseTime to be adjusted as
needed during normal operation. The PauseTime variable sets the minimum gap
between transmissions on the conference. Stations who jump in before the
minimum time has elapsed will be sent a warning message and will not be
repeated until the minimum pause time has elapsed.
This parameter may help prevent repeater "bouncing" that occurs when multiple
repeaters or link stations are logged into a conference room with poor
operating parameters. It will also ensure that there's a break between
transmissions to allow simplex links to leave the conference.
".play4 [-f] [-i] [displayed name]"
This command allows a recording file to be played all users. When the file is
played for all users an optional description may be entered which will appear
on the station list as the "station" talking. If the description is omitted
the "station" will be shown as "QST". The timing of the playback is
controlled by the same configuration file variables as the .play command.
Normally playback will begin as soon as the conference free (no one is
talking), -f and -i flags are used to modify this behavour. The -f flag can be
used to force the playback to begin immediately even if someone is talking.
The -i flag can be used to force the playback to wait for IdleTimeout seconds
of inactivity before the bulletin playback begins.
These flags provide the ability for scripts to do things such as automatically
playback a net at a particular while warning any users before hand to allow
them time to finish their QSOs. For example a couple of warning anouncements
could be played 10 mintutes, 5 minutes and one minute before the net and then
the bulletin could be played exactly on time using the -f command.
A less driven conference operator might simply use the -i command to play the
bulletin as soon as the conference becomes free after the appointed time. This
would allow QSOs to finish naturally before begining a playback.
".play4 -u "
This variation of play4 command allows a recording to be played for a specifc
user.
".users [-b] [-c] [-q] [-t] [-T] [-v] [?]"
The .users command lists the callsign of all VoIP connections order of login
along with their attributes. This command is particularly useful for net
control operators by enabling them to see more stations than will fit in the
EchoLink client's info window.
The meaning of the attribute characters may be display by the ".user ?"
command. They are as follows:
User attributes:
0 - User is usign the Speak Freely protocol
1 - User is using the RTP protocol
A - User is logged in as an administrator.
a - User is using the ADCPM codec
B - User is running theBridge conference or thelinkbox.
C - User is a linked conference other than thebridge.
c - User's chat text is been suppressed
F - User is playing a file (using the .play or .test commands).
f - User is Full duplex
I - User is Isolated (not In conference)
K - User's has been Kicked (being disconnected).
L - User is a Lurker.
m - User's audio is muted.
M - User's audio and text are muted.
P - User is a permanent connection (connected by a .connect command).
R - User is in Receive only mode (being monitored)
S - User is logged in as a sysop.
T - User is currently Talking.
u - User is running the uLaw codec
x - User connection is inactive
! - User is an old version of thebridge which sent SDES packets containing
a private "txt" extension field.
The -b (bare) switch suppresses the display of user attributes.
The -c switch displays the amount of time the user has been connected.
The -q switch suppresses logging of the .user command. This is useful when
the .user command is used by AJAX scripts to prevent the log from being
filled with less than interesting information.
The -t switch displays the amount of time since user last transmitted.
The -T switch sorts the user list by time since last transmission.
The -s switch displays the user list in the same format as is presented
to EchoLink users on the right hand side of their client.
The -v switch displays the version number of user's client
".belchfilter" ".belchfilter