Strawman Task List

From reSIProcate
Revision as of 18:19, 11 January 2005 by Rohan (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Strawman List of Tasks TODO

New Components to build a complete WiFi phone reference application

Proposed Environment

Linux 2.4 (Familiar 0.8) on HP iPaq 5550 and Linux 2.6 (Fedora Core 3) on laptop w/Atheros a/g card. IPv4 and IPv6.

Layer 2

Task 1: Add :Basic ACE: to Linux drivers. Also add support for the Intersil chipset to WPA on Linux project. (Target platform is Linux laptop and Linux on iPaq). Try to get code checked into mainline: 3 months


Task 2: Add RTCP to the link titlelibSRTP project. document and test as a complete RTP/RTCP/SRTP library using T.140 text over RTP. check back in: 6 weeks

Task 3: Write a TURN client and server implementation and add to the stund project. Test on IPv4 and IPv6: 2 months

Task 4: Write a media socket layer. For UDP operation it uses STUN or TURN as necessary to get an open socket. Expects STUN on the port initially and then detect an initial RTP packet and switches to RTP. Likewise it sends STUN packets initially and then switches over to RTP once the initial negotiation is done. For TCP operation can send RTP and RTCP over one or two TCP connections setup in either direction. It also has a connectivity manager which insures that empty RTP and RTCP packets are periodically sent to insure NAT and firewall traversal: 2 months **

Task 5: Implement the media graph framework with support for multiple speaker/mic sources and sinks, a very basic jitter buffer, T.140 and G.711u with no echo or silence suppression. Write developer documentation for the API. This framework should support zero-copies for an ordinary media path. The framework also needs to support new filters (not provided) which are implemented in another processor (for example a DSP). 3 months (Before this task gets underway, I will check out the gnomemeeting media graph framework to see if it can be reused)

Task 6: Find and integrate (floating point) implementations of at least iLBC [RFC3951], GSM AMR, G.729a and G.711u/A; and preferably also G.726, G.722, G.723.1, mp3, ogg and Speex codecs; and integrate them into the media graph framework. See the OpenG729, OpenAMR, and MPEG4IP (mp3) projects hosted on; or ffmepg2(G.722); (G.726); (ogg vorbis and speex); and ITU reference designs (G.723.1). As many as can be implemented in 3 weeks

Task 7: Implement tone detection algorithm [to be provided] for AVT tones 0-9*#A-D, CNG, and all 4 baudot tones. Implement generic tone generation using tone scripts. Implement comfort noise using an adjustable volume which can be provided by another media filter. Time permitting implement simple tone generation from MIDI file: 1 month

Task 8: Implement a media mixing unit using a speaker selection algorithm which is to be provided. 6 weeks

Task 9: Integrate jitter buffer, AEC, PLC, and wideband iLBC codec extension modules from (expected) forthcoming contribution. Write additional documentation and test programs for integrated code. 1 month

Flow Manager

Task 10: Write an SDP parser and encoder compatible with draft-ietf-mmusic-sdp-new, with integral support for offer/answer preconditions and other specific standard extensions (see below) plus access to unknown attributes. Each m-line is represented as a flow. The library must support the SDP extensions described in the following documents: RFC3264, RFC3266, RFC3313, RFC 3388, RFC3524, RFC3605, RFC3890, draft-ietf-mmusic-anat, draft-ietf-mmusic-sdp-srcfilter, draft-ietf-mmusic-sdp-comedia, draft-ietf-mmusic-kmgmt-ext, draft-ietf-mmusic-sdescriptions, draft-ietf-mmusic-connection-precon, draft-ietf-mmusic-ice, and draft-ietf-mmusic-sdp-media-label. (This might look like a lot of extensions, but most are just single attributes. 1 month.

Task 11: The Flow Manager manages streams of media. The Flow Manager is responsible with setting up streams by fetching appropriate IP addresses and ports and binding the appropriate protocol to the port (ex: RTP, RTCP, MSRP, and raw TCP, TLS, and UDP), optionally through a media mux that handles the media portion of ICE (Interactive Connectivity Establishment). The Flow manager can also stop and restart sending or listening on a port, and delete flows entirely. The flow manager is also responsible for initially connecting the media graph in a sensible default fashion. 2 months.

SIP Stack

Task 12: Add IPv6 support for ares library in resiprocate/contrib/ares. Repackage for distribution as separate library (ares2) provided via sourceforge. 2 weeks

Task 13: Make resiprocate stack much smaller for use on embedded systems - Make resiprocate stack C linkable (add static initializers); remove RTTI; add compilation option for Data class to use only heap or stack memory. Make STL containers space efficient. Refactor to remove gratuitous template use (isolate template use to a handful of classes): 2 months

Task 14: Add SIP GRUU extension, SIP connection reuse, and outbound connection management to resiprocate stack. 6 weeks

Task 15: Write developer tutorial for the resiprocate dialog usage manager (DUM). 2 weeks

Task 16: Write Conversation Manager. Uses the DUM and Flow Managers to setup conversations (2-way calls, conferences, and sessions with locally generated or relayed media). API should offer functionality such as attempt party, add party, reject call, answer call, split party from conference, and complete a transfer. Proposed API to be provided. Write developer tutorial. 4 months

Configuration Profile Manager

Task 17: Build a simple configuration server, which maintains subscriptions to the config package using the resiprocate dialog usage manager. Whenever a SIGHUP signal is sent to the configuration server process, it compares the current contents of the target directory with the contents at the last SIGHUP (using a SHA-1 hash on each file). If any files have changed, the appropriate subscribers are notified. The files can be local or remote (via http/webdav). Write test client (using DUM) which subscribes to the config package and then fetches changed files from multiple sources as they become available using neon (HTTP library) or cadaver (command line utility) to keep a cached copy. The client should support merging client data from multiple sources (device, user, domain, app) using a conflict resolution algorithm to be provided. Should also provide a client wrapper to write and delete configuration to the server using cadaver or an equivalent using neon. No configuration UI is needed. 1 month

Phone Application

Task 18: Write a phone application with GUI using Swing or QT. The GUI should include dialing by number, URI, or from a directory. The directory should be fetched with the configuration data fetched at started and kept fresh using the config package. The phone app should contain a configurable dial plan (to transform digit strings to SIP URIs, possibly in different domains). The phone application should be able to support multiple independent, simultaneous calls, and switch between them, join them, split them ,etc using an intuitive interface. For the iPaq, the interface should minimize the number of buttons dedicated to specific features and focus on quick and predictable access to the most common features without looking at the display, or with minimal attention. For example, Nokia cell phones are considered very easy to use because the most likely feature during a call is accessible by pressing the context sensitive key in the top center of the keypad. This task would proably involve coordination of 2 or 3 short usability tests, and a weekend-long design and coding session with other core contributors to the DUM and the Flow Manager. 3-5 months