point-to-point problem with speak_freely

* point-to-point problem with speak_freely
@  Charles Hallenbeck
   ` Kirk Reiser
   ` Geoff Shang
  0 siblings, 2 replies; 7+ messages in thread
From: Charles Hallenbeck @  UTC (permalink / raw)
  To: Speakup Distribution List

Hi gang,

I am puzzled by the failure of something I thought ought to work, and I am
hopeful that one of our speak_freely experts might be able to advise me
what I am doing wrong.

I am trying to establish user to user contact with another local Linux
user. I have created a script which runs sfspeaker (see below) which we
both use. The procedure I think ought to work is this:

1. We each run the script to start sfspeaker on the default port, 2074.
2. My friend determines his IP address and communicates it to me. We did
this by telephone while experimenting, but could eventually do it by
email.
3. I trun "sfmike" with my friend's IP address as the argument. So far so
good - i press space to talk and my friend hears my voice with only a
slight delay.
4. My friend types the command "sf-ans" which was created by the script he
has run in step 1, in response to my incoming call. This does not work. I
hear no voice, and he hears the audio busy signal sent to him by me, also
specified in the script below.
5. He repeats his attempt to send me a voice message, and is told his
connection to me is refused. I attempt to send him a voice message again
and am told that he refuses my connection.

Here is the script we run to start our sfspeaker programs. I will comment
on a couple of lines later...

#!/bin/bash
setsource mike
killall sfspeaker >/dev/null 2>&1
export SPEAKFREE_LWL_TELL=""
rm ./sf-ans >/dev/null 2>&1
sfspeaker -a./sf-ans -b"sleep 10; sfmike %s /pub/sounds/busy.au" -j2000  &

Comments:
"setsource mike" merely runs amixer to accept sound card input from the
microphone.
"killall sfspeaker" insures that we will not have any old process lying
around to interfere with this script.
Setting the environment variable to null suppresses posting the IP address
anywhere.
The "rm" command removes any previous "sf-ans" file so that only a newly
created one will be effective.
Finally, the sfspeaker command is asked to create an "sf-ans" file, to
supply a "busy signal" when appropriate, to change the "jitter" value, and
to run in the background.

So to summarize: We both run the above script so that sfspeaker is active
on both our systems with the default port, 2074. Then I run sfmike with my
friend's IP address and establish communication from me to him,
successfully. This creates "sf-ans" on his system. Then he executes
sf-ans, but instead of completing the connection back to me, it finds my
side busy, and I dutifully return the file "busy.au" to him, which he
hears. Any further attempts by either of us to send anything else results
in connections being refused.

Any ideas will be very much appreciated.

Chuck

 My web site is http://www.mhonline.net/~chuckh 
The Moon is Waxing Gibbous (97% of Full)

^ permalink raw reply	[flat|nested] 7+ messages in thread