(#371) Proposed Aim for the Speak Freely NG

Message posted to the Speak Freely Forum
  by Anshuman Ag.... on Mon, 11 Aug 2003 02:51:42 +0200 (MEST).
  http://www.fourmilab.ch/wb/speak-freely.pl?rev=371

Hi all,
Here is what I am personally looking towards achieving from this project. I
believe that the internet users should be empowered to be able to operate in a
peer to peer fashion for internet tele/video phony. Speak-Freely is an
application which does the tele part very well at the moment and crosses the
unix-window bridge fairly well. I reject the commercial solutions which either
are not cross platform enough or use a server -client approach.
On these lines based on my last post ...since a complete rewrite of the code
base is needed, based on that here is the proposal:-
- Speak Freely should be as it right now a complete tool for end to end point
to point user communication developed with the GUI in mind ( not just an addon
which never appears complete ) - wxWindows toolkit for instance
- Modular and reusability of other code libraries..I have seen some good yet
lacking RTP/Speech compression code bases..we should use those libraries (
enhance them with speak freely code ) and incorporate them as needed.
By making it modular enough we can plug in video, interoperability with SIP
etc.
- well designed and documented API so that the backend can be tapped into by
other produts (IM client etc. etc. )
- Aim at merging the myriad projects for internet telephony out
there...picking up the good ( code and developers from all )
- Base it on a solid design and architecture as scalable as we can think of
today ( Pipeline , object oriented scalable code in C++ for instance )

This is my take on the project...I realize everybody has different
expectations..personally I'd like this project to be a common goal so that we
are all are working at different pieces of it instead of replicating work
towards different ones.

Cheers
Anshuman

Anshuman Aggarwal] I believe the most critical part of the application will be
the initial design/structure/architecture...Once the RTP handling, connection
managing, authentication/encryption framework is in place.
An overlying Kernel class could co-ordinate the use of resources
> > - Based on a cross platform GUI/utilities library: wxWindows (Open
>source,
> > available on all platforms, provides native GUI+TCP/IP). Adv.:
> > Immediate
>GUI
> > for all unix platforms.
>
>I don't have any personal experience with wxWindows, but I've heard
>good things about it. But I think the most important thing is to
>create a kernel and API, completely independent of the user interface,
>which does all of the real work (connection management, CODEC
>interface, encryption [if that's left in--see below]) which GUI
>packages call. The kernel could be supplied with a minimialist
>command-prompt user interface that would allows anybody to get it
>running on a new platform easily, then build whatever GUI they wished
>(Macintosh, Tcl/TK, Gnome, etc.).

[Anshuman Aggarwal] Here is an initial concept
Connection Authentication Encryption Compression I/O Class heirarchy:-
- Kernel contains ref. To multiple Link objects..each Link object has multiple
connection, authentication,encryption object ref. The compression ref. can be
further
> > - OO Design in C++. Adv: Easy scalability to new codecs (just derive
>classes )
>
>Yes. Each CODEC should be an object one patches into the pipeline
>which transforms audio in canonical form (which we might take the
>opportunity to extend to 44.1 kHz linear PCM stereo for future growth
>potential--the transform to and from mu-law mono is just a table lookup
>and costs nothing) to the encoded form. All should have identical
>methods, so it would be easy to add new ones.
>
> > + Video Conf. as and when SF grows.
>
>A new Speak Freely should, in my opinion, adopt RTP as its native
>protocol. The existing Speak Freely protocol would be accepted and
>sent to any connection which used it, but when talking new version to
>new version, RTP should be the default. The advantage of RTP is that
>it *already* has RFC-specified formats for most of the video CODECs, so
>we'd simply be complying with a standard, not breaking new ground.
>
> > - Develop on existing code base for C code for compression etc.
>(Suitably
> > modified when needed) encapsulated inside the C++ classes (which can
> > be upgraded with time)
>
>Yes. I'd keep the C CODECs and wrap them with the pipeline components
>as mentioned above. As for encryption, basically Speak Freely doesn't
>have any business doing encryption at all. We'd be much better off
>either building with SSLEAY or relying on IPsec opportunistic
>encryption such as FreeS/Wan. Unfortunately, to remain compatible with
>the existing Speak Freely, some of the existing eccentric encryption
>modes will need to remain. These, again, can be pipeline components
>plugged in as required.
>
> > - Large following of SF (as seen on the mailing list) can offer help
> > to migrate code for sections and non developers for quickly ironing
> > out
>bugs ( Go
> > Auriemma! ).
>
>Don't be over-optimistic about this. Over 12 years of Speak Freely,
>the total number of people who have submitted 100 lines or more of
>usable code is less than five. I'm not being cynical, just providing a
>data point. When Speak Freely downloads exploded in 1996-1997 and the
>program got lots of coverage in the press (NASA even broadcast the air
>to ground audio feed with Speak Freely for a couple of shuttle
>missions), I thought it was a just a matter of time before dozens of
>developers volunteered to pitch in with the many tasks that needed
>doing. Didn't happen.
>
>------------- ------------
>John Walker | What did the mystic say
>[email protected] | to the hot-dog vendor?
> | Make me one with everything.
> | -- Laurence Kushner
>
>


                      * * *

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