faq.htm

g729 coding ipaddressing

code should be usable with little or no modification.  The bulk
of the work would be in the user interface, network driver, and
audio input/output which, due to great differences between
Windows and the Macintosh, would have to be essentially
rewritten.  If you're interested in making a Mac version of
<i>Speak Freely</i>, please get in touch (via the <i>Speak
Freely</i> <a href="maillist.htm">mailing list</a>) so you can
see if anybody else is already working on such a project.

<p>

<dt><b>I don't get it.  I've installed <i>Speak Freely</i> and
it runs OK, but nothing happens when I connect  to the IRC
server.  What gives?</b>
<dd><i>Speak Freely</i> is a <I>telephone</I>, not a party-line
chat program like IRC.  You run a copy on your machine, the
other person runs a copy on theirs, and then you talk to one
another person-to-person--there's no server in the loop nor any
need for one.  Somebody could certainly <I>make</I> a voice
chat program, but this isn't it.  If your network supports <A
HREF="multicasting.htm">multicasting</A>, you can use that
facility to organise conference groups individuals can join and
leave at will.  The <A
HREF="lwl_ask.htm">Phonebook/Search...</A> menu item permits
you to access a Look Who's Listening server to locate other
people running <i>Speak Freely</i>.

<p>

<dt><b>Can <i>Speak Freely</i> talk to <em>other network voice program</em>?</b>
<dd>Yes, as long as the program supports either Internet
Real-Time Protocol (RTP) or the protocol used by the Lawrence
Berkeley Laboratory's Visual Audio Tool (VAT). <i>Speak
Freely</i> automatically detects which protocol a program is
sending and displays the protocol in the connection window. 
When transmitting to a user running an RTP or VAT compatible
program, be sure to set <A
HREF="protocol.htm">Options/Protocol</A> to the protocol that
program requires.  Many commercial Internet voice programs use
proprietary protocols to guarantee users can only talk to
others with the same program.  Until the vendors of these
products adopt RTP as a means of communicating with other voice
applications, it will not be possible to communicate with users
of such products.

<p>

<dt><b>How can I make sure <i>Speak Freely</i> is always running on my machine?</b>
<dd>Put a shortcut to <i>Speak Freely</i> in your Startup
folder (or whatever it's called if you're running a
non-English edition of Windows).  You'll probably want to check the
Options/<A HREF="winmodes.htm">Window Display Modes</a>/Start Minimized menu item
so <i>Speak Freely</i> starts as an icon.  If you check the
Use Notification ("System Tray") Icon and Hide When Minimized items
as well, <i>Speak Freely</i> will lurk as a small icon to
the right of the taskbar until you activate it by clicking the
icon.
If you also check
the Open on New Connection item in this
menu, the <i>Speak Freely</i> window will automatically pop
open whenever a remote machine connects to yours.  If
you'd like to automatically establish one or more ready-to-use
connections, specify the names of the <A
HREF="saveconnection.htm">connection files</A> describing them
on the <A HREF="commandline.htm">command line</A> of the shortcut, separated by
spaces.

<p>

<dt><b>Help!  I'm trapped behind a firewall and can't
talk to people at other Internet sites.  What can I do?</b>
<dd>Little or nothing, unfortunately.  <i>Speak Freely</i>
communicates using Internet UDP protocol on non-privileged
ports 2074 through 2075 and TCP protocol on port 2076 (the
latter only if you're using a Look Who's Listening server).  Most firewalls block all
non-privileged (and hence unknown) port number packets, since
there's no way to know they aren't being used by a mole or a
Trojan Horse application to transmit sensitive data to a remote
site.  <i>Speak Freely</i> uses a nonprivileged port precisely
to avoid the need for involving your system administrator in
installing the program, but if you're behind a firewall you
have no alternative.  If you can persuade your jovial sysadmin
to allow packets on ports 2074 through 2076 to pass both
directions through the firewall, you'll be all set, but the
odds of this are extremely slim--I certainly wouldn't permit it
were I your site manager.  Once there's a known port out of
your system, any program, not just <i>Speak Freely</i>, can
transmit anything it likes accessible on your system to any
other host on the Internet; if you permit that, why have a
firewall in the first place?  Basically, you'll just have to
wait until the demand for network voice conferencing becomes
strong enough at your site that your administrator installs a
secure proxy tool to create a bridge across the firewall that
<i>Speak Freely</i> can cross. In the short term, there's
nothing you or I can do to get across the firewall.  If you do
decide to create a bridge across your firewall for network
voice, you should probably also allow packets on ports 5004 and
5005 to pass--this is the standard port pair for <A
HREF="protocol.htm">RTP protocol</A>.

