Specifically, they can be downloaded from the page: http://www.voxgratia.org/downloads.html. The Faq, http://www.voxgratia.org/docs/faq.html is helpful for solving most of the build issues you will come across. Build instructions for linux are contained in the tarballs. You may need to set the environment variable LD_LIBRARY_PATH to get the code to run.
Many of the utilities in the SofaSwitch suite of programs (eg, am, mcu, voip) rely on the sofa library to compile and run. This library is in the directory labelled "sofa". The default location of the sofa library is in your home directory. Should you have it in a different directory, you will immediately get some weird build errors on building. To fix this, you need to set the environment variable
export SOFADIR=some_dir
some_dir/src
The server, answering machine, and sound card utility do not need the opal library to compile and build. These applications rely on pwlib. The opal library is used in the voip utility to do H.323, SIP, or IAX2 calls.
There are python based programs as part of this application - these do the work of controlling everything. Python 2.2 is sufficient to run the controller scripts
If you are having troubles getting your library path sorted, you may consider building the executable with the commands
server> python client.py console_2 localhost list read in console_2 read in cons1 cons1:hello list read in console_2 read in cons1 quitnow OOOOOPS. The server has gone. We exit now.
The server reported:
server> server -r
console_2 : list
console_2 : cons1:hello
console_2 : list
console_2 : quitnow
end of this server program
The server output consists of two columns: left being the source of messages, and the right being the message itself. Note that here, the user was typing text in at the console identified as "console_2". No text was typed in at cons1.
The server is expected to be running before starting this test.
Compile build, and run the sound utility.
cd sound make both ./obj_linux_x86_r/sound -s beta -d Ensoniq\ AudioPI
The options to the sound utility say the sofa message server is on the host "beta", and the sound device is "Ensoniq AudioPCI". If this utility is unable to open the sound device, it will list the available (and valid) sound device names.
In the controller directory, there is a python script, "testonesound.py". Run this script file with the command
python testonesound.py
If you are running the python test script on a different box to the message server, you will need to append to the above command line the name of the box running the message server.
This test simply tells the sound card to echo audio from the microphone back to the speaker, so you will hear the transmitted audio with a slight delay. The test enquires of the sound program for status information every 2 seconds, which is reported to the console. After 20 seconds of operation, the sound utility is closed, and the "testonesound.py" script file ends.
This mode of operation is a bit unusual, in that we have a sofa utility sending audio to itself. However, we are trying to introduce things at a gradual and slow rate, so are only describing one utility at a time. Normally, one sofa utility will send audio to another sofa utility. The next test, in Test sound card and Answering Machine will introduce you to a second sofa utility. Consequently, we can show you audio moving from one utility to another.
Now, you can add to this test. With the "client.py" script file running at the same time, you can send additional commands to the sound utility. Alternatively, you can send commands to the 'controller'. To see what nodes are connected to the server, send the command 'list'. At this point, you know who you can send commands to.
In the sound directory, build and run the executable with a command as described above.
In the answering machine directory (am) build the executable with make both
Once the server is running, start sound with
./ob_linux_x86_r/sound -s machine_running_server -d Ensoniq\ AudioPCI
Once the server is running, start the answering machine with
./ob_linux_x86_r/ssam -s machine_running_server
For the test script to work, we expect that ssam is launched from a directory containing a 16bit, 8khz sound file, called "sample_message.wav"
In the controller directory, there is a python script that will connect the audio streams from the answering machine and sound executables together.
python testsound.py machine_running_server
The server reports the following messages.
controller : ssam:REQUESTNEWID
ssam : controller:REQUESTNEWID ssam1
controller : ssam1:transferudp sound
ssam1 : controller:OutgoingCall ssam1
ssam1 : sound:transferudp sound 10.0.0.5:64000
sound : ssam1:transferudp sound 10.0.0.5:61000 done
controller : ssam1:setannouncementfile sample_message.wav
controller : ssam1:setreceivedmsgfile derek.wav
controller : ssam1:hangup
ssam1 : controller:Terminating
The messages are in four groups.
ssam:status full
ssam:Current Status:-----------
Comms instance count 61 50 11
Consumer instance count 50 50 0
pre, active & dead calls 0 1 0
Current active nodes:
ssam51
There are 11 Comms instances currently availble. One is used in an active call (ssam51), and the remaining 10 have connected to the message server. These remaining 10 are therefore ready for immediate use, should they be requested by the controller.
The Consumer instance count is a class that is very short lived, and designed to clean up calls after the call has terminated.. In this case, 50 have been constructed, 50 deleted, and balance is zero. If there are several available Consumer instances, we have evidence that the calls are not being cleaned up. Each Consumer instance is a separate thread, created to clean up one call. A call is cleaned up independently (well, as much as possible) from all other calls.
From within the "client.py" script, whicle the "testsound.py" script is running, we can interrogate the message server to see what is happening. We send the command "status full", which looks like:
status full Status of the Server ------------------------- Constructed/Deleted TcpConnections 98 72 26 Count ready made TcpConnections 10 Messages Sent Received Dropped Diff 1274 972 108 194 Current list size 15 current nodes controller sound ssam ssam51 ssam52 ssam53 ssam54 ssam55 ssam56 ssam57 ssam58 ssam59 ssam60 ssam61 test
The server has reported that there are 26 available TcpConnection class instances. One TcpConnection instance is used for each connected node. The figure of 26 above is correct.
The conference utility has to be compiled (make both) and invoked. The command line args are identical to ssam.
./ob_linux_x86_r/ssmcu -s machine_running_server
The script "testmcu3.py" has to be invoked. This will add a member to the conference room that does play a message. The message is played 10 times. This script will exit when the user presses the return key. This script provides a unique id server for other controllers to use. When another controller is created (say in testmcu3_time.py) the controller will have a new unique id.
The remainder of this description on the mcu and am assumes that the script "testmcu3.py" has been started, and is waiting for the user to terminate it. Please do not terminate this script. This script has created a conference room with one member.
In the "client.py" window, we type "ssmcu:status", to get the status of the mcu as a whole.
ssmcu:status ssmcu:ssmcu:Current Status :------------------ Comms instance count : 12 1 11 Member instance count : 2 1 1 Participant instance count: 2 2 0 Available conference rooms 1 room:room members:1
See, there are 11 current instances of the Comm class. 1 has been deleted - that was used when playing the annoucements from when "testmcu3.py started up. Of the current instances, 1 is in use. 10 have been premade, ready for immediate use as required. These premade instances have already connected to the server, as can be seeen by listing the nodes currently on the server.
The Member instance count is 1 - there are a total of 1 connections actually in a conference room. The Participant instance count is 0. These Participants are used to create the link between members and are required for muxing the audio together. If there are N members in a conference room, then we require N*(N - 1) participant instances. It is essential N squared, because every member has links to every other member in each cnference room.
Additional information can be obtained with the command "ssmcu:status room", to get information about the activities in room. This command reports:
ssmcu:status room
ssmcu:ssmcu:Current Status :------------------
Comms instance count : 12 1 11
Member instance count : 2 1 1
Participant instance count: 2 2 0
Available conference rooms 1
room:room members:1
Available members is 1
member ssmcu2
Participants in Conference room "room" are::
-ssmcu2
Duration Info
-ssmcu2 19:14.462 mins:secs.msecs
See? It has told us that in conference room "room" the names of the available members, and how long these members have been in this room.
In a separate window, run the command
python testmcu3_time.py
while true; do python testmcu3_time.py & sleep 5; done
If you leave this script running, you can examine the list of nodes on the server changing with the "client.py" script. You see the Member instance count on the mcu, and Participant instance count on the mcu increase.
You also see that when it is playing the message, there are two Members in the conference, and two Participants. The Participant count is correct, because each Member has a link to the other Member in the conference.
You can also try making the test a bit tougher. If the sleep period is changed to 1 second, you will hear a jumble of voices in the conference. During this time, there will be multiple members in the conference, and lots of Participants.
The script "testmcu3a.py" is used to play a silence wav file into the conference. It can be run in exactly the same way as testmcu3_time.py
The script "testmcu3b.py" is used to play a "ding-dong" type sound. It can be run in exactly the same way as testmcu3_time.py
To help explain the topology of this networked system, please refer to the diagram below. This diagram assumes three Members in the conference.
You can see the commands used to create these members by running the server with the option "-r" to report all incoming messages.
1.4.6