In this section, I endeavour to describe how to get started and get to understand how this all hangs together.
The first thing required to do is download pwlib and opal from http://www.voxgratia.org/. The pwlib library will (most likely) be already on your box if you have a well known distribution such as redhat, suse, or debian. I suggest you remove pwlib from your box, to eliminate library conflict issues.
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.
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
The server is the program which allows the different Sofa Switch entities to communicate. You will compile it with the command make both, in the server directory. For debugging, run with the "-r" option, which reports all incoming messages. This allows you to quickly ascertain which component is doing the wrong thing.
- Run the server with -r
- in a separate console, do python client.py cons1 machine_name_running_server
- in a second console, do python client.py console_2 machine_name_running_server
The python program client.py will connect to the server. You can send messages from one instance to the other. Commands like, "list", "cons1:hello" (to send hello to instance cons1) should be tried. You also have "end", to terminate the python program, and "quitnow" to kill the server. Note that you can run the python programs on any machine. The only requirement is that there is a path for TCP packets to travel between the server and python programs.
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 sound card can be utilised in the Sofa Switch environment, and it can send/receive audio with any other Sofa Switch audio component. The Answering Machine is perhaps the simplest other audio component, which can play/record audio from/to a wav file.
In the sound directory, build the executable with make both
In the answering machine directory (am) build the executable with make both
Once the server is running, start sound with
./ob_linux_x86_r/audio -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.
- The controller requests an answering machine entity to send/receive audio from. The answering machine supervisor sends a message back to the controller, advising the controller of the new identity.
- The controller tells the new identy (ssam1) to connect audio streams with the "sound" identity. Notice that the controller is not aware of the address used to transfer audio.
- The controller tells the answering machine identity to play audio from the file "sample_message.wav", and record to the file "derek.wav".
- Advisement notices (call setup, call terminating)
In this section, we create a more complex example, which consists of one conference room which contains three members. One Member is connected to the sound card, and ther other two members are answering machines. One answering machine is left dormant. The second answering machine injects audio into the conference, and records the conference audio.
Note that the person connected to the sound card may also inject audio into the conference, simply by speaking into the microphone
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 server reports
controller : ssmcu:REQUESTNEWID room
controller : ssam:REQUESTNEWID
ssmcu : controller:REQUESTNEWID ssmcu1
ssam : controller:REQUESTNEWID ssam1
controller : ssam1:transferudp ssmcu1
controller : ssam1:setannouncementfile sample_message.wav
ssam1 : controller:OutgoingCall ssam1
ssam1 : ssmcu1:transferudp ssmcu1 10.0.0.5:64000
ssmcu1 : ssam1:OutgoingCall ssmcu1
ssmcu1 : ssam1:transferudp ssmcu1 10.0.0.5:59000 done
controller : ssmcu:REQUESTNEWID room
controller : ssam:REQUESTNEWID
ssam : controller:REQUESTNEWID ssam2
ssmcu : controller:REQUESTNEWID ssmcu2
controller : ssam2:transferudp ssmcu2
controller : ssam2:setreceivedmsgfile derek.wav
controller : ssmcu:REQUESTNEWID room
ssam2 : controller:OutgoingCall ssam2
ssam2 : ssmcu2:transferudp ssmcu2 10.0.0.5:64001
ssmcu : controller:REQUESTNEWID ssmcu3
ssmcu2 : ssam2:OutgoingCall ssmcu2
ssmcu2 : ssam2:transferudp ssmcu2 10.0.0.5:59001 done
controller : sound:transferudp ssmcu3
sound : ssmcu3:transferudp ssmcu3 10.0.0.5:61000
ssmcu3 : sound:OutgoingCall ssmcu3
ssmcu3 : sound:transferudp ssmcu3 10.0.0.5:59002 done
From inspection of the messages, we see that
- ssam1 injects the wav file "sample_message.wav" into the conference
- the conference is recorded by ssam2
- sound from the user is injected into the conference via ssmcu3
- the user will hear the file "sample_message.wav" via ssmcu3
- The controller did not spawn of a subtask to manage this call.It is theoretically possible to write a multi threaded python script that handles all current calls with one sofa swith identity.
The testmcu.py script does not cause the conference to end. You can start up the client.py program, and send commands to any entity. You can, for example, ask ssam1 to play a different announcement file. The moment a new announcement file is specified in the answering machine, the old file stops playing and the new file starts playing.
To help explain the topology of this networked system, please refer to the diagram below.
- The solid thick black line indicates separate applications, or separate program. Within each application, there may be tens to hundreds of threads of execution to do the work
- The sold thin lines within the black box indicates an entity which is responsible for one conversation.
- The dotted lines with arrows indicate audio flow
- The dotted thick lines (no arrows) indicate a flow of control signals.
- Note that all control signals go via the server.
- We have shown the ssmcu as containing one conference room (denoted by the hexagon and word "room"). However, ssmcu could manage multiple conference rooms.
- There are three entities in the conference room, ssmcu1, ssmcu2 and ssmcu3.
- The conference room "room" was created by ssmcu by the command, "ssmcu:REQUESTNEWID room". The next time this command was sent to ssmcu, a new node was created (ssmcu2) and then placed in the specified conference room.
- The entities 'ssam', 'ssmcu', and 'controller' are supervisor style nodes.
- The entities 'ssam1', 'ssam2', 'ssmcu1', 'ssmcu2' are worker nodes.
- The sound program is designed to work with just one card. Consequently, it made little sense to put in a Supervisor/Worker feature. From a code perspective, sound is wrong. One day, I will add a supervisor to sound.
Generated on Sun Jan 29 19:48:56 2006 for Sofa Switch by
1.4.4