<p>

<dt><b>Aren't you going to wreck the Internet by
clogging it with all this sound traffic?</b>
<dd>This is a legitimate concern in regard to <I>video</I>
conferencing programs, but not with a voice-only tool like
<i>Speak Freely</i>.  With GSM compression, real-time audio
requires a bandwidth of just 1650 bytes per second.  This is
far less than a typical FTP session, and people regularly make
multi-megabyte FTP archives available without fear of clogging
the Internet.  A user accessing one of the many graphics-rich
World-Wide Web sites can easily consume more Internet bandwidth
than <i>Speak Freely</i>.  In addition, the load created by
real-time audio is inherently self-limiting.  As a network link
approaches saturation, the consistency of packet delivery time
becomes dramatically worse, while non-real-time applications
such as FTP and Web transfers simply begin to smoothly slow
down.  Long before the links between two sites reach their
bandwidth limit, the audio users will have given up in
frustration with break-ups and lost sound, to try again,
perhaps, when the network is less busy.

<p>

<dt><b>Why do <a href="face.htm">face images</a> go all weird when more than
one person is connected at once?</b>
<dd>This occurs when your system has a 256 colour display
board, and each face has its own set of 256 colours.  The
active connection will be displayed with the correct colours
but other connections must use a default colour table.  If you
upgrade your display adaptor to full-colour, multiple face
images will display correctly.

<p>
<dt><b>How secure is the encryption?</b>
<dd>I've used the best algorithms I know of and applied them in
the best ways I could given the constraints of real-time audio,
fallible communication networks, and the computing power of
contemporary personal computers.  But I'm not a professional
cryptographer or cryptanalyst and even if I were, you shouldn't
believe something is secure just because the author claims it
to be.  One of the reasons I'm releasing complete source code
for <i>Speak Freely</i> is to permit independent evaluation of
the implementation and application of encryption within the
program by experts in the community.  With time, a consensus
will emerge as to the degree of security <i>Speak Freely</i>
provides and how to remedy any perceived weaknesses in future
releases.  <A HREF="encryptotp.htm">Key file encryption</A> is
very insecure, but I already warned you about that; it's
intended purely as a last-ditch alternative for users with
computers too slow to run any of the other forms of encryption,
yet who prefer any protection, however weak, to transmitting
entirely in the clear.

<p>

<dt><b>Why do you use datagram protocol with no end-to-end acknowledgment that would
permit detecting and correcting errors?</b>
<dd>Network transmission delays rule out end-to-end
acknowledgment.  Audio has to be delivered in real time to be
intelligible.  Waiting for an ack from the other end would, in
many cases, require delaying up to a second before sending the
next packet.  The best we can do is blindly spray packets at
the other end in the hope enough will arrive with sufficiently
consistent delivery time to be intelligible.  Over slow links
to distant sites, several packets will be flowing through the
network toward the destination at a given time.  Providing
connections with guaranteed bandwidth and consistent delivery
time is one of the main challenges in extending the Internet to
accommodate real time audio and video communication.

<p>
<dt><b>I run the Windows debug kernel and I get <i>whatever </i>messages when I
do...</b>
<dd>I've sweated blood to try to make this thing debug kernel
clean, and as of this writing, with <A
HREF="hardduplex.htm">half-duplex</A> audio hardware,
attempting to open input while output is open causes several
"GlobalReAlloc failed" and "LocalAlloc failed" messages from
the Kernel, which it presumably handles correctly since no
apparent harm is done.  But, as a battle-weary Windows warrior,
I have no illusions that I've "found the last one".  If you see
warnings or errors unrelated to half-duplex output to input
transitions, please announce them to the <i>Speak Freely</i>
mailing list and provide as much information as you can about
precisely what you were doing, what message(s) you got, whether
you could reproduce the problem, and which sound card, network
interface, and network (WINSOCK) software you're using.  Thanks
in advance.

</dl>

</BODY>
</HTML>