Speak Freely Next Generation (SFng) Desiderata

Since people are beginning to discuss what a successor to Speak
Freely might look like, I thought I'd share some notes I scribbled
down on that topic several months ago while thinking about "whither
Speak Freely".  I've transcribed my handwritten notes below, rewording
things and adding references in the hope of making them comprehensible
to others.  Obviously, I'm in no position to define a successor project.
This is simply a list of the things I planned to do if I *had*
decided to carry on with Speak Freely.

				  * * *


     	    	   Speak Freely Next Generation (SFng)
		    	        Desiderata
				
		       by John Walker  --  April 2003
			
     1.  SFNg should be written in C++ using the Literate Programming
         (http://www.literateprogramming.com/) methodology.  C++ strings
	and STL will be used throughout to improve robustness.
	
     2.  Audio input and output will be structured as a pipeline architecture
         consisting of C++ pipeline components as used in my ETset program
	(http://www.fourmilab.ch/etexts/etset/etset.pdf).  The control
	logic will assemble a pipeline containing the appropriate
	encryption, compression, and audio processing components as
	required.
	
     3.  The canonical form for audio within the program will be 44.1 kHz
     	16-bit stereo PCM (CD audio standard).  This will provide for high
	fidelity on emerging broadband links, and is trivially easy to
	interconvert with the existing canonical form of 8 kHz µlaw.

     4.  The preferred network protocol will be RTP (RFCs
	1889/1890 et seq.-- http://www.ietf.org/rfc/rfc1889.txt).
	RTP is defined by an IETF RFC, contains support for
	mixers, reflectors, bandwidth allocation, and defines
	formats for transmitting video as well as audio.  Any
	requirements of SFng not presently specified as RTP
	payload types (CELP, AES encryption, etc.) should be
	submitted as RFCs.

     5.  When communicating with another SFng user, RTP will be used
	exclusively, but the existing Speak Freely protocol will be
	supported for reception and transmission to users of earlier
	releases and when, for example, broadcasting to an unknown
	audience.
	
     6.  Audio CODECs will be based on the existing C code, cleaned up
     	where appropriate, and wrapped with C++ to become pipeline
	components as mentioned in (2) above.  Local storage required
	by the CODECs (their "context buffers") should be moved into
	C++ instance variables where appropriate.
	
     7.  Ideally, SFng should not need to do encryption at all.  In a
     	perfect world, everybody would use opportunistic encryption
	with IPsec, as is currently available with FreeS/WAN
	(http://www.freeswan.org/), which all traffic between two
	users, not just audio, would benefit from.  But we do not
	inhabit a perfect world, so SFng will doubtless carry forward
	its own encryption, if only for the need to be compatible with
	RTP (which specifies DES encryption in the base standard)
	and existing copies of Speak Freely.  SFng should, wherever
	possible, use widely-available Open Source packages such
	as SSLeay for encryption rather than its own code.  (When
	Speak Freely was originally written, I wanted to avoid
	"contaminating" it with GPL code; I see no need to burden SFng
	with this constraint.)  All encryption code, like CODECs, will
	be wrapped with C++ to function as pipeline components.
	
     8.  SFng will be structured as a "headless" library with a documented
	API.  The complete headless SFng will a be C++ class
	which will permit multiple instantiations and be thread
	safe.  The actual application will supply audio input
	and output and network transport components to the
	library, and control it with API calls.  A minimalist
	command-line application will permit demonstration and
	testing on any POSIX-compatible platform with audio and
	network support.  Actual SFng user applications will bind
	the API to user interfaces written for the target platform
	(Tcl/Tk, Gnome, KDE, Windows, Macintosh, PalmOS, etc.)  The
	"two program" architecture of Unix Speak Freely, the source of
	innumerable difficulties over the years, will be pitched into
	the tree chipper.

     9.  The API should be usable by any program which wishes to provide
         audio (and eventually video) communication as part of its services
         (for example, multi-player games).  The headless module and API
         should be able to be built into a Perl module, and similarly embedded
         in higher level scripting languages.  The API should "expose" lower
	level services such as compression and encryption pipeline components,
	not just the high level connection-oriented facilities.
	
     10. Compared to the work involved in restructuring the main application
     	code and building modern user interfaces to the SFng headless
	library, the cost of carrying forward legacy CODECs and encryption
	modes is next to nil.  Still, it's nice to take the trash out
	every decade or so.  Here are some candidates for deprecation or
	outright discontinuation in SFng:
	
     	    A)  Key file encryption.  It's dumb, insecure, and nobody
	    	uses it.
	    B)  IDEA encryption.  It's subject to a patent, which requires
	    	all kinds of weasel words and disclaimers.  Blowfish is
		just as secure and not so constrained, and AES is far more
		secure, unconstrained, and a United States federal standard.
	    C)  LPC10 compression.  This makes sense only for the tiny minority
	    	of users who both have slow machines (< 400 Mhz) and Internet
		connections too slow for GSM (< 28 Kb/s).  It sounds awful,
		and requires careful gain setting.  For anybody with a fast machine,
		CELP is the way to go if bandwidth is limited.  LPC compression
		should be ditched as well, but RTP compliance requires it.
	    D)  Show your face.  This is a total kludge.  I'm not saying such a
	    	feature doesn't belong in SFng, but it should be done in a much
		cleaner way, ideally transferring the face image over the control
		port, not the data port.
	    E)  PGP/GPG session key negotiation.  This was a kludge introduced to
	    	wiggle around all of the constraints of the RSA patent.  That
		patent has now expired.  SFng should incorporate its own
		Diffie-Hellman key exchange (perhaps being able to share
		SSH or PGP keys).
		
     Candidates for Redesign
     -----------------------

     1.  LWL notification.  Using a TCP connection to send the heartbeat to
     	an LWL server causes all kinds of problems, especially on Windows.
	Replacing this with a UDP heartbeat makes a lot of sense.  Note that
	the LWL daemon could listen for both TCP and UDP heartbeats which
	would make the transition painless.
	
     2.  Single port operation.  Given the difficulties imposed by NAT, there
     	may be advantages to restructuring the program so it transfers
	all data on a single port, as opposed to the port pair, plus LWL
	port currently used.  This structure was inherited from the RTP standard;
	there's no reason a single port couldn't be used, and it would actually
	simplify the program.  The major problem with this is that use of a single
	port would break RTP compatibility.

     3.  Audio quality negotiation.  Once SFng works internally in 44.1 stereo,
     	when a connection is established, the two parties, having individually
	specified the highest quality audio they can send and receive over
	their individual Internet connections, would automatically select the
	highest quality usable by both.


                      * * *

To unsubscribe from this mailing list, send E-mail containing
the word "unsubscribe" in the message body (*not* as the
Subject) to [email protected]