Institution: University College London
Principal Investigators: Dr Martina Angela Sasse and Prof. Peter Kirstein
Tel: 0171-380-7286, Fax: 0171-387-1397, e-mail: email@example.com
Title: SHRink-wrapping Internet Multicast Packages (SHRIMP)
12 August 1997
This proposal is for a five months project to provide a shrink-wrapped set of programmes to support multicast, multimedia conferencing over the Internet. During the first month we will survey the field of available software, and recommend a set of programmes for Audio, Video, Shared Editing and Shared Drawing which should be shrink-wrapped for use under UNIX and Microsoft Environments. After agreement with the UKERNA Project Officer, we will shrink-wrap the selected individual tools with installation scripts and user documentation for Windows’95, NT, LINUX and Sun Workstations running Solaris. We cannot guarantee that shrink-wrapped versions will run on other UNIX platforms, but the tools themselves will be known to run on other UNIX platforms. In addition, we will package a set of audio, video and shared workspace tools into a simple-to-use conferencing package for up to 4 or up to 8 video streams for PCs and Suns. The package is aimed at novice users, it will be straightforward to install and accompanied by an introductory user guide and pared-down documentation.
Although the total project is envisaged to extend over five months, near-final versions of the package and the documentation will be provided after 15 weeks. The further extension is to allow for Review by UKERNA, the Christmas vacations and subsequent amendment by UCL.
The JANET Videoconferencing Strategy, as approved by the ACN and JISC , recognises that there is a need to provide IP-based videoconferencing packaging improvements to provide user friendly, easily installable, well documented software to end users. This activity is a prerequisite to Piloting activities to understand potential issues which will be encountered in running a large scale IP videoconferencing service with emphasis on network congestion and user perception of the service.
This proposal is a response to the resulting call . The Call recognises that there are a number of IP-based videoconferencing software tools in the "public domain". At the same time, for these tools to gain widespread acceptance, they need to be packaged to a standard that is acceptable to the non-expert user - i.e. the tools need to be "shrink-wrapped". A shrink-wrapped tool set is required for use as the basis of a stable platform for the IP videoconferencing piloting activities as outlined above. This project aims to address this need by providing packaged software solutions.
The funding available for this project is not sufficient to make major improvements in any of the individual tools. In fact, it would be uneconomic to bid for his project unless the bidder needed the tools for reasons of his own. The Call envisages a very short time scale for the effort; it would be impractical to bid unless the bidder had excellent knowledge of at least some of the tools and already had experienced people in place to do the work. The Multimedia Group in the Department of Computer Science, University College London is one of the few UK groups in a position to make a credible response because of their previous involvement in the MICE National Support Centre  and ReLaTe  projects, and their current Direction of the MERCI project . Moreover they need the tools in a packaged way, because of their proposed lead of the MECCANO project  from the beginning of 1998.
The aims of the SHRIMP project are exactly those stated in the call, i.e.:
There are a number of possible families of tools which could be used. The most common set is based on the ITU-T T.120 protocol suite . There are variants of this proposed for use over the Internet; for this purpose the H.320 transport protocol has been modified to H.323 , and tools are expected shortly. This protocol suite will not be considered in this project - mainly because very few products exist for use over the Internet, and we do not think that these were meant by the Call.
Another commonly used tool is CU-SeeMe . This is already commercially distributed in the US; its facilities are too limited to be of use to the UK academic communicty. It will therefore not be considered in this proposal.
We will consider only the multi-media tools in widespread use over the Mbone. We have extensive experience of these tools, think those were the ones meant in the Call, and will address these exclusively. Here we must consider separately the audio, video and shared workspace aspects. There are many variants, and we discuss these below. If others are suggested or encountered during the short period of this study - i.e. during the first three weeks of September, they will be considered if possible. It is possible to consider only those tools which are demonstrated to be available by September 1, 1997.
With the limited time and effort available, we can consider only tools which either run already on both Microsoft PCs and UNIX systems, which we have a strong reason to believe are easily ported from one to the other with negligible effort; if a tool operates only on one of those two platforms, it can be considered only if it is inter-operable with another tool of similar functionality on the other platform. For brevity we use the words "on PCs" where we really means "on PCs under Microsoft Operating Systems"; where we mean a PC UNIX variant like LINUX or FreeBSD, we say so explicitly.
The main criteria we will adopt in the tools we are considering are the following: functionality, stability, relative absence of bugs, support on broad ranges of platforms, availability of interfaces to allow either simpler use or the addition of a further interface to be superposed, feasibility of deployment without excessive cost, availability of technical feedback to repair deficiencies or bugs.
Although we have mentioned a number of possible versions of each system, we believe that only VIC, RAT, NTE and SDR will meet all the conditions. It is possible that WB on UNIX systems and WBD on PCs, or even WBD on both, could meet most of the criteria as well; however WBD has only just been released and there is still little experience of it. Nevertheless, we would verify during the evaluation phase whether we felt any of the other systems were possible candidates for shrink-wrapping.
As part of the packaging, we will undertake the following tasks
Note that whilst we expect to document bugs in the tools, we will not be able to do extensive bug fixing on the tools themselves within the short timescale of this project. The expected willingness to obtain bug fixes will be one of our criteria in the choice of tools. The user interface will be written in Tcl/Tk.
The documentation must cover of a number of different areas:
We expect not only to provide the separate documents, but also to present them as an integrated set of web-based documents. This has already been done successfully in a web-based tutorial for SDR and RAT.
We plan to do testing at several parts of the project. During the first month, there will be extensive testing of all the packages mentioned Section 2.3.1 which pass our initial screening on other grounds. During this period we will discover specific problems in the tools which we will use in the packaging phase of have Section 2.3.2. We will either try to fix these, work round them, or ask the tool providers to assist.
Clearly the implementers will do a considerable amount of testing. When they declare the systems finished, we will pass them to the team from the earlier MICE National Support Centre. These will perform three types of testing: installation, stability and verification of the main functionality.
Eventually, we will pass them to some more naïve users either in the context of the ReLaTe trials, or in that of normal MERCI/MECCANO videoconferences. It is doubtful, however, whether the tight UKERNA time-scales will allow this stage of testing to have been reached by the time that the tools have to be passed to UKERNA. However we hope that UKERNA will nominate guinea pig users, who can do this testing outside the normal contract. The testing will cover all the phases of the packages: installation, session initiation and operation.
The Deliverables are outlined in Section 4. Assuming that the project starts on September 1, it is intended to complete D1 by the end of September.
A version of D2 for each platform is expected to be completed by the end of November. However, we expect to make improvements as a result of both internal testing and of the expected feedback from outside users throughout December. In view of the disruption caused by Christmas vacation, we prefer to make a final Deliverable of D2 by January 15. We cannot yet say whether any specific components of D2 - for example the Solaris or LINUX versions - could be delivered earlier than the end of November.
First versions of D3 and D4 will be delivered by December 5. We expect to make modifications and improvements as a result both of internal comments and those of UKERNA, and would prefer to make a final Deliverable of D3 and D4 by January 31, 1998.
The above end dates assume that we are incorporating comments from the Project Manager by that end date. We could meet the dates stated in , but think that would impact the finished product. The College closes between December 19 and January 5, so to meet the deadlines we would have to have provided the accepted Deliverables by December 19. In view of the fact that the Editorial Board need comment on documentation only by December 19, we do not really understand how any of their comments could be included. These dates are open to negotiation; we fear that their retention will impact the quality of the Deliverables.
In the word "tools" we restrict ourselves to Mbone tools which allow interactive video, audio and shared workspace activity. Each written Deliverable will be provided in Paper, RTF, Postscript and HTML. Both the deliverables and the software will be made available on the UCL WWW Server and as a package that can be inserted onto the UKERNA WWW Server.
The following Deliverables are proposed:
By September 19 we should have decided which tools we recommend for packaging. By the end of that month, we should have completed D1, and got agreement on packaging specific tools.
By November 14, the packages should be ready for testing by our internal testing group - at least on one Microsoft and one UNIX environment. The completion of the transfer to the other two environments will be carried out in parallel with remedying faults found by the testing team. The packages should all be ready for delivery to UKERNA by the end of November - together with a draft of the relevant documentation.
A further cleaned up version of both the software and the documentation will be delivered by December 19 - but we still expect to make further modifications during January on the lines described in Section 3.
The project should be completed by the end of January, as long as this is acceptable to UKERNA.
The final product will be integrated sets of tools, each including video, audio, a shared Editor and hopefully a Shared Drawing tool, which run on PCs under LINUX, Windows’95 and Windows NT, and on Solaris workstations. It is probable that the same toolset will be used on each platform, but this depends partly on the outcome of D1; in any case the tools will be interoperable. There must still be some question on the Shared Drawing tool, since we have not yet tested any such system which operates on both PCs and UNIX systems - though we know several claimed to be available.
The package should be easy to install in each environment; sessions should be simple to start, and the tools should be easy to drive for the Standard purposes. There should be good documentation both for the knowledgeable and naïve user.