Re: (#371) Proposed Aim for the Speak Freely NG - proposals

Couple design ideas that could save us some headaches in the future:

The world goes in the direction of lots of small computers everywhere. Not
only the big, powerful PCs anymore, but also less-powerful MIPS and ARM
chipsets scattered throughout everything. The power and scalability of
embedded computers grows every day. (I should stop now, I start resembling
a marketing pamphlet.)

I propose to split the code into two parts: the core, and the user
interface. The core shall run as a separate process, communicating with
the user interface over a data pipe; a TCP or UDP connection, a Unix
socket, a named pipe, whatever will turn out to be the best. The core
shall be written to be small and easy to port between platforms.

The API then shall allow connecting of more than one user-interface
client at once. (Reason: You need eg. push-to-talk? Write a minimalistic
client which connects to the core together with the main GUI client and
just sends the start-stop message.)

Then there can be a set of separate and independent user-interface
projects. A barebones commandline one, a console ncurses-based interface,
a wxWindows GUI-based one, a browser-controlled one, a Java applet. And a
set of tiny single-purpose user-interface projects: one sending talk
start-stop messages when CapsLock or right-shift or F12 or any other
suitable key is pressed, another sending the same message depending on a
button on a serial or USB port. This way we can avoid splitting the
project development because of a relatively insignificant feature someone
insists on.

In a typical PC setting, the core and the UI will run on the same machine,
communicating over a socket, named pipe, or TCP. No practical difference
against the current appearance. Both the UI and core can be launched
simultaneously by a wrapper program.

However, this architecture permits more advanced setups too; eg, a LAN
phone implementation is made easy. Get a cheap MIPS board, run eg. ucLinux
or Midori Linux on it, run the SpeakFreelyNG core there. Run also a simple
user interface there, controlled over the keypad. Then optionally have a
fancy control software on the user's PC, connected over a TCP connection
to the phone, maintaining a phone directory, telling the user who calls,
serving as an answering machine, anything and everything you can imagine.
If the PC is off or broken, the LAN phone itself still works as usual, as
the second UI doesn't make the device to be dependent on it. If one of the
UI programs crash, the connection stays on; the program gets restarted and
reattaches to the core.

Another example where this architecture may prove useful is in the
combination of a PC (or a dedicated embedded computer), a wireless PDA,
and a BlueTooth handsfree unit. The handsfree unit is connected to the
computer, and serves as a wireless speaker/mike. The PDA runs a simple
client that's connected to the computer as well (by IrDA, BlueTooth, or
any other suitable way) and controls the SpeakFreelyNG core.

The lightweight core allows us a relatively easy way towards
SpeakFreely-based secure portable phones (maybe later even cellphones).
The separated independent user interface allows us easy development of a
variety of different ways to control it without having to fork the
project. Just do a new project, being it a whole full-scale client or just
an add-on like a PTT.

This client-server approach is used in eg. a P2P client mlDonkey and its
control application mlDonkeyWatch. I saw an implementation where the
client reliably runs on a Linux server on a fast connection, where the
control app connects to it from a Windows PC on a modem.

----

There is a consideration for the core/UI communication protocol - a
backward and forward compatibility. We should consider the possibility of
different versions of UI and core talking with each other; we may get
inspired by the approach of HTML, where unknown tags just get ignored. We
may also implement a way for the commands to specify how the recipient
should handle it when it is unknown - if it should make an error message
for the user, transparently ignore it, or return a complaint to the caller
process.

The core/UI protocol should in the future allow a request for relaying the
decrypted received voice data to the UI process. This will open a way to
easy-to-implement DTMF decoders and the mentioned answering machines,
without increasing the complexity of the core nor the mainstream-project
user interface, not hampering reliability; if a badly written UI client
crashes, the other clients and the core aren't affected.

----

Another consideration, this time for the SF protocol itself, is to define
a magic number for the beginning of the UDP packet that would specify that
the packet is not meant to be interpreted as voice data but that it
carries other information. This can be client-specific, and the default
way to handle such packets shall be just silently dropping them. This
opens the way for various kinds of in-band signalling. A thing to consider
is to check for the magic number AFTER decrypting the packet (if
encryption is used), which protects the signalling information against
eavesdropping. Another thing to consider here is to place the magic number
to the offset of (say) 8 bytes from the beginning of the packet and set
the first 8 bytes to random value, which may partially protect us against
the known-plaintext attack. There may be a secondary magic number
following the primary one, or maybe a short text string, describing what
the non-voice packet is for.

The SFng core doesn't have to care about the content non-voice packets; in
the first versions it may just silently drop everything with the magic
number. Later it may receive a table of handled non-voice packet types
from each user-interface programs, relay the payload of the received
packets of the given type to all the connected user interfaces which
registered that type for themselves, and receive payloads from the UI
clients and send them to the other side. This may also eliminate the need
of the 2075 port connection, putting the status messages into the main
connection stream.

This has a million of potential applications, from an in-band key exchange
to encrypted chat to various talk control protocols for group chats to a
way to remotely control a phone or a device connected to the phone (eg.
for a listening part of a home security system, or for controlling a
transceiver). Write a UI program that receives commands from the SFng core
and sets parallel port pins to the required values, assign it a secondary
magic number, connect a transceiver's Talk button to one of the pins,
write a corresponding simple UI program for the other side (or make a
slight modification to eg. a PTT one), problem solved.

----

Yet another thing to consider, for the core, is the chance of mixing
together the data streams coming in from different addresses, instead of
playing the packets in alternate order, which results in chopped speech.
But that's just a side idea, and according to one earlier post here was
already done...

----

Sorry for being wordy.


                      * * *

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