Fourth Framework Programme of European Community activities
in the field of Research and Technological Development
"Telematics Applications Programme"
Sector: Research
ANNUAL PROJECT REVIEW REPORT
Project Number RE1007 Project Acronym MERCI
Project title Multimedia European Research Conferencing Integration
Project Manager
Name Roy Bennett
Department Computer Science
Organisation University College London
Address Gower Street, London WC1E 6BT
Country-Code City GB London
Telephone +44 (0)171 380 7934
Fax +44 (0)171 387 1397
E-mail R.Bennett@cs.ucl.ac.uk
List of Partners
Organisation Role Country
University College London C1 GB
GMD - Forschungszentrum Informationstechnik GmbH C DE
Institut National de Recherche en Informatique et Automatique C FR
Kungliga Tekniska Högskolan C SE
University of Oslo C NO
Rechenzentrum U Stuttgart C DE
TELES C DE
Date: 20 September 1996
Project Self assessment - Form SA Project No: RE 1007
Project title: Multimedia European Research Conferencing Integration
Work-programme (15 December 1994) task: R 2.1 Real-time interactive multimedia collaboration
A. Assessment of work done during the reporting period.
We have made excellent progress on the project. This has been achieved through active co-operation both within the project and with our associated User projects and sponsors. We have kept close to our budgets in both person months and KECU and have achieved the goals which we set ourselves within the 8 months that the project has been operating up to the review date of July 31.
We have developed new features and new functionality to extend and to improve the tools from the MICE project. These improvements are in more robust and better quality coding, new shared workspace tools, a better media server, and better session announcement and starting facilities. Many other improvements are under development, and will become available over the next six months.
We have continued to play a major role in the development of international standards in the field of multimedia conferencing, both within the Internet community (IETF) and within the ITU (ITU-T). This participation is helping to ensure that both the above improvements and the developments mentioned below are not limited to the MERCI participants, but will be reflected in the International standards.
We have made good progress in a major project goal of enabling both confidentiality for conferences and authentication of participants by our success in providing internationally available encryption for the MERCI tools. We have also produced our security architecture document, a deliverable due in month 9 of the project. The architecture implies a close alignment of the MERCI architecture with that of the IETF in the security area, and with the Public Key Infrastructure being piloted in the ICE-TEL project.
We have made a start on the difficult task of integrating the circuit-switched conferencing model of the ITU with the packet-switched model of the Internet - we have a strategy, we have defined the requirements and work has commenced on the first stage. This will result in a interworking implementation during the next few months.
Having established good relations with our associated project, MANICORAL, we have helped them to install and use the initial software with their end-users and have already received valuable feedback which will influence further developments of the MERCI tools. In addition, we have had feedback from users in our sponsoring partners, especially Shell Research for whom we are already developing an updated version of their particular user interface to incorporate the changes they have requested.
Although we are not primarily producing a product at this stage, we have made some advances towards the exploitation of the MERCI tools. At UiO an initiative is underway to commercialise conference room technology developed under the auspices of the project. We expect this to result in the establishment of a commercial company to market, supply and support conference rooms incorporating MERCI technology before the end of 1996. Hewlett-Packard are developing a demonstration set-up for possible implementation prior to exploitation.
We have had few problems within the project - we have made minor adjustments to the allocation of effort within workpackages and have reassigned certain responsibilities. We regret that we have not been able to include the Communications Research Centre of Industry Canada as a partner yet, but we will continue our efforts and anticipate success in the near future.
Project Manager Roy Bennett ........................................................ .................... Date: 20 September 1996
Form SA page 2 Project No: RE 1007
B. Current project status
As at (end of reporting Number Comments, problems with deadlines
date)
Activities on/before 27
target
Activities delayed 1 The surgical workshop in WP11,
planned for September, 1996 has
been postponed until February,
1997. This will not involve any
change of deadlines.
Deliverables submitted in 1 D0 Initial software deliverable
reporting period Restricted to project participants
Deliverables acknowledged 1
by DG XIII
Late deliverables - for 0
reporting period
C. Work done
Are project objectives Grade from 0 Comments
being met? (not at all) 4 All deliverables are on
to 4 track for delivery by due
(totally) dates.
Is work done within Yes Comments
the project budget?
Major achievements Secure versions of VIC, VAT, RAT and NTE have
within reporting been released
period Internet drafts were presented at the IETF
meetings in Dallas and Los Angeles on:
Simple Conference Control Protocol (SCCP)
Session Invitation Protocol (SIP)
Session Description Protocol (SDP)
Session Directory Announcement Protocol (SDAP)
RTP packet format for redundant encoding
proposed to the IETF's AV working group
Details of expected Type Comments
end-products (ref
.......)
Name
MERCI toolkit Software This toolkit, verified and
demonstrated by our users such as
MANICORAL, will form the basis for
the construction of interfaces
targeted to meet specific user
requirements. We already see the
need for these and have indicated
that they will be a post-MERCI
requirement.
D. Outline Changes to Future Plans
We anticipate the entry of the Communications Research Centre (CRC) of Industry Canada into the consortium as a self-funded member. A revised project plan will be prepared which will show the additional contribution CRC will make to the project. This will provide additional quality and depth to the deliverables without affecting either their number or their due dates. Further details of the proposed contribution of CRC to the project are given in section B.1.3 Dependencies and relationships below.
We no longer intend to support the tools on Apple MACs since the Apple Quick Time conferencing tools are now RTP compliant; they are, therefore compatible with the MERCI tools and can interwork with them for Video and Audio.
These have not changed since the proposal. Under MERCI we will do some work in most phases: Analysis of user requirements (Phase 1), Definition of functional phases (Phase 2), Building of a demonstrator (Phase 3), Validation - including some verification - Phase 4a, but not really Demonstration in the way used by the EU (Phase 4b).
The purpose of the MERCI project is to help in the development of the tools so that they are available to other applications; a major activity is to assess the real needs of projects which have stated that they want to use the tools, to see what they really need. Inside this project, we will move only to Phase 4a over the two years proposed - though we expect eventually to go to Phase 5 of exploitation! The reason for this is that we plan that our main Demonstrators will be other projects which capitalise on the facilities being developed in MERCI. However, to retain a clear assessment of the success of the technology, we have the three verification activities of WP11-WP13.
Hewlett-Packard are developing and trialling a demonstration set-up for possible implementation prior to exploitation.
At UiO an initiative is underway to commercialise conference room technology developed under the auspices of the MERCI project. It is anticipated that this will result in the establishment of a commercial company to market, supply and support conference rooms incorporating MERCI technology before the end of 1996.
Form SA page 3 Project No: RE 1007
F. Commission Services observations
(to be completed by the Project Officer)
Commission Project Officer ....................... Signed ........................... Date...........................
TELEMATICS APPLICATIONS Programme
Form A: OVERVIEW OF MERCI PROJECT
A.1 - Summary Information on the Project
Project Number Acronym - Title
RE 1007 MERCI : Multimedia European Research Conferencing
Integration
Lead sector Other sectors Project Duration
(Initials) in Months
Telematics for 24
Research
The objective of the project is to provide all the technology components, other than the data network itself, to allow proper deployment of the tools for multimedia collaboration in Europe. We will improve our tools over the earlier MICE tools, developed during 1992-95, in many important aspects: Better integration of the multimedia conferencing facilities to make them easier to use by untrained users; Better capability for higher quality video, audio and shared workspace facilities; Inter-operable cross-platform support for many systems - UNIX workstations and PCs Better support for the introduction and recording of multimedia information in conferences; Support for different network technologies - mainly over IP: packet-switched, ATM or SMDS and ISDN; Inter-operation between workstations running the multicast Internet and the normal ITU-T procedures; Facilities for secure conferencing - with easy distribution of keys and information; Distributed measurement, monitoring and control Verification activities will be pursued both inside the project and in other Telematics projects: Regular research seminars given from the sites of the partners - and from North America Annual interactive workshops in invasive surgery given at UCL - transmitted internationally, and with some operations coming from other countries; Industrial trials with commercial organisations including our sponsoring partners Hewlett-Packard & Shell Use in the research community, including by our sponsoring partner UKERNA and by other ACTS and Telematics projects including MANICORAL, ATHOC and ICE-TEL. Besides tools from earlier EU projects, it will utilise results from concurrent Telematics projects: Security tools from the ICE-TEL and Shared Visualisation tool from MANICORAL.
Institution/ City/Town Region 2 . Country 3 .
Organisations + Postal Code
UCL London WC1E 6BT UK55 GB
GMD Darmstadt 64202 DEA2 DE
INRIA Sophia Antipolis 06902 FR82 FR
KTH Stockholm 164 40 SE01 SE
UiO Oslo 0316 NO NO
RUS Stuttgart 70550 DE11 DE
TELES Berlin 10587 DE3 DE
Middlesex Hospital London W1P 6DB UK55 GB
Sahlgrenska University Gothenburg S-413 45 SE052 SE
Hospital
Hewlett-Packard Bristol BS12 6QZ UK61 GB
Hewlett-Packard Villefontaine 38090 FR71 FR
Shell Research Thornton CH2 4NX UK81 GB
Shell Research Amsterdam 1031CM NL32 NL
UKERNA Didcot OX11 0QS UK52 GB
Other Characteristics of the Project:
Users involved: Students and research workers - in the regular seminars, conferences and remote teaching; doctors and medical students - in the medical workshops; computer equipment users and technicians - in the training seminars; office users and researchers - in the industrial trials . Technologies and/or approach used: Packet technology; highly compressed audio, video and shared workspace; multimedia servers; security technology; distributed management and control; broad spectrum of network technologies: packet data, ISDN, ATM, & MAN - ITU-T and Internet procedures. Expected benefits for the citizen: It is expected that this technology will have a very broad impact. It will be broadly applicable in education, industrial research and medicine - which touch all of us. Expected benefits for the users of the application: We expect that the applications will set the tone for the use of audio/visual techniques and shared whiteboard in tele-teaching, remote consultation of doctors, and many other similar disciplines. Clearly several industrial organisations will investigate how there business can be helped by the technology. Expected benefits for the European Industries: There should be benefits from the User industries, in their improving their productivity by use of the techniques pioneered in MERCI; it is also vital that the supplier industry get a better feel for the impact of the technology on their products. Contribution to EU-policies: It is the policy of the EU in the communications part of their programme to pioneer the use of multimedia and of international standards; in the GII discussions, they are promoting international collaboration and co-operative working over high-speed networks. The MERCI concentration on standard hardware and software solutions for European-wide and international multimedia, collaborative working furthers both the EU dissemination policies, and their aim to further developments that should be profitable to exploit by European industry.
Co-ordinator:
Name of Institution/Organisation City Region1 Country 2
+ Postal Code
University College London London, WC1E UK 55 GB
6BT
Title, First Professor Peter Address: Gower St, London, WC1E 6BT, UK Name, Name Kirstein Tel: +44 171 380 7286 Fax: +44 171 387 1397 E-mail 1: E-mail 2: kirstein@cs.ucl.ac.uk
Participant Name of Institution/Organisation City Region1 Country 2
s Code3 + Postal Code
C 2 GMD - Forschungszentrum Darmstadt, DE 71 DE
Informationstechnik GmbH D-64204
C 3 Institut National de Recherche en Nice, 06902 FR 82 FR
Informatique et Automatique
C4 Kungliga Tekniska Högskolan Kista, 16440 SE 01 SE
C5 University of Oslo Oslo, N-0316 NO NO
C6 Rechenzentrum U Stuttgart Stuttgart, DE 11 DE
70174
C 7 TELES Berlin, 10587 DE 3 DE
Part A. Synopsis of Work Undertaken
This section should not normally exceed 30 pages in length and should draw the attention of the Annual Project Review to the key elements of the project. Supporting information should be included in annex.
How the work done has contributed to meeting the project objectives, whether the original objectives need refocusing etc., to what extent have overall project objectives been met.
Analysis of whether this year's objectives have been met.
Description of the main activities of the project in the reporting period. Give a brief description of the work undertaken within each of the work packages, with reference to the technical deliverables (list included in annex 4) where the methodology and results are described in more detail. The executive summaries of all Public and Programme level deliverables should be included in Annex 5.
Describe any impact of current or emerging standards on the project's work and the actual or likely contribution of the project on the work of standardisation bodies. Use of budget resources will be summarised in the annex 1, 2 and 3.
All project reports and deliverables have been submitted on time and within budget. The first cost claim, for the period to 31 May, was submitted on the 24 July, 1996.
Public and private web servers have been set up at UCL to provide a central repository of information and project management materials. The public server contains general information on the project and includes access to deliverables, project publications and publicity materials. The private server contains information for project management, including contact details, agendas, minutes, minuting rotas, and management reporting formats.
We have established an automated management reporting system which uses World-Wide Web forms linked to a text database. This allows individual partners and workpackage leaders to report independently and the resulting reports can be included in the regular quarterly Progress reports.
Work has begun on an automated system to allow the submission of project documents of all sorts to the WWW repository by authorised project members. This will provide for a more flexible use of the repository and will include a document search engine as part of the interface.
We have agreed to pursue the possible extension of the project by an association agreement with the Communication Research Centre (CRC) in Canada. Further discussions with CRC led to an official request to the Commission to allow CRC to become a MERCI partner and we are now in the process of submitting a revised Project Plan to the Commission.
Regular weekly conferences over the Mbone started on the 10 January 1996 and have included CRC as well as the formal partners. These conferences have been held bi-monthly since the beginning of May. This frequency will be reviewed at intervals and may be changed again to suit project requirements. The conferences are minuted with the minutes made available on the private WWW server. Project meetings have been held at UCL (Kick-off), INRIA, Sophia Antipolis and KTH, Stockholm.
The main thrust of our activity with external groups has been our co-operation with MANICORAL and with the MICE National Support Centres in Europe. We have also made initial contact with CoBrow partners at Lancaster University.
We have provided the tools and assistance to the project in setting up multimedia conferencing in support of their on-going project activities. We have received detailed feedback on the Initial software delivery which has been absorbed by the Workpackage 4 workers to help develop the deliverable User Feedback I (D4.1).
We have also provided some help to the project's technical partners in their ongoing work to define the new shared-workspace tool.
We have established direct relationships with the active National Support Centres for the testing and enhancement of the new features being developed on the MERCI tools, especially Session Announcement and Invitation (SDR), Shared Text Editing (NTE) and Robust Audio (RAT). In this regard we have been helped particularly by the UK centres.
The National Support Centres have also been approached to participate in the MERCI request to use the JAMES network and we have had positive responses from Austria, Italy and Portugal with further consideration being given to our proposal by Denmark and the Netherlands.
A meeting was held between the MERCI project members at UCL and members of the CoBrow project from the University of Lancaster. There was useful discussion of the work being done at Lancaster on digital filtering. This could lead to new techniques for integrating participants on low-bandwidth lines into MERCI conferences. We expect to have further and deeper contacts in the near future.
The ACTS project (AC037) ATHOC (ATM Applications over Hybrid Optical Fibre Coax) has been brought into being in order to "enable the wide introduction of broadband communication in short terms by usage of existing coaxial Cable TV infrastructure". They expect to use MERCI tools within the ATHOC project - a presentation has already been given to project participants.
Sun Microsystems co-operates with selected European university sites bringing technology centres under the name SunTREC (Sun Technology and Research Excellence Centre) into existence. SunTREC has the following targets:
RUS is actively involved in SunTREC Stuttgart providing the MERCI software tools. New users from this community are given assistance in introducing multimedia conferencing for their own needs.
MERCI project partners have been collaborating with TERENA and their working groups "Networked Multimedia Applications (WG-NMA)" and "Lower Layer Technologies (WG-LLT)", especially within the WG-LLT Task Force "Trans European Networking (TF-TEN)". This task force aims at evaluating advanced ATM technologies in the context of the TEN-34 project Network tests have already been done involving some MERCI sites and the ATM network provided by JAMES. These experiments, and the close co-operation with the national research networks and TEN-34, are very important for MERCI because they make sure that the evolving high-speed trans European networks are prepared and suited for networked multimedia conferencing and for the multicast technology.
We have continued liaison with the ICE-TEL project, since any secure conferencing must use the same infrastructure as is provided in ICE-TEL. The fact that GMD is the Co-ordinating partner in ICE-TEL, and that both GMD and UCL are the main players in security on MERCI, ensure that there is good compatibility and collaboration between these two projects.
Participation in, co-ordination with, and influencing of, the IETF are very important activities in the MERCI project. We regularly attend the multimedia conferencing and security sessions of the IETF. We co-chair the MMUSIC group on conference control, and are key members of the Audio Video Transport group. Through the MERCI activities, it is ensured that relevant European practices are fully compatible with the IETF ones - in fact in some areas, like conference control, conference invitation, and key distribution for conferencing, we largely set the standards. We are participating in the new initiative to standardise multimedia server interfaces. In the security area, GMD and UCL are particularly strongly involved both from the MERCI and ICE-TEL perspectives. We are collaborating to ensure that the facilities being provided under MERCI fit into the IETF framework - but also can be used with the ICE-TEL infrastructure. From all our work we want to be sure that the standards used in the MERCI project have a world-wide compatibility.
Through the IETF we retain also good collaboration with ISI and LBL - who are responsible for major US multimedia conferencing initiatives.
TELES has regularly attended the meetings the International Multimedia Teleconferencing Consortium ( IMTC) to participate in the discussion of the next version of the ITU-T Recommendations of the H.323 series of protocols. They also participated in discussions on extensions to T.125 (MCS) and T.124 (GCC) at the ITU SG 8 meeting in Boston.
The Web offers the opportunity to integrate sound and video with other media types (text, still images, etc.). This has generated increased interest in the integration of live audio and video applications (such as those developed in MERCI) into the Web. We have been holding regular discussions and meetings with the World Wide Web Consortium to examine these issues. This has proved fruitful, especially since the person in charge of "real time applications" in the Consortium is housed at INRIA. A workshop on "Real time multimedia and the Web" is being organised at INRIA to examine the relevant issues. To get full information, you may refer to the URL:
http://www.w3.org/pub/WWW/AudioVideo/RTMW96.html
The project was represented at the JENC7 Conference in Budapest, 13-16 May, by several of the partners. UCL and GMD were presenting papers project (see A.9 Dissemination activity and plans - Publications below). RUS attended the TERENA WG-LLT and WG-NMA meetings on 13 May.
UCL presented a paper to the Videoconferencing workshop organised by UKERNA at the University of Nottingham, 13/14 May 1996 (see A.9 Dissemination activity and plans - Publications below).
The objective of this workpackage is to provide high quality multimedia components to meet the conferencing needs of diverse users over a variety of platforms. Work has therefore focused, as indicated in the project plan, on improving the quality of the components, and on increasing the range of platforms on which they can be run.
The quality of the audio data delivered from a source to its intended destinations is one of the most important factors in the overall quality of a videoconference. UCL and INRIA have implemented mechanisms in their audio tools (RAT and FreePhone) to provide high quality audio, including
We have added high frequency sampling (up to CD quality sampling) and high resolution coding/decoding (16 bit vs. the current 8 bit coding) in our audio tools
We have continued work on rate and loss control. Rate control aims at matching the audio source rate to the capacity available in the network to minimise losses. Loss control aims at reconstructing lost packets at the destination using redundant information sent by the source. Subjective quality tests have shown that these mechanisms provide a huge increase in quality. Together with INRIA, UCL has developed a packet format for redundant audio encoding. This has been presented at the AVT working group during the Montreal IETF, for consideration as a proposed standard. This is available as Internet-draft draft-perkins-rtp-redundancy-01.{txt|ps}. This work ensures compatibility between RAT and FreePhone.
UCL has integrated encryption into the RAT audio tool. This has been shown to be compatible with the LBL audio tool, VAT. The production version, which is being released in September, will include encryption. UCL is currently working on adding support for sound localisation and externalisation.
Recent versions of the VIC videoconferencing software have been integrated into the MERCI tools. UCL has incorporated encryption code - though the encryption key is currently inserted manually. The production version of the tools, which will be released in September, will include the encrypted version of VIC.
INRIA is developing a successor to the IVS videoconferencing tool. The new tool, Rendez Vous, includes two new features, namely
This explicitly allocates resources such as CPU power to audio and video processing / transmission / reception so as to optimise the quality of the data delivered to the end user. The scheduler is expected to provide better quality to the end user by allowing resources such as CPU power to be allocated in a flexible way to a specific audio and/or video stream.
The new coding schemes are expected to provide better video quality for low bit rates, better robustness to loss, and scalability in multicast environments. Rendez Vous will be released in late October 1996.
Stream Synchronisation
Experiments on inter-stream synchronisation have been completed at UCL. Time-stamp information in RTP packets is used to co-ordinate the audio and video presentation on receiving hosts to achieve lip synchronisation. RAT is used for audio, and a modified version of VIC with play-out adaptation for video presentation. Co-ordination information is exchanged between the two tools using a local conference bus. The results of the work will be presented in IEEE Globecom 96.
The UCL shared text editor, Network Text Editor (NTE) is now a rugged tool. It operates over many flavours of UNIX, and has had encryption added to it in much the same way as VIC. Work has begun at RUS on porting it onto a Windows NT platform. Protocols for shared workspace tools are typically reliable multicast transport protocols, and they rely on sophisticated flow control mechanisms such as that in SRM (Scaleable Reliable Multicast). INRIA has started work on implementing SRM over the Real Time Transport Protocol (RTP) developed in the IETF for multimedia applications.
RUS has started development of a Java-based (and, thus, easily portable) shared whiteboard application.
At the start of the MERCI project, RAT was running on UNIX workstations from Sun and Silicon Graphics only. Since then, UCL has ported RAT to IBM compatible multimedia PCs running Windows 95 and Windows NT. In addition, UiO and UCL are working to port RAT to HP workstations, and a number of external groups are assisting with further ports. Free Phone is running on Sun UNIX workstations, with ports to Silicon Graphics and UNIX-based PCs underway. Ports to Windows-based PCs are planned for next year.
TELES has continued with its porting activities of H.320 Terminal to Windows 95. RUS has been busy exploring ongoing developments in the areas of multicasting, broadcasting and multimedia teleconferencing for PCs (running Windows 95 or Windows NT) and Macintosh computers (running MacOS). This work has involved the downloading, installation and testing of existing software and the compilation of a WWW page comprising the results of the investigations. In view of available resources and the poor support from Apple, we have dropped our plans to port the MERCI tools to the Macintosh platform. Apple is developing tools compatible with VIC and VAT, operating above RTP-2; these will interoperate with the MERCI tools. The JAVA-based whiteboard tool, currently under development at RUS, should run on the Mac - though it is unlikely that NTE will work on that machine.
The TELES.VISION DMC-system is being ported to the Windows 95 operating system. The first step, developing virtual I/O device (VxDs), is now complete. The next step, porting infrastructure components such as TLSFON (the telephony support API), TLSCAPI (the high-level ISDN interface) and TLSDTMF (the DTMF recognition module) to Windows 95 has begun. Some of the source code modules from which these components are built are OS-independent while others are OS dependent. In order to perform the porting, the OS dependent modules need to be re-written for Windows 95. This task has started and is currently progressing. A development environment has been established, which allows for the debugging of the 32-bit code modules. After the porting of the infrastructure components, the development of the applications as 32-bit code will begin.
The tools developed in WP3 have been made available on the Internet. Furthermore, specific Web pages describing the audio tools and ongoing work on high quality audio have been set up at
http://www-mice.cs.ucl.ac.uk/mice/rat/ and
http://www.inria.fr/rodeo/fphone (for Free Phone).
A Web page describing the Rendez Vous video tool has been set up at
http://www.inria.fr/rodeo/personnel/Frank.Lyonnet/IVStng/
An assessment of currently existing guidelines (e.g. LUSI, ISSUE) has been completed to determine which of these are applicable and relevant to MERCI. Having surveyed existing literature on usability and assessment of multimedia conferencing systems, a framework for usability evaluation has been developed. A number of evaluation methods have been selected for further development on the basis of this literature survey and an informal survey on emerging methods at the partner sites.
MERCI evaluation will begin with qualitative methods (observation, interviews, open questionnaires) and then use this material to formulate quantitative assessment methods via system logging, closed questionnaires etc. Work has now been completed on Laboratory experiments evaluating redundancy and audio-visual synchronisation and a list has been established of trials to be completed with an associated timetable. A schedule of user trials has been drawn up, and some user trials are currently in progress.
We aim to produce a modular MERCI questionnaire, consisting of a general part, to be completed by participants in all conferences, and then a number of specific question modules which can be applied depending on user group, application, stage of trial etc. This will be a partner-wide effort, co-ordinated from UCL.
The Pilot work is leading to an observational approach conducive to content analysis to provide objective assessment of the use of MERCI tools. The aim is to develop an observation method which can be used for further trials in conjunction with other evaluation methods (e.g., questionnaires, interviews). Efforts are being made at CRC to develop an HTML-interactive questionnaire to evaluate session success. A fuller report of this work has been prepared in the Usability and Assessment - Progress Report May 1996 which is included in Annex 7 to this report.
A list of user representation groups has been drawn up and these are in direct communication with individual MERCI partners. Validation activities are currently underway at CRC, UCL (Audio & Video Quality Assessment), RUS (MERCI Seminars), GMD (Telekom), Shell (Thornton and Amsterdam), and KTH (Stanford Teaching). Validation has also taken place in collaboration with project MANICORAL, who have trained their user group in the MERCI tools and provided user feedback in a joint meeting. Their internal report provided to us, Notes on the MANICORAL/MERCI Liaison Meeting, UCL, 15 July 1996, is included in Annex 7 to this report.
A fuller report for this workpackage can be found in Packet / Circuit MM Conference Interworking - Annual report, included in Annex 7 of this report.
Two major families of standards-based videoconferencing systems exist today:
The development of these ITU-T recommendations was followed with great interest from the communications- and IT industries. All major vendors which are active in the field of multimedia conferencing have joined IMTC, an industry forum which propagates the usage of these standards, organises interoperability trials, develops implementation guidelines and provides feedback to the ITU. Many of these vendors have already developed products on the basis of these standards. Desktop Multimedia Conferencing (DMC) systems based on the ITU recommendations of the H.3xx / T.12x series were developed in the RACE II project EuroBridge and have been applied in field trials on a European scale in other projects such as AREA, ICARE and others.
Due to their differing backgrounds and development histories, these DMC systems are currently not compatible although they employ, to some extent, the same communication protocols.
It is the aim of this workpackage to develop means which will allow MBONE videoconferencing tools and DMC systems based on the H.3xx / T.12x - series of ITU-T recommendations to interoperate, thus allowing them to enter the same conference.
Interworking between the MBONE Tools and H.320/T.12x-compliant Desktop Multimedia Conferencing (DMC) terminals will be achieved by means of a Gateway (MBONE / H.320 Gateway). When designing such a gateway, it is important to consider that MBONE- and ITU-style multimedia conferences have different characteristics:
It is the task of the gateway to mediate between both conference styles as depicted in the figure below:
Interworking between Mbone terminals and ITU Multimedia Conferencing Terminals
The MBONE H.323 Gateway consists of several components which are originally developed as separate entities but can later be integrated. Having them as separate entities has the advantage that the components can also be used individually.
The main components, comprise:
A full description of these components can be found in Packet / Circuit MM Conference Interworking - Annual report, included in Annex 7 of this report.
In the first eight months of the MERCI project, the following results have been achieved in WP 5:
The move to the use of higher speed networks has been slowed by the delays in the signing of the TEN'34 and JAMES contracts. Over the last few months the link between UCL and RUS was upgraded to an ATM one, but no other PNOs were willing to consider putting in services until after the contracts had been signed. It has been agreed in principle that BT will continue to liaise with the Project for the PNOs, but even here there has been a slight hitch, because of personnel changes in BT .
UCL has had frequent discussions with DARPA and others on the Federal Networking Council to get its link to the US moved and upgraded. This is important in the context of good conferencing with North America.
Measurements and Monitoring
INRIA has started a new round of measurements to characterise the delay and loss processes of audio packets over the MBONE. The goal is to come up with better characterisations and models than are available today, so as to design better play-out adjustment algorithms, and rate and error control mechanisms (see WP 3 above).
The functional modules described in ITU-T Recommendation H.324 Terminal for Low Bitrate Multimedia Communication are now incorporated into the TELES.VISION DMC system, thus making it capable of operating over analogue telephone networks. Major components described in this recommendation are:
A major effort was undertaken between Hewlett-Packard and UCL to ensure that the ISDN access facilities, using the ASCEND hardware, worked well with multiple B-channels. This has now been completed, and n x 64 Kbps channels can be supported at UCL and HP - Bristol. It is possible to run IP over multiple B-channels (between 1 and 30) into the primary rate devices at UCL and HP. KTH and RUS have installed similar equipment, but it has not been used extensively. The termination of H320 terminals requires further activity on both a mixer attached to the LAN, and some interworking facilities which are part of WP5.
Work pursued in WP7 initially involved the evaluation of the multimedia server created at UCL during the MICE project. Its advantages and disadvantages were assessed and it was decided to build up on the previous work. The server's main feature is its architecture which enables users to create their own applications to use the recorded data the way they want. The server requires access to a large storage space and this will be provided by a jukebox which will act as a back end to a 6 Gigabyte disk which will be a form of cache. Tests undertaken show that the transfer rates from/to the jukebox are adequate for the purpose.
A lot of time was spent in making the tool generally more robust and less prone to user error. The simple text interface (a help facility was added) did not cause any problems to the specific people who used the server; nevertheless we will create a Graphical User Interface which will combine the playing, recording and perusing interfaces of the server.
The Robust Audio Tool's (RAT) recordings can now be played back since the player was enhanced to ignore any time spent in sending the previous packets and send the packets within the time interval that RAT expects them. Another important problem concerning playback was solved. Initially any delay at the beginning of a recording (i.e. from the time the recording was started until the first packet was received) was reflected in the playback. Now this gap is skipped and playback starts immediately.
As there is a maximum number of files that a process can have open the recorder could only record up to 12 media sources (i.e. a maximum of 4 people all sending video, audio and whiteboard). Now all file activities (create, open, close, write) are managed by a file manager object which performs them on demand. When there is a number of open requests pending the file-manager selects which files to close and satisfies the requests. Any buffered data is written to files when the recorder is idle (there are idle gaps - a few milliseconds - during recording in which the recorder has no data to write to any files).
Playback of recordings was previously based on the timestamps at which the data was received at the recorder. This was not very desirable since any network jitter was replicated at playback. Now the recorder (when instructed) can record incoming data as RTP and RTCP packets. The player uses a combination of the recorder timestamps and the RTP sender timestamps to determine when it will send the data. In this way the packets are played back at the same gaps at which they were originally transmitted and the original network jitter is not replicated.
The work at KTH in WP7 has mostly been concerned with evaluation and testing of various server technologies, including coding techniques like Motion JPEG, MPEG II and Quicktime. We have started a co-operation with Sun and Oracle to evaluate the Oracle Video Server software and service, to conclude whether, and to what extent, MERCI may be able to use the forthcoming commercial technologies.
The work done in this workpackage falls under several headings related both to the Internet environment, where the project has been active in defining standards through the IETF, and to the ITU where we have been active in Study Groups 8 and 15 of the ITU-T. A full report of the work of this workpackage, Conference Control and Management - Annual report, is included in Annex 7.
For a lightweight session, no explicit session control or membership control is required, but a rendezvous mechanism is required to communicate information about the existence of a session to its potential participants. To this end, the Session Description Protocol (SDP) and Session Announcement Protocol (SAP) were devised by UCL and LBL, originally by the MICE project, and have continued to evolve and be revised by the MERCI project. These protocols are implemented in the UCL Session Directory tool SDR. At the start of the MERCI project, Mbone conferences were being announced by an early session directory tool, SD, from Lawrence Berkeley Labs. SD had limited functionality, and a number of problems including an inability to announce RTP based sessions. SDR solved these problems, and over the first eight months of the MERCI project it has become used ubiquitously by the Mbone community. In fact it has been so successful that, in the past couple of months, compatible tools have started to emerge.
In addition to announcing public sessions as a table of contents, an alternative mechanism to initiate multimedia sessions follows a telephone style analogy - a user wishes to call another user to start a session immediately.
Using SIP, a user may call another user who has SDR running, and invite them to join an existing advertised session or a new private "on-demand" session. The current implementation of SIP in SDR is minimal, but performs well. SIP, however, allows for relays to provide user-location, firewall transition, etc., and this additional functionality, not yet implemented, will be provided during the second year of MERCI.
SDP, SAP and SIP are currently all Internet-drafts, and will be progressed to IETF "Proposed Standard" status during the second year of MERCI.
Since the start of MERCI, the ITU SG15 (in which the MERCI project was represented by TELES) developed the H.323 family of protocols, which take H.320 ISDN-based videophone technology onto packet-switched local-area networks. The H.323 family includes Q.931 for call initiation, and H.245 for content type negotiation.
TELES have had PC based H.320 solutions for some time, and are currently developing H.323 based solutions and an H.320/H.323 gateway.
The ITU SG 8 developed the T.120 family of protocols for data-conferencing. Although there is some overlap between T.120 and H.320/H.323, in general they complement each other, with the "H" protocols providing the basic video-telephony parts and the "T" series protocols providing more advanced conference control facilities and some limited shared application functionality.
The T.120 series was designed for use over reliable circuit switched ISDN, with Multipoint Control Units providing data-distribution and conference access and control mechanisms. In the Internet, IP multicast provides efficient data distribution without resorting to MCUs, and conference access control can only reliably be performed through the use of encryption. In addition, the reliable multi-point distribution channel assumed by T.120 cannot exist (ISDN channels do not "fail-silent", packet networks do), so T.120's error recovery mechanisms seem inappropriate and insufficient for wide-area Internet-based operation. While this is a current problem, it is being addressed in the WG.
Although the details of inter-operation are covered in WP5, the scenarios mentioned affect conference control more than any other work package. H.323 specifies the use of RTP/RTCP for distribution of the actual data traffic, so an H.320 to H.323 gateway will perform most of the correct functionality for inter-operation at this level. However, in the conference control area, large Mbone lightweight-sessions, H.323 sessions and T.120 sessions have significantly different concepts of what constitutes a session and how to control it.
H.323 sessions can be initiated through T.120 without requiring the Q.931 set-up phase, and T.120 provides much richer functionality that H.323, so to enable inter-operation between ISDN based conferencing and Internet based conferencing, the best solution for the MERCI project appears to be to provide a mechanism to allow T.120 style conference control over the Mbone, preserving as much of the T.120 semantics as are appropriate for multicast-based operation. In particular, this involves mapping the T.124 Generic Conference Control protocol (or at least its semantics) over IP multicast, and providing a gateway, at the border to the ISDN network, to map the multicast syntax into circuit switched ISDN based syntax.
To this end, TELES (represented by TU Berlin and TU Bremen) have been developing the Simple Conference Control Protocol (SCCP) in the IETF, which will provide an IP multicast based mechanism upon which T.124 semantics can be built. Work on SCCP is less advanced than that on SDP/SAP/SIP, as it started later; running code is not yet publicly available, but an SCCP implementation should be available during the second year of MERCI.
Both the LBL Mbone conferencing tools (VIC and VAT) and the UCL audio tool (RAT) support inter-tool local communication using a multicast-based local conference bus. Currently no standard is available for such a local bus. Although UCL presented a proposal for this at the IETF, the IETF MMUSIC session control working group has decided that such local protocols fall into the category of API rather than network protocol and thus do not fall under the auspices of the IETF. However, LBL have agreed with UCL to work towards standardising this interface mechanism outside of the IETF, and this work should be completed in the second year of MERCI.
Multicast routing is not yet ubiquitous, and so there are sites that wish to participate in Mbone sessions but cannot do so. This applies in particular to workstations situated at the end of ISDN lines running IP (usually PPP) over ISDN. Such workstations often do not wish to run full multicast routing, or cannot do so if they are running any Microsoft operating system without a local multicast router, and so an alternative solution is required.
UCL have been working on a set of solutions collectively known as the Umbone (Unicast Mbone). These are components that can be put together to form a relay between the multicast world and a single, multicast-deprived, end-system. Sessions will be initiated using a modified SDR Session Directory, which can obtain a list of available sessions on demand (rather than continuously for a multicast-capable site), and can send a SIP request to initiate the mixing and relaying functionality.
Currently work on the audio mixer has been started, drawing upon experience gained in writing the RAT audio tool. The video switcher, queuing module and modified session directory will be completed in the second year of MERCI.
Conference control and security functionality are intricately related, and the SAP, SDP and SIP protocols all include explicit security mechanisms to perform key exchange for multicast sessions. This functionality is discussed in detail in the report on the Security work package (WP10). The second revision of the SCCP document will do this as well, so we must look carefully how to provide this functionality.
At the Montreal IETF, a Birds of a Feather (BOF) session was held on the subject of multimedia server control. The provisional proposal that emerged from this BOF was to use the MERCI project's Session Invitation Protocol to initiate recording and playback from a remote server, in addition to a server control protocol (as yet un-named) to provide control of sessions so initiated. This work is very tentative at this stage.
Several of the partners have been upgrading their conference room facilities. Both UiO and KTH have upgraded conference rooms with flexible tools for conferencing during the first half of 1996. At KTH development of a conference room/lecture hall for 225 people has started and will be completed by September. KTH has refined the tools for remote camera control and production and has developed new tools for high-quality audio and video between conference rooms.
UiO is developing new pen-hardware for the electronic whiteboard which will be lower cost and better quality than the system currently in use. The robustness of the software components in the electronic classroom system has been significantly improved and the user-interface of the system has been redesigned and extended to allow end-users to fully operate the conference room. A fourth conference room of the electronic classroom type has been completed in Norway at Høgskolen i Hedmark. In May, this conference room was used for a short course conducted jointly with the University of Oslo.
Several software components currently used in the electronic classroom are available from UiO for project partners only:
UCL has made more modest improvements in its conference rooms, but they are adequate for small scale activity. Further upgrades will be made in the next year in the light of our experiences with collaborative seminars.
Under MERCI auspices, a paper on Secure Conference architectures has been completed. This covers two worlds of conferencing, the ITU and the Internet/ Mbone world. Security in the ITU world is mainly characterised by Recommendations H.233 and H.234, that in the Internet by Internet standards. The aspects of these worlds are discussed. This paper is being made available to the ICE-TEL project because of its implications on the requirements on the security infrastructure. The paper outlines the need to encrypt the data exchanged by the multimedia tools, and also to provide both confidentiality and authentication on session announcements and invitations. As mentioned in WP8, the secured versions of SDR, which take these needs into account, are under development. In addition SCUA, the Secure Conferencing User Agent (an outcome of the MICE project, based on E-mail, though enhanced) meets the requirements and is being made available for MERCI.
The ICE-TEL project presumes a security infrastructure for Europe, which can be utilised for Public Key interchange; such an assumption is not necessarily valid in the Internet as a whole. For this reason, most of the components of SDR will operate without assuming the availability of such an infrastructure - though the Session Invitation Protocol does require it. The SCUA is using the ICE-TEL infrastructure to the extent it is available now.
The key distribution mechanisms for Public Keys, to authenticate persons or groups will be provided by the ICE-TEL project or others and the Public Keys may be available by access to directories, or WWW pages or may be exchanged by mail. The provision of these keys and the means to retrieve public keys should be the task of a common security infrastructure. MERCI's ask is to make possible that among authenticated participants conference information like date, time, addresses, session keys for the multimedia data streams, etc. may be exchanged confidentially. This may be made available through SDR, E-mail or a WWW page. The available or nearly available solutions till now are SDR and SCUA.
We have also been examining alternative mechanisms for session key distribution using secured mail interchange or secured directory access. Possible mechanisms are outlined in the architecture report (D10.1, due 31 August 1996), but it is not yet clear how far we will go on implementation.
The continued lack of the high-speed connectivity to be provided by TEN-34 and JAMES, already mentioned in WP6, means that there is a very bad network performance to some MERCI partners. This makes it difficult, if not impossible, to achieve the good video and audio quality between all the partners which is essential for successful seminars. For this reason, the number of seminars given was deliberately reduced. Two seminars have been given:
19 March 1996: Object-Oriented Technology, A Brief Introduction was given from RUS by C.J. Copplestone.
24 May 1996: REALITY IS VIRTUAL: Why Virtual Reality Works was given from UCL by Professor Lawrence W. Stark, MD of the School of Optometry, UC-Berkeley.
and a further one is planned:
5 September 1996: High speed networking in Canada, to be given from UCL by Doug Hughes, Canadian Network for the Advancement of Research, Industry and Education (CANARIE).
The development of a WWW based seminar booking form at RUS has now been completed and the form is in use. It may be accessed at URL:
http://WWW-KS.RUS.Uni-Stuttgart.De/PROJ/MERCI/seminars.html
Seminar ideas which are being investigated include one on visualisation which might include a shared visualisation demonstration and another involving the re-multicast from KTH of a conference feed from the SIGCOM meeting at Stanford in September next.
MERCI has tested and used its own tools at the weekly/biweekly networked multimedia project meetings as described in item A 11.1 of the Project Plan for this workpackage.
The development, in Workpackage 4, of a Seminar/Conference General Questionnaire will make evaluation of future seminars more effective. This is the first of a series of specialised questionnaires to record user perceptions of quality.
The original plan for this workpackage was to participate in the Urology Workshop due to be held in September 1996 at the Middlesex Hospital, London. As a result of his difficulties in setting up this workshop, Dr Kellett of the Middlesex Hospital has postponed it until February 1997. At that time we will be involved as planned. Whilst this is a disappointment, there is a positive aspect: we expect to have much improved network connectivity in the new year which will improve the chances of a successful demonstration of the surgical procedures. RUS has made initial contacts with the hospital in Stuttgart and UCL has been in touch with UCLA. The first of the two workshops is due to be delivered by the end of February, 1997, so no deadline has been missed by the postponement.
A formal agreement has been set up between Deutsche Telekom AG in Germany and MERCI contractor GMD to carry out commercial trials with MERCI tools at Telekom premises.
Silicon Graphics workstations and Mbone tools have been installed at Deutsche Telekom locations. The configuration consists of a LAN/LAN interconnection over ISDN. So far, user tests have only been done with audio and WB tools; video tools cannot be used due to problems with the existing SGI video cards; other cards have been ordered. Nevertheless, the Telekom team is quite satisfied with the tools (they were well accepted) and the experiments done so far. They are eager to add video connections as soon as possible. With a full set of media, more extensive trials will be arranged for the fourth quarter of 1996.
An analysis of any problems or difficulties which have been addressed, whether of a technical or organisational point of view.
The delay in the signing of the contract for JAMES has made the testing of the tools over high bandwidth links somewhat problematical so far. We are currently in consultation with BT over the inclusion of the project as a JAMES user and anticipate no problem. The main effect has been on the quality of the demonstrations, seminars and periodic project meetings which we have held. On the positive side we have been able to demonstrate the success of the Robust Audio Tool (RAT), when used with redundancy, in overcoming some of the problems of packet loss on congested links by allowing intelligible conversations to continue in the face of much higher loss rates than would be possible with other tools.
The postponement of this workshop by Dr Kellet has meant that we shall be multicasting both of the planned workshops in the second year of the project, but has not otherwise caused a problem to the partners.A.4 Changes to the project plan
Summarise the reasons and events leading to any change of direction or approach which the project has felt necessary to adopt. Briefly describe the work which still remains to be done in the project and when this is likely to be completed
There have been no major changes to the project plan. At the kick-off meeting responsibility for Workpackages 4 and 11 were switched to make RUS responsible for WP11 and UCL for WP4. This was matched by a change of the pms between the workpackages.
Porting of MERCI tools to Apple MACs has been abandoned for the reasons given in the discussion of WP3.
The consortium agreed to the request from TELES to withdraw from Workpackage 9, Conference Room Support, and add the 1 pm pa assigned to that work into their effort on Workpackage 8, Conference Management and Control.
We anticipate further changes if we get permission to include the Communications Research Centre (CRC) of Industry Canada in the consortium. This we have been trying to do since the project's inception. Included in B.1.3 Dependencies and Relationships is a description of the proposed contribution of CRC to the project.
Describe the user representation groups, their contribution in the development and exploitation of the work.
MANICORAL is a TELEMATICS for Research project (RE 1006). The project consists of three partners
The feedback from MANICORAL will influence the ongoing development of tools, especially the design of their user interface.
Shell research, one of the projects sponsoring partners, are using a special interface to the tools based on that developed for the ReLaTe language teaching project (see A.9 Dissemination activity and plans - Publications below). Since the start of MERCI, the newly developed secure versions of the tools have been incorporated into the interface and have been successfully demonstrated. Secure conferencing is of great importance to Shell, as to many other users. Shell have begun using the new interface, Collabone (Collaboration over the Mbone), in conferences between Shell researchers and Shell-funded projects at Thornton, Amsterdam and Leeds University. On-line training for the users has been provided by UCL using the tools themselves to deliver the training. This experience has shown both advantages and problems and will not be used normally as an initial training technique.
As more use is made of both the new interface and the new security features of the tools, we will learn more of the problems and feed this back into our continuing development of the user interface. The objective, as always, will be to make the tools not only more efficient, but also more usable by non-technical users.
Our work with Hewlett-Packard has been mostly in interworking with the UK laboratory in the use of ISDN for Mbone conferencing which is described in our report on WP 6 above.
We expect more user feedback when we are able to give a full set of PC-based tools to TPEC, the Hewlett-Packard training group at Isle d'Abeau in France, who plan to use them for expert training.
Outline the validation undertaken in the project and/or any subsequent plans for doing so.
Describe the demonstration and/or trials (to be) undertaken ensuring that following information is provided:
Description of demonstrator(s)
Sectors (applications) involved
Sites
Number and type of users
Technologies used
Evaluation methodology/results
Feedback, potential uptake, extensions of the work etc.
Mechanism for user acceptance and validation
The main development work of the project is in the improvement of the tools and their transfer to other platforms, operating systems and networks. Therefore validation is an ongoing part of the project, not just a single activity. Here we rehearse our plans and report on progress to date.
The stated objectives of the project include:
We see four stages of verification:
The validation which we have achieved so far is a mixture of that done within the project and that done by our users in the MANICORAL project.
MANICORAL has been using the tools which we gave them as the deliverable D0 (details in Annex 5 below). We have had only an initial report from them so far together with questions on the use and limitations of the tools for their purposes (See Notes on the MANICORAL/MERCI Liaison Meeting, UCL, 15 July 1996 included in Annex 7). We expect further feedback from the next deliverables and after increased use of the tools by the AFRICAR project.
We have so far held 19 multimedia conferences since the start of the project and have delivered 2 seminars in our first series. The planned delivery of the medical workshop in September has been postponed until February 1997.
The conferences have been characterised by generally poor connectivity which we have overcome by the use of tools resistant to the adverse network conditions. Network Text Editor (NTE) has proved a much more useful tool than the LBL whiteboard WB for displaying the agenda and using the agenda to interactively develop the minutes; when connectivity declines temporarily, participants use NTE to communicate and this text is then edited into the minutes. The use of the Robust Audio Tool (RAT), with redundant encoding for audio, has enabled us to continue to speak and be heard in conditions where loss would have prevented this otherwise. In these difficult conditions, RAT also provided proof of the efficacy of the concept of using additional, redundant audio encoding to counter network loss.
The two seminars delivered so far were:
19 March 1996: Object-Oriented Technology, A Brief Introduction was given from RUS by C.J. Copplestone.
24 May 1996: REALITY IS VIRTUAL: Why Virtual Reality Works was given from UCL by Professor Lawrence W. Stark, MD of the School of Optometry, UC-Berkeley.
We have had limited feedback from non-project people attending these seminars. The first event, from RUS, was received well at UCL and the feedback from the group of MSc students, attending in a conference room, was positive. We had no feed back from the second seminar due to a failure of both the main and backup analogue audio systems soon after the seminar started (both the microphones failed). A new Seminar series is scheduled between October and December with further seminars planned for 1997.
In many instances, the continued lack of the high-speed connectivity expected from the TEN-34 and JAMES projects has meant very bad network performance between most MERCI partners. This makes it difficult, if not impossible, to achieve the standard of video and audio between the partners which is essential for successful network seminars and the regular business meetings.
A description of the role of the project in the programme Sector, including its interfaces and inter-actions with other projects; describe the extent and nature of participation in the Concertation meetings. A description of the activities of the project involving other projects in the programme, in particular those within the horizontal sectors.
MERCI is a service provider to the other projects in the Telematics for Research sector. We provide the tools for multimedia conferencing, assist with their introduction and will, in due course, provide a fully secured conferencing environment for both workstations and PCs.
We have held two meetings with MANICORAL, an initial meeting with the whole project and a later technical meeting with RAL, the partner responsible for developing the shared visualisation tool. We are in close contact with ICE-TEL from which project we will get our secure conferencing infrastructure. We have had preliminary discussions with CoBrow on technical approaches to shared working in the Internet. We were particularly interested in the work being done at Lancaster University on the development of filters for media streams. We are interested in using them to allow the interconnection of lower-bandwidth links with the mainstream Mbone. The Project Director has attended meetings with SCIMITAR to discuss and define the extent to which SCIMITAR will fund sector projects' activities in the field of standards definition. MERCI is fully compliant with the deliverables publishing format requested by the ADVISER project.
The Project Director and Project Manager of MERCI attended the first Concertation meeting in Brussels on March 18, 1996.
An analysis of the actual and potential contribution of the project work to the overall efficiency, effectiveness and quality of the domain, or application area, in which the project is working. A description of the contribution of the demonstration of services which will result could be included here.
MERCI is demonstrating that adequate technology is available, and high quality advice can be brought to bear by applying the technology to three important applications:
In each case the applications require audio, video and shared workspace.
The seminar series requires rugged regular use of the technology to a wide number of sites; the demands on the video and audio is high but not too stringent; there is a need to distribute slide and OHP material as part of the seminars. The capability for the tools to be put together in interesting and innovative ways has been demonstrated by the interface developed by the ReLaTe project for language teaching. We maintain our interest in and support of the development of such interfaces for new educational uses.
The newer higher quality tools provided by MERCI will enable the Surgery Workshop (WP12) to satisfy the tighter demands on the quality of the video; the catheters used are often extremely narrow, and the detail is of interest to surgeons. In these uses of conferencing, the introduction of multimedia servers allows an important improvement to the quality of the seminars as educational experiences. The access to high bandwidths also improves quality. The availability of a secure conferencing environment to be provided by MERCI will ensure the confidentiality of the procedures to be multicast and thus an approved audience. This is vital for many reasons - of which patient protection is an important one.
An agreement has been concluded between GMD and Deutsche Telekom AG in Germany to carry out commercial trials with MERCI tools at Telekom premises. Silicon Graphics workstations and Mbone tools have been installed at Deutsche Telekom locations. The configuration consists of a LAN/LAN interconnection over ISDN. So far, user tests have only been done with audio and WB tools, but, with the installation of new video cards which have been ordered, more extensive trials will be arranged in the third quarter of 1996. Despite the very early stage of these trials, the Telekom team is quite satisfied with the tools and the experiments done so far.
We must emphasise that the above practical uses of the technology, whilst they show validation of our approach, are not seen as real demonstrators. Each one can be developed into a full demonstrator - indeed this may well happen. However, with so many projects using the technology, we continue to evaluate which variants and facilities will be most needed; hence our strong commitment to the user reports gathered by WP4.
Describe the main diffusion type activities, e.g. organisation of workshops, conferences, key papers delivered and published etc.
Describe the actual and planned dissemination of your results.
INRIA and UCL both sent delegates. A UCL report of the meeting is included in Annex 7.
Joerg Ott of TELES presented the first version of the Simple Conference Control Protocol which will be supported by the H.323 to MBONE Gateway being developed at TELES.
Mark Handley of UCL, joint chair of the Multiparty Multimedia Session Control Working Group (MMUSIC), presented papers on Session Invitation Protocol (SIP), Session Description Protocol (SDP) and Session Directory Announcement Protocol (SDAP) to this working. He also attended the Audio/Video Transport Working Group. Minutes of these meetings are included in Annex 7 of this report.
Walid Dabbous and Mark Handley presented the redundant audio encoding technique and payload format developed by UCL and INRIA. Progress on SIP (Session Invitation Protocol) was described by Mark Handley (UCL). A new Session Announcement Protocol (SAP) draft was presented by Mark Handley. Progress on SCCP was described by Carsten Bormann. A UCL report of the meeting is included in Annex 7.
Joerg Ott participated in discussions on extensions to T.125 (MCS) and T.124 (GCC) at this meeting. He also attended the IMTC Corporate Network Conferencing Meeting to participate in the discussion of the next version of the ITU-T Recommendations of the H.323 series of protocols.
There is a public project server at UCL. The URL is
http://www-mice.cs.ucl.ac.uk/merci/
This server also has a password-protected private section used for Project Control and documentation.
A MERCI page has been added to the RUS WWW server. The URL of the RUS server is
http://WWW-KS.RUS.Uni-Stuttgart.De/PROJ/MERCI/MERCI.html
RUS have produced a two-page colour handout with information about MERCI which is available from the RUS web server.
Demonstrations of the MERCI technology have been given for:
UCL presented a paper at the UK NetWorkshop conference
The project was represented at the JENC7 Conference in Budapest, 13-16 May, by several of the partners. UCL and GMD were presenting papers (see Publications below). RUS attended the TERENA WG-LLT and WG-NMA meetings on 13 May.
UCL presented a paper to the Videoconferencing workshop organised by UKERNA at the University of Nottingham, 13/14 May (see Publications below).
Two seminars have been given (details in A2 - Workpackage 11):
19 March 1996 : "Object-Oriented Technology, A Brief Introduction" was given from RUS by C.J. Copplestone.
24 May 1996 : "REALITY IS VIRTUAL: Why Virtual Reality Works" was given from UCL by Professor Lawrence W. Stark, MD of the School of Optometry, UC-Berkeley.
At present one further seminar is planned:
5 September 1996 : "High speed Networking in Canada" to be given from UCL by Doug Hughes, CANARIE.
Bennett, R., Kirstein, P. T. : The MERCI Project - Improving Multimedia Conferencing for Research, Proc. UKERNA Videoconferencing Workshop, Nottingham, May 96.
Bolot, J-C. & Vega Garcia, A. : "Control mechanisms for packet audio in the Internet", Proc. IEEE Infocom '96, San Fransisco, CA, pp. 232-239, April 1996.
Hinsch, E., Jaegemann, A., Roper, I. C. & Wang, L. : "The Secure Conferencing User Agent : A Tool to Provide Secure Conferencing with MBONE Multimedia Conferencing Applications", Proc. IDMS '96, Berlin, March 96.
Hinsch, E., Jaegemann, A. & Wang, L. : "Experience with the Secure Conferencing User Agent: A Tool to Provide Secure Conferencing with MBONE Multimedia Conferencing Applications", Proc JENC7, Budapest, May 96.
Kirstein, P. T. : MERCI Project (A Progress Report on Multimedia European Research Conferencing Integration), Proc. JENC7, Budapest, May 96
Sasse, A. & Bennett, R. : Recent Developments in the Support of Multicast Conferencing in the UK. Proc. NetWorkshop 24, Brighton, March 96.
Bormann, C., Ott, J. & Reichert, C. : "Simple Conference Control Protocol", available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sccp-00.txt
Handley, M. & Jacobson, V. : "Session Description Protocol", available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-02.ps
Handley, M. & Schooler, E. : "Session Invitation Protocol", available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps
Handley, M. : "Session Announcement Protocol", available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sap-00.ps
Handley, M., Crowcroft, J. and Bormann, C. : "The Internet Multimedia Conferencing Architecture", available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-confarch-00.ps
Perkins, C et al. : "Payload Format Issues for Redundant Encodings in RTP", Internet draft draft-perkins-rtp-redundancy-01.{txt,ps}, July 1996.
We have plans to improve the web server by allowing access to video and audio data and by updating and enhancing the much referenced Multimedia Index which was begun under the MICE project.
During the next year we expect to attend all the IETF meetings and also those of the ITU-T Study Groups 8 and 15 which are the groups concerned with the technical standardisation of multimedia teleconferencing. This represents a large drain on our finances, and we have requested assistance from the SCIMITAR project to help defray the cost.
We will continue to mount demonstrations at conferences and other suitable venues, to attend conferences and to publish our research in suitable journals.
We will be responsible for the multicast of the IEEE GLOBECOM conference in November 1996 from the Queen Elizabeth II Hall in London. We will be represented at the MEDNET96 conference of the European Congress of the Internet in Medicine to be held in Brighton, UK in October 1996 to describe our work in the transmission of surgical workshops.
At the present time we have a number of papers pre-publication:
Bolot, J-C. & Turletti, T. : "Adaptive Error Control for Packet Video in the Internet", Invited paper in Proc. IEEE, ICIP'96 (Intl Conf. Image Processing), Lausanne, Switzerland, September 1996.
Bolot, J-C. & Vega Garcia, A. : "The case for FEC-based error control for packet audio in the Internet", to appear in Multimedia Systems Journal.
Kouvelas I, Hardman V J & Watson A : "Lip Synchronisation for use over the Internet: Analysis and Implementation". To be presented at IEEE GLOBECOM November 1996.
Watson, A. & Sasse, A. : "Evaluating Audio and Video Quality in Low-Cost Multimedia Conferencing Systems". To appear in Interacting with Computers, September '96.
Bolot, J-C. & Turletti, T. : "Experience with control mechanisms for packet video in the Internet'', submitted to IEEE, JSAC.
Hardman V J and Iken M : "Enhanced Reality Audio in Interactive Networked Environments". Submitted to FIVE'96.
Kouvelas I, Hardman V J : "Overcoming Workstation Scheduling Problems in a Real-Time Audio tool". Submitted to USENIX 1997.
A.10 Details of patent applications
Give fuller details of any patent applications made since the previous review or commencement of the project. These should include the name of the organisation holding the patent (application) and any provisions made or envisaged for exploitation of the patent.
No patents have been applied for during this period.
A description of how the project has contributed to the Sector objectives. Highlight the contribution of the project work to achieving the programme objectives. Answer each of the following questions individually.
To the extent that the project is generic, we can discuss only the impact on telematic applications in general. In the particular education, training and health-care areas, the impact can be immense. In tertiary education, UiO, KTH and UCL are already discussing putting on full joint courses - something which we are considering applying much more widely. Hewlett-Packard and other similar organisations already have a European wide training mission; they are looking to this project to help provide an insight on whether it is now possible to organise the training on a genuinely pan-European basis.
In the medical education field, University College London already has an integrated course across the three medical sites that have been part of their catchment area - hence the ease with which they have entered a larger British project, funded nationally, to provide surgical education embracing 6 universities and using SuperJANET. This in turn has meant that the infrastructure was in place to introduce operations from Sweden and the US into a workshop at short notice. These operations were watched in their turn (and questions were asked) by doctors at that workshop, at other hospitals seminar rooms, and on individual workstations. The impact this will have for medical consultation will be immense; we will be able to use our improved tools over the JAMES and TEN'34 networks to incorporate higher quality video and audio, and to introduce the better quality instrument data used by the medical practitioners. Because we are also embracing lower levels of technology, namely ISDN, we will be able also to influence secondary health care - allowing medical consultation between the doctor's office and the hospital.
These arguments extend to other areas. It should be noted that the entry costs are not high. With the porting of the applications to high-end PCs, much larger numbers of users can use our technology without the need for high-performance workstations or expensive networks. Clearly the higher performance workstations, PCs, servers and networks will improve the facilities that can be offered. The economic justification is over-powering.
The project's contribution to the competitiveness of industry is necessarily oblique since its objectives are to facilitate the use of the multimedia conferencing technology within the European research community. We do see the contribution being made in three main fields:
The improvement in the network infrastructure resulting from the investment in JAMES and TEN'34 will complement and enhance our activity with these users.
We have identified European researchers as our major constituency and have made a good start with the use of the conferencing technology by Shell Research, Hewlett-Packard Laboratories, MANICORAL project (RE 1006) and UKERNA. We have discussed much of this in the preceding section, and more detail of this contribution is given in section A.2 Work done, within the workpackage descriptions.
One of the biggest problems of effectively managing the effort of such a large research programme as Telematics is the difficulty in ensuring that the many related and interlocking projects communicate with the Commission and with each other. Such communication needs to be made in a timely and appropriate manner without spending too much time and effort. The provision of projects to facilitate such communication, including MERCI and SCIMITAR, and the programme of Concertation meetings both confirm that this is recognised.
The effort and cost involved in setting up the various meetings needed for effective communication militate against its being done to the extent that it is needed when partners and projects are spread across the whole of Europe. If the multimedia conferencing tools now in use can be deployed to the extent of saving a small proportion of this time and effort, the project will have made a major contribution to the activities of the sector domain. It is already making some contribution. MANICORAL is using the tools for regular meetings and ICE-TEL intends to use them soon. We expect that such use will increase as the tools become more sophisticated and are made available to the much larger user population which uses PCs rather than UNIX workstations.
There is direct involvement of SMEs on both sides of the Atlantic. TELES, one of the partners, is an SME; they are contributing strongly to the project in ways that directly impact their product plans - both on ITU terminals, and on Interworking Gateways. UiO is a partner concentrating on Conference Rooms in the project; they are planning to start a company to commercialise the product which was partially financed by this work. Reflection Systems, a British SME, has donated software used for the Jukebox (donated by HP), which will be used in the Multimedia Server. GMD is starting a company to commercialise its security products; these will be used in the security workpackage. UCL has been discussing with the ISODE Consortium, which derived from UCL activities, its taking over some of the security and session announcement activity which derives from the UCL work. Finally, we are discussing with many SMEs, in particular Video Logic of the UK, the use of their PC boards for the project.
The project has a strong involvement with its designated users and has benefited already from their reactions to using the tools for conferencing. We expect that we will gain far more from this involvement as we bring improved tools to them in the coming year and as they gain more experience in the use of the tools.
Some aspects of the MERCI work are easier to exploit nationally. Both technical and political considerations have made connectivity to some countries difficult in the past. Nevertheless, the real benefit comes from the European dimension. It is very clear from the other European projects in which the partners are involved, that the international benefits are huge; we have a depth and regularity of content which is completely unavailable in the normal projects not using this way of working. It would have been quite impossible to make the rapid progress we have made in the project without the use of the technology; the European dimension is required by many of the applications, and avoids different developments becoming unable to interwork
At the start of the MERCI project, most of the partners already knew each other and had worked together on MICE where the use of interactive conferencing revolutionised the collaboration. MERCI has got off to a flying start with its use, and has already been able to improve the collaboration of the partners in MANICORAL, a linked project, through making the conferencing tools available to them. The availability, and wide deployment, of this technology will continue to have an integrating effect that cannot yet be fully appreciated. This will be in full support of the information society in Europe and of the European Union policies. Moreover, we still maintain that the way that the multimedia technology plans to embrace most of the underlying network technologies will have several important consequences:
This part of the document should cover, at least, the following elements. Please use the formats provided (see bi-monthly management report where appropriate).
Annex 1. Project partners
Partner Role Description of Type of Budget Person -
Role Organisatio (KECU) Months
n
UCL C1 Project A1 385.0 84.0
co-ordinator
GMD C Contractor A4 289.0 26.9
INRIA C Contractor A1 267.0 21.6
KTH C Contractor A1 200.5 36.5
UiO C Contractor A2 135.1 29.0
RUS C Contractor A1 134.0 23.0
TELES C Contractor A1 534.6 40.3
Annex 2. Project activities
Work package or activity Manpower Manpower used
planned (Person -
(Person-months Months)
within the
reporting
period)
WP1 Management 6.0 5.7
WP2 Activity with External Groups 7.3 5.5
WP3 MM Conference Components and
cross-platform 15.7 19.3
support
WP4 Usability and Assessment 3.3 2.5
WP5 Interworking 6.9 6.1
WP6 Network Support 10.1 12.1
WP7 Multimedia Server 6.9 7.1
WP8 Conference Management and Control 8.3 7.4
WP9 Conference Room Support 5.0 5.4
WP10 Security 11.7 12.0
WP11 MERCI Seminars 5.3 4.4
WP12 Surgical Workshop 2.6 0.7
WP13 Commercial Trials 2.0 1.0
Total 91.1 89.2
Annex 3. Partner Contribution
Partner Work packages Manpower planned Manpower used
involved in (Person-months) (Person-months)
UCL 1 -12 30.0 30.4
GMD 2, 5,10,11,13 8.7 8.6
INRIA 2,3,5,6,11 7.2 8.5
KTH 2,6,7,8,9,10,11,12 12.3 12.2
UiO 2,3,4,6,7,8,9,11 10.0 6.4
RUS 2,3,4,5,6,11,12 8.0 8.4
TELES 2,3,4,5,6,8,10,11,13 14.9 14.7
Total 91.1 89.2
In addition to the provision of man-power, two of our Sponsoring Partners have made direct contributions of material kind in support of the project. A financial contribution from Shell Research to UCL has allowed it to devote more man-power to the project. Substantial equipment provision from Hewlett-Packard to the four academic partners (PCs, a Server, peripherals, and network management software) has allowed us to become much more better equipped to attack the use of PCs on the project, and to improve the network management activities of WP6.
Annex 4. List of deliverables
This list should contain all deliverables due on or before the end of the reporting period.
Reference Title Date due Date Target date
number submitted if overdue
D0 Initial Software 29 Feb. 96 29 Feb. 96
Annex 5. Executive Summaries of Deliverables
Executive Summaries of all Public deliverables and abstracts of Programme level deliverables must be included here. In liaison with the Project officer or at the subsequent request of a Reviewer, some key or 'Submitted on Request' deliverables may be needed in full (please contact the project officer for details).
You should provide 5 copies of these deliverables which are to be reviewed.
This is a Project deliverable of tools only, restricted to Project participants. It was delivered on time on the 29 February, 1996. The intention was to provide an approved set of tools for audio, video, shared work-space and conference control which were usable then and which presented a benchmark starting point for the work of the project. The tools included in this deliverable were:
Audio: VAT 4.0
Video: VIC 2.7
Shared workspace: WB 1.59
NTE 1.6
Conference control: SD 1.16
They are available on the MERCI web server :
http://www-mice.cs.ucl.ac.uk/merci/deliverables/
Annex 6 - Involvement in other EU research and development activities
Further detailed commentary may be included here on the concrete contribution of the project to the Programme goals at both Sector level and at overall Telematics Applications Programme level. For example: involvement in other EU research and development activities.
The MERCI partners are involved in many European and National projects which are directly relevant to their work in MERCI. On the European level, several of the ACTS projects in which we are partners (e.g. PROSPECT and ATHOC), will be using the MERCI tools. With ICE-TEL the links are particularly strong; it plans to use MERCI tools for discussions between the partners, and MERCI will use its Certification Authority infrastructure for verifying and distributing Public Key certificates. While the partners are not directly members of JAMES or TEN-34, the project will be a major user of their facilities - and will be providing technical input for further advancement of the multicast and resource allocation aspects of these networks. Several partners are involved with ACTS Network Management projects (VITAL, PROSPECT and IBCOBN to mention a few); it is probable that the provision by one sponsoring partner (Hewlett-Packard) of Network Management facilities to four of the MERCI partners will stimulate activities related to, and feeding off, some of these Network Management projects.
There are several activities, both under European and National auspices, to support users in networked multimedia. There are official links with the MICE National Support Centres, which are leading to them having JAMES links with MERCI; there is also excellent provision for such centres to run MERCI services, receive MERCI software, and to support National users of MERCI products.
Annex 7 - Additional information on workpackages.
This section consists of the following items:
Page
Workpackage 4 Usability and Assessment - Progress Report May 1996 44
Workpackage 5 Packet / Circuit MM Conference Interworking - Annual report 46
Workpackage 8 Conference Control and Management - Annual report 53
Report of the 34th IETF meeting, Dallas, December 1995 57
Minutes of MMUSIC WG meeting at the 35th IETF, Los Angeles, March 1996 63
Minutes of A/V Transport WG meeting at the 35th IETF, Los Angeles, March 1996 66
Notes on the MANICORAL/MERCI Liaison Meeting, UCL, 15 July 1996 73
Report of the 36th IETF meeting, Montreal, June1996 78
An assessment of currently existing guidelines (e.g. LUSI, ISSUE) has been completed to determine which of these are applicable and relevant to MERCI. The workpackage will produce
1.1 An assessment of current guidelines and technology, and their relevance to multimedia conferencing systems for research collaboration and related applications.
1.2 General and specific user requirements for multimedia conferencing for research collaboration and related applications (such as distance education, health care, business).
1.3 Revised and new user interfaces for MERCI tools and integrated conferencing systems.
1.4 Recommendation for additional and novel functionality and technology, as well as guidelines for use.
1.5 Effectiveness and usability assessments with user groups through a number of studies, ranging from field trials to experimental investigations.
MERCI evaluation should attempt to begin with qualitative methods (observation, interviews, open questionnaires) and then use this material to formulate quantitative assessment methods via system logging, closed questionnaires etc. For the results to be comparable, we have to ensure that we use the same measurement tools where appropriate. The following approaches are used, or being considered, for data collection.
2.1 questionnaires - open-ended and forced-choice;
2.2 observation - done via video recorder, remotely from another workstation, in person etc.;
2.3 interviews - one-to-one can be time consuming, group interview is very effective;
2.4 content analysis - analysis of behavioural transcript;
2.5 system logging - tool use logged automatically by the system;
2.6 empirical experimentation - controlled conditions rather than field trials. Quality thresholds for audio and video will be investigated at UCL by experimental methods.
3.1 Lab experiments evaluating redundancy and audio-visual synchronisation.
3.2 List of trials (see section 4) to be completed and associated timetable established.
4.1 There is an immediate requirement to document the seminars and provide a means for all participants to file assessments of the seminars and regular meetings of MERCI partners. The aim is to produce a modular MERCI questionnaire, consisting of a general part, to be completed by participants in all conferences, and then a number of specific question modules which can be applied depending on user group, application, stage of trial etc. This is a partner-wide effort, co-ordinated from UCL.
4.2 Introduction and support of the MICE/MERCI tools has been initiated for collaboration between Shell researchers and Shell-funded projects at Leeds University. There will be a series of conferences between researchers at Thornton-Amsterdam-Leeds (June - September 96), using workstation-based trial with modified version of ReLaTe integrated interface.
4.3 The current ReLaTe activity focus on porting of ReLaTe tools (rat, VIC, WB & NTE in an integrated conferencing interface) to PCs (Exeter will port to LINUX, UCL to Windows95).
4.4 Pilot work is leading to an observational approach conducive to content analysis (CRC). Content analysis on multimedia recordings (stereophonic audio, 4-way video, and capture logs of keyboard & mouse activities) made of seminars/conference and laboratory experiments will provide objective assessment of the use of MERCI tools. The aim is to develop an observation method to be used for other trials in conjunctions with other evaluation methods (e.g. questionnaires, interviews).
4.5 Weekly 2-hour seminar series between KTH and Stanford are under way, providing another milieu for usability and assessment to be addressed.
4.6 User assessment and trials are planned with other Telematics for Research project, WWW-based (CoBrow) and CSCW-based (MANICORAL, using MERCI tools .
4.7 Trials with German Telecom between Darmstadt-Berlin will take place as of July 96 (GMD). Interest has been expressed about collaboration between Shell-Thornton and Daimler Benz in Stuttgart. ULB is discussing a demonstration for Phillips/Siemens in Brussels.
4.8 Questionnaires for students participating in remote classrooms are available, but require translation to English. Remote teaching activities via Electronic Classrooms continues at UiO.
4.9 Contact UKERNA and HP to identify activities that could be used for assessment/usability (UCL).
4.10 Efforts are being made to develop an HTML-interactive questionnaire to evaluate session success (CRC). The development of session suitability and success will focus on session goals and activities rather than the actual tools. This questionnaire is being designed to be adaptable to various Internet services, but will be tested within the context of mbone activity and MERCI sessions.
MERCI Annual Review Report
Workpackage 5 - Packet / Circuit MM Conference Interworking
Period: December 1995 - July 1996
Goals:
Two major families of standards-based videoconferencing systems exist today:
The development of these ITU-T recommendations was followed with great interest from the communications- and IT industries. All major vendors which are active in the field of multimedia conferencing have joined the International Multimedia Teleconferencing Consortium (IMTC), an industry forum which propagates the usage of these standards, organises interoperability trials, develops implementation guidelines and provides feedback to the ITU. Many of these vendors have already developed products on the basis of these standards. DMC systems based on the ITU recommendations of the H.3xx / T.12x series were developed in the RACE II project EuroBridge and have been applied in field trials on a European scale in other projects such as AREA, ICARE and others.
Due to the different background and history to the development of these DMC systems, both kinds of systems are currently not compatible although they employ to some extent the same communication protocols.
It is the aim of WP 5 of the MERCI project to develop means which will allow Mbone videoconferencing tools and DMC systems based on the H.3xx / T.12x - series of ITU-T recs. to interoperate, thus allowing them to enter the same conference.
Approach:
Interworking between the Mbone Tools and H.320/T.12x-compliant Desktop Multimedia Conferencing (DMC) terminals will be achieved by means of a Gateway (Mbone / H.320 Gateway).
When designing such a gateway, it is important to consider that Mbone- and ITU-style multimedia conferences have different characteristics:
Audio-, video and datastreams of all conference participants of an Mbone session are multicast via the network simultaneously. Thus, every conference participant receives all data streams sources by all other conference participants. The receiver decides how to process them (e.g. whether to represent only specific video data streams). The overall bandwidth occupied by the conference is thus the sum of the bandwidths occupied by the individual sites.
Mbone conferences are completely distributed, i.e. no centralised entity or set of entities exist to perform conference control functions. Mbone terminals have no explicit means to control conferences (e.g. to join a conference, to invite other parties to a conference, to request the speech right etc.).
It is the task of the gateway to mediate between both conference styles as depicted in the figure below.
Figure 1 : Interworking between Mbone terminals and ITU Multimedia Conferencing Terminals
The Mbone H.323 Gateway consists of several components which are originally developed as separate entities but can later be integrated. The following figure gives an overview over these components and their interrelations. It illustrates the control and data flows between an ITU terminal, an Mbone terminals and the gateway. Dotted fat lines depict protocols which allow Mbone terminals to actively establish connections to a remote site and perform conference control functions (such as invitation of other sites, creation of ITU conferences on an MCU, acting as a conference chairman etc.).
Figure 2 : Components of the Mbone / H.320 gateway and their Interrelations
In the following, the main components, comprising
are described in more detail.
The Session Controller (SC) provides the essential conference management functionality for Mbone terminals, i.e. it allows Mbone terminals
The Session Controller is a component which will be installed on Mbone terminals in addition to the other Mbone tools (RAT, VIC, ...) and has the capability to co-operate locally with these other tools.
The Session controller communicates with the Mbone / H.323 gateway by means of the Simple Invitation Protocol (SIP) and the Simple Conference Control Protocol (SCCP) both of which are currently Internet Drafts and are being further developed in WP 8 of the MERCI project.
Figure 3 : Schematic diagram of the Mbone / H.323 gateway
The Mbone / H.323 Gateway allows Mbone terminals which are equipped with a Session Controller to communicate with H.323 terminals. The Mbone / H.323 Terminal acts as a proxy in this context, i.e. it maps SIP / SCCP to the corresponding H.323 / T.120 functions and vice versa.
The Mbone / H.323 gateway does not influence the audio- and video data streams which are multicast on the LAN. The data formats used by the H.323 Terminal and the Mbone Tools to exchange audio and video data are identical and both sites have access to them as they are multicast on the LAN.
The H.323 / H.320 Gateway allows ISDN-based H.320 terminals to communicate with LAN-based H.323 terminals.
Achievements:
In the first nine months of the MERCI project, the following results have been achieved in WP 5:
In parallel with the specification of the Simple Conference Control Protocol in WP 8, the development of the Session Controller - which will provide conference management functionality to Mbone terminals - has started and it is expected that first version will be available in autumn 1996.
The software architecture of the Mbone / H.323 gateway has been defined. This architecture forms the basis for the implementation of the gateway, which has started. The gateway consists of components required to establish H.323 connections and of a module which maps SIP / SCCP PDUs to the corresponding H.323 / T.120 functions. In this manner it acts like an H.323 proxy for Mbone terminals.
A first version of the H.323/T.12x Subsystem Module and the High-level Multimedia Conferencing API to this module (HMC-API) has been developed. Work is currently concentrating on the development of the Mbone / H.323 relay module.
Future Work:
The first version of the operational Mbone / H.323 Gateway and of the Session Controller will be available for the second MERCI software deliverable in month 15 of the MERCI project. This will provide the basic gateway functionality and allow one Mbone Terminal to communicate with one H.323 Terminal.
A first version of the H.323 / H.320 gateway will also be available at that time so that one Mbone terminal will be enabled to enter one H.320 conference.
Subsequent work will then concentrate on the integration of security facilities and on an enhancement of the Mbone / H.323 gateway in order to allow more than one Mbone terminal to enter an ITU-style multimedia conference at a time. The corresponding enhanced versions of the Mbone terminal and the Session Controller will be available for the third MERCI software deliverable.
[itu-g711] ITU-T Recommendation G.711: Pulse Code Modulation (PCM) for Voice Frequencies; Aug. 1992
[itu-h221] ITU-T Recommendation H.221: Frame Structure for a 64 to 1920 Kbps channel in audio-visual teleservices; March 1993
[itu-h230] ITU-T Recommendation H.230: Frame Synchronous Control and Indication Signals for Audio-Visual Systems; March 1993
[itu-h233] ITU-T Recommendation H.233: Confidentiality System for Audio-visual Services; July 1995
[itu-h234] ITU-T Recommendation H.234: Encryption Key Management and Authentication System for Audio-visual Services; Nov. 1994
[itu-h261] ITU-T Recommendation H.261: Video Codec for Audio-visual Conferences at p x 64 kbit/s; March 1993
[itu-h310] Draft ITU-T Recommendation H.310: Broadband Audio-visual Communication Systems and terminals, June 1996
[itu-h320] ITU-T Recommendation H.320: Narrow-Band Visual Telephone Systems and Terminal Equipment; March 1993
[itu-h323] Draft ITU-T Recommendation H.323: Visual Telephone Systems and Terminal Equipment for Local Area Networks which provide a Non-Guaranteed Quality of Service; May 1996
[itu-h324] Draft ITU-T Recommendation H.324: Terminal for Low Bitrate Multimedia Communication, June 1996
[itu-t120] Draft ITU-T Recommendation T.120: Data Protocols for Multimedia Conferencing; Nov. 1995
[itu-t124] ITU-T Draft Recommendation T.124: Generic Conference Control for Audio-visual terminals and Multi-point Control Units; August 1995
[itu-t126] ITU-T Recommendation T.126: Multi-point Still Image and Annotation Protocol; August 1995
MERCI Annual Review Report
Workpackage 8 Conference Control and Management
Period: December 1995 - July 1996
The work done in this workpackage falls under several headings related both to the Internet environment, where the project has been active in defining standards through the IETF, and to the ITU where we have been active in Study Groups 8 and 15 of the ITU-T.
The MERCI project's primary work is in the field of multicast multimedia conferencing on the Internet. IP multicast provides not only an efficient data distribution mechanism for media streams, but also provides an efficient distributed binding mechanism whereby receivers in a session can discover and receive traffic from senders without explicit application-level joining mechanisms. This has led to the evolution of the lightweight sessions philosophy, in which a session consists of a set of multicast based media tools at each site, and no explicit session control or membership control - sites that wish to send merely do so, and if receivers do not wish to listen, they may "mute" individual senders locally. This philosophy is the basis of the Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP) which are now IETF "Proposed Standards".
For a lightweight session, no explicit session control or membership control is required, but a rendezvous mechanism is required to communicate information about the existence of a session to its potential participants. To this end, the Session Description Protocol (SDP) and Session Announcement Protocol (SAP) were devised by UCL and LBL, originally by the MICE project, and have continued to evolve and be revised by the MERCI project. These protocols are implemented in the UCL Session Directory tool SDR. At the start of the MERCI project, Mbone conferences were being announced by an early session directory tool, SD, from Lawrence Berkeley Labs. Sd had limited functionality, and a number of problems including an inability to announce RTP based sessions. Sdr solved these problems, and over the first eight months of the MERCI project it has become used ubiquitously by the Mbone community. In fact it has been so successful that, in the past couple of months, compatible tools have started to emerge.
In addition to announcing public sessions in a "Radio Times" style fashion, an alternative mechanism to initiate multimedia sessions follows a telephone style analogy - a user wishes to call another user to start a session immediately. To do this requires three things:
On the Internet, a naming scheme already exists in the form of electronic mail addresses, so it is desirable to re-use this. User location is somewhat site-specific, but it is possible to design a protocol with appropriate hooks for user location and to perform (3) above. To this end, the Session Invitation Protocol (SIP) has been devised by UCL and Caltech, and is currently an Internet Draft, with a deployed minimal implementation in SDR. SIP is used to convey SDP session descriptions in this new scenario.
Using SIP, a user may call another user who has SDR running, and invite them to join an existing advertised session or a new private "on-demand" session. The current implementation of SIP in SDR is minimal, but performs well. SIP, however, allows for relays to provide user-location, firewall transition, etc, and this additional functionality, not yet implemented, will be provided during the second year of MERCI.
SDP, SAP and SIP are currently all Internet-drafts, and will be progressed to IETF "Proposed Standard" status during the second year of MERCI.
During the first year of MERCI, the ITU SG15 (in which the MERCI project was represented by TELES) developed the H.323 family of protocols, which take H.320 ISDN-based videophone technology onto packet-switched local-area networks. The H.323 family includes Q.931 for call initiation, and H.245 for content type negotiation.
It is likely that H.323 based conferencing will become widespread on corporate LANs interconnected by H.320 based ISDN connections. It is less clear how much use H.323 will see in the wide area Internet. A minimal subset of H.323 is usable (though probably not optimal) for small tightly-coupled conferences on the wide-area Internet, and is being pushed by several large US companies including Intel and Picturetel, so H.323 based solutions will probably form a part of the Internet conferencing picture.
It is also clear though that H.323 cannot support the large dynamic lightweight sessions that Mbone conferencing can provide, thus H.323 cannot be the only solution. There is clearly overlap between Q.931/H.245 and SIP, but they are aimed at very different styles of conferencing, and extending Q.931/H.245 to support very large Mbone sessions does not appear to be feasible. Hence we expect both H.323 and SIP to exist for some time as Internet-based conferencing evolves.
TELES have had PC based H.320 solutions for some time, and are currently developing H.323 based solutions and an H.320/H.323 gateway.
The ITU SG 8 developed the T.120 family of protocols for data-conferencing. Although there is some overlap between T.120 and H.320/H.323, in general they complement each other, with the "H" protocols providing the basic video-telephony parts and the "T" series protocols providing more advanced conference control facilities and some limited shared application functionality.
The T.120 series was designed for use over reliable circuit switched ISDN, with Multipoint Control Units providing data-distribution and conference access and control mechanisms. In the Internet, IP multicast provides efficient data distribution without resorting to MCUs, and conference access control can only reliably be performed through the use of encryption. In addition, the reliable multi-point distribution channel assumed by T.120 cannot exist (ISDN channels do not "fail-silent", packet networks do), so T.120's error recovery mechanisms seem inappropriate and insufficient for wide-area Internet-based operation. While this is a current problem, it is being addressed in the WG.
Although the details of inter-operation are covered in WP5, the scenarios mentioned affect conference control more than any other work package. H.323 specifies the use of RTP/RTCP for distribution of the actual data traffic, so an H.320 to H.323 gateway will perform most of the correct functionality for inter-operation at this level. However, in the conference control area, large Mbone lightweight-sessions, H.323 sessions and T.120 sessions have significantly different concepts of what constitutes a session and how to control it.
H.323 sessions can be initiated through T.120 without requiring the Q.931 set-up phase, and T.120 provides much richer functionality that H.323, so to enable inter-operation between ISDN based conferencing and Internet based conferencing, the best solution for the MERCI project appears to be to provide a mechanism to allow T.120 style conference control over the Mbone, preserving as much of the T.120 semantics as are appropriate for multicast-based operation. In particular, this involves mapping the T.124 Generic Conference Control protocol (or at least its semantics) over IP multicast, and providing a gateway, at the border to the ISDN network, to map the multicast syntax into circuit switched ISDN based syntax.
To this end, TELES (represented by TU Berlin and TU Bremen) have been developing the Simple Conference Control Protocol (SCCP) in the IETF, which will provide an IP multicast based mechanism upon which T.124 semantics can be built. Work on SCCP is less advanced than that on SDP/SAP/SIP, as it started later; running code is not yet publicly available, but an SCCP implementation should be available during the second year of MERCI.
Both the LBL Mbone conferencing tools (VIC and VAT) and the UCL audio tool (RAT) support inter-tool local communication using a multicast-based local conference bus. Currently no standard is available for such a local bus. Although UCL presented a proposal for this at the IETF, the IETF MMUSIC session control working group has decided that such local protocols fall into the category of API rather than network protocol and thus do not fall under the auspices of the IETF. However, LBL have agreed with UCL to work towards standardising this interface mechanism outside of the IETF, and this work should be completed in the second year of MERCI.
Multicast routing is not yet ubiquitous, and so there are sites that wish to participate in Mbone sessions but cannot do so. This applies in particular to workstations situated at the end of ISDN lines running IP (usually PPP) over ISDN. Such workstations often do not wish to run full multicast routing, or cannot do so if they are running any Microsoft operating system without a local multicast router, and so an alternative solution is required.
UCL have been working on a set of solutions collectively known as the Umbone (Unicast Mbone). These are components that can be put together to form a relay between the multicast world and a single, multicast-deprived, end-system. Incoming audio streams from the Mbone will be mixed to produce a single audio stream, and transcoded if necessary to further reduce bandwidth. Incoming video streams will be switched and potentially also be transcoded or bandwidth reduced by frame-rate reduction (which can be done in the compressed domain). The resulting audio, video and shared workspace streams will then be put through a priority queuing gateway to ensure that audio gets precedence over shared workspace over video when they reach the bandwidth constrained ISDN link. Sessions will be initiated using a modified SDR Session Directory, which can obtain a list of available sessions on demand (rather than continuously for a multicast-capable site), and can send a SIP request to initiate the mixing and relaying functionality.
Currently work on the audio mixer has been started, drawing upon experience gained in writing the RAT audio tool. The video switcher, queuing module and modified session directory will be completed in the second year of MERCI.
Conference control and security functionality are intricately related, and the SAP, SDP and SIP protocols all include explicit security mechanisms to perform key exchange for multicast sessions. This functionality is discussed in detail in the report on the Security work package (WP10). The second revision of the SCCP document will do this as well, so we must look carefully how to provide this functionality.
At the Montreal IETF, a Birds of a Feather (BOF) session was held on the subject of multimedia server control. The provisional proposal that emerged from this BOF was to use the MERCI project's Session Invitation Protocol to initiate recording and playback from a remote server, in addition to a server control protocol (as yet un-named) to provide control of sessions so initiated. This work is very tentative at this stage.
"Session Description Protocol", Mark Handley/Van Jacobson
Available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-02.ps
"Session Invitation Protocol", Mark Handley/Eve Schooler.
Available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps
"Session Announcement Protocol", Mark Handley
Available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sap-00.ps
"Simple Conference Control Protocol", Carsten Bormann/Joerg Ott/Christoph Reichert
Available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sccp-00.txt
"The Internet Multimedia Conferencing Architecture", M. Handley/J. Crowcroft/C. Bormann
Available from ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-confarch-00.ps
"RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, RFC 1889
"RTP Profile for Audio and Video Conferences with Minimal Control" H. Schulzrinne, RFC 1890
Recommendation H.320 (03/93) - Narrow-band visual telephone systems and terminal equipment
Recommendation H.245 (3/96) Control protocol for multimedia communication
Recommendation T.120 (7/96) Data protocols for multimedia conferencing
Recommendation T.124 (8/95) Generic Conference Control
Recommendation Q.931 (3/93) ISDN user-network interface layer 3 specification for basic call control
Draft Recommendation H.323: Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service
The IETF Meeting, Dallas, December 4-8 1995
Peter T. Kirstein and M. Handley
University College London
ABSTRACT
This note outlines some of the impressions from our attendance at the IETF meeting in Dallas in December 1995. There will be much fuller minutes of all the sessions on the network. However, this note describes some of the activities on security, network congestion and multimedia. It is a very personal impression, and does not reflect the total activities at the meeting.
There were the usual large number of sessions throughout the five days of the meeting of the Internet Engineering Task Force (IETF), but for the purposes of this visit, we concentrated on those aspects directly applicable to the ICE-TEL and MERCI projects. These were actually more than the conferencing and security sessions themselves; they included also those on routing, congestion control and integrated services.
Of some significance, and concern was the statements made at the MMUSIC session, that the agreements made between the Internet Society (ISOC) and the ITU were not being followed - and that this was largely due to the US delegation to the ITU. The problem is complex. The IETF is not a registered entity, so any agreements made have been with ISOC (this raises its own problems, since there is some move to have the IETF become independent of ISOC). ISOC is a US-registered corporation, but had made a verbal agreement with the ITU that it could be a member organisation, and its dues have been waived on a reciprocal basis. IETF members can attend ITU meetings, and their Standards have been introduced into the ITU in the past. This does not mean that an IETF Standard is automatically an ITU Standard, but it was thought to mean that such Standards could be referenced in ITU ones - as distinct from being repeated and explicitly voted on in the ITU. The US delegation has now objected to this procedure - partly because they are worried about a precedent with other sorts of organisation; they have stated that such Standards can only be introduced directly through the US delegation - because the ISOC is a US-incorporated entity. It is not yet clear how this will be resolved from the ITU viewpoint; in addition, there are some ongoing discussions between the ISOC trustees and the ICB as to whether the Standards part of the IETF will stay under ISOC or not in any case.
No significant changes were made to RSVP at this IETF. RSVP version 1 is close to being submitted to Proposed Standard status, and many small details remain to be cleared up before then. It was decided that some of these details will now be relegated to RSVP version 2. The most important remaining work that needs to be done before submitting RSVP to Proposed Standard status is the definition of a MIB and a definition of how RSVP should work over ATM.
Deborah Estrin presented changes to PIM (Protocol Independent Multicast) to allow PIM to function properly in a two level multicast routing hierarchy with DVMRP at the higher of the two levels. These ideas have changed completely since the Stockholm IETF, and no longer use a single globally advertised RP for the case when PIM is not used in the multicast backbone.
Mark Handley presented Hierarchical PIM - a new PIM model which avoids the need for globally advertised RPs when PIM is used in the multicast backbone. This work is still tentative, but variations on it are now being considered by a number of people.
Bill Fenner presented mtrace (multicast traceroute) which is now the recommended method for diagnosing Mbone problems.
Tony Ballardie presented a unified model for the interface between level 1 and level 2 in a two level hierarchical Mbone. The aim was to simply the number of combinations that need to be considered when interfacing two different multicast protocols in this manner.
Problems concerned with making multicast a ubiquitous service and multicast fault diagnosis were discussed.
A decision was taken to attempt to outlaw all multicast routing implementations that do now support all of:
- multicast pruning
- default routes
- multicast traceroute
With mrouted, this means all mrouteds before mrouted 3.6 will be consider obsolete. This change will happen during the first part of 1996.
A number of Standards are now in various stages of completion: Socks v5 [secure xxxx, imminent], One Time Passwords (very soon), SKIP (last call in the working group), Simple Protocol for Key Management for the GSSAPI (SPKM was stopped by Internet Engineering Steering Group), Domain Name Service (last call in the working group). Of these only SPKM was really significant; it was stopped because it required RSA, and there was no satisfactory licence agreement from PKG Inc. The recent arbitration agreement against PKG has been so satisfactory, that RSA is considered to be freely available, and all the Standards incorporating it will now be considered. Finally, there have been problems with the Simple Network Management Protocol (SNMPv2); it has been decided to approve the services management interface and the management interface base to Standard, and to call the product data unit "Experimental.
There was considerable discussion in the Security Advisory Group on the question of the fundamental security of the Internet. The reports of determined attacks are increasing - and the attacks are now more directed at the high-end infrastructure - not only end-hosts. The hackers are attacking the routers and the Domain Name Servers (DNS), which could be serious. The standards for secure IP are now out to ballot, so that it should soon be possible to implement security in a Standard way in the routers. However, in the discussion it transpired that CISCO had had the option in their code for some time - but virtually nobody had bothered to implement their routers accordingly. In the subsequent discussion, it was considered that it would take several years before this level of security was widely deployed.
There was a session on, and considerable discussion of, standards for site security. Amongst others there is a very useful document in the "Site Security Handbook" Its recommendations are simple - but far reaching. It sill include discussions about security procedures - like authentication, authorisation, access, use of cryptography, use of auditing, and back-ups; currently the cryptography and back-up sections are blank. There is an important chapter on Incident Handling - including prioritisation of actions.
The CAT WG met for two sessions in Dallas. Presentations included talks on the SESAME GSS-API mechanism, the Kerberos Single-Use Authentication Mechanism (SAM) draft, Kerberos Public-Key Extensions, IDUP, Simple Authentication and Session Layer (SASL), authorisation and delegation control extensions (xgssapi), and GSS-API/Web integration (a work item within the WTS WG). Other discussion topics included pending issues on GSS-V2; all known pending issues were closed or triggered action items, and an additional Internet-Draft version is planned for January as a basis for advancement to Proposed Standard. Following active business on Internet-Drafts, a brief summary of Microsoft's adaptation of GSS-API for Windows NT was presented.
In addition to status of active drafts, status of available reference code was discussed. Reference code is currently available for Kerberos and for the Kerberos GSS-API mechanism (per GSS-V1); a partial GSS-V2 Kerberos mechanism implementation (including context import/export and credential support extensions) has been developed at MIT and is available as a snapshot. Reference code is planned to be available shortly (January 1996) for the SESAME mechanism and early in 1996 for the SPKM mechanism. Reference code currently exists for Kerberos Public-Key Initial Authentication but revisions are planned as a result of issues being discussed. No reference code is currently available for Kerberos SAM, but will be developed subsequently.
There was an inaugural meeting of the Public Key Infrastructure WG (PKIX), attended by approximately 147 IETF members. Kent provided an overview of what a PKI encompasses and why it is needed - emphasisijng that a PKI is useful only relative to a set of applications that employ certificates. This WG will need to identify the set of (Internet) applications that will be supported by this PKI, and derive from these applications the requirements imposed on a supporting PKI. Candidate applications include: e-mail, IPSEC protocols, GSS API, WWW security (e.g., SSL and S-HTTP), and various electronic commerce payment schemes.
Ford discussed the history and status of X.509.versions of certificate and CRL syntax. In 1994, an extensible format for version 3 certificates and version 2 CRLs was adopted. In 1995 work is progressing in ISO on definition of a specific set of "standard" extensions for version 3 certificates and version 2 CRLs.
Solo discussed some of the issues associated with use of version 3 certificate extensions, e.g., what constitutes required support for compliant implementations and the use of the Critical flag. Concern was expressed over how to expand, over time, the set of "required" extensions that must be supported by compliant implementation. Solo emphasised the importance of a thoughtful discussion of selecting supported name types and representing various forms of identity in the syntax options present.
Housley reviewed version 2 CRL extensions, describing the motivation for each extension and making some suggestions for an Internet profile for these extensions. Overall CRL extensions reviewed included Authority Key Identifier, Issuer Alternate Name, CRL Number, Issuing Distribution Point, and the Delta CRL Indicator. Use of the last of these was disparaged by the speaker. Per-entry CRL extensions reviewed include Invalidity date, Reason Code, Expiration Date, and Instruction Code. the last three of these were disparaged by the speaker. (See the I-D for details.)
Ford discusses the need for protocols to support certificate registration and initialisation (in general), key pair recovery (escrow), key pair updating, on-line requests for revocation, and cross-certification exchanges. The intent is to establish application layer protocols for these management functions, which are largely independent of the underlying protocol stack, plus to map these protocols to specific Internet protocol environments, e.g., e-mail or HTTP. (See the I-D for details on initial proposals for several of these protocols.)
Farrell describes proposed requirements for a CA key pair updating protocol, emphasising minimal impact on existing client certificates and allowing for a graceful transition to a new CA key. (See the I-D for details for this proposed new data structure and modified certificate validation procedure.)
Pinkas provided feedback on the I-D, as well as speaking about his advertised agenda topic. He began by noting that the owner of a private key generally does not need to "know" the key, but only needs to be able to use it, even though a (trusted) third party (e.g., an escrow agent) might have a requirement to "know" the key. This approach implies using hardware (vs. software) to enforce this security policy. He is especially concerned about using an RSA signature key for encryption, vs. signature generation. (The motivation is based on French government regulations regarding encryption but not digital signatures.) Pinkas argued that this policy would require the CA to be off-line, and that the CA would not directly track the certificates it signs (vs. a separate directory function). Pinks also emphasised that the PKI I-D should emphasise support for non-repudiation. This implies changes to current specifications for how long a certificate stays on a CRL, and a requirement that older CRLs ought to be available. There is a suggestion that the Invalidity Date extension is important in supporting non-repudiation, in contrast with earlier comments on this extension.
Kent very briefly described motivations for establishing and using certification policies, and the X.509 v3 extensions that are available for supporting policies. Fared very briefly described some motivations for establishing Local Registration Authority (LRA) or and Organisational Registration Authority (ORA), and alluded to the need for protocols to support this CA representatives.
There were many discussions on WWW security. The Netscape SSL approach does a low-level security, so that any application protocol can be used. Even that version needs to be implemented in Europe by projects like ours, because the permitted security in the exportable versions is too weak. MOSAIC is advocating a PGP approach to Web security, which is straightforward, and allows for both authentication and confidentiality. The WTS group debated their proposals for a Secure HTTP (S-HTTP). This approach can use Public keys, but also can use symmetric keys; it is interesting, as long as it is taken up by those making the browsers and servers. Finally, there was a lengthy discussion on the use of GSS-API for web security; this approach is very interesting to ICE-TEL, since we had agreed to use that API if it was at all possible.
The WWW situation is sufficiently complex, that we feel we must make better contact with the WWW Consortium and Netscape directly to consider how to proceed in ICE-TEL.
There was an important session on Secure Transactions. There has been little progress in the fundamental problem - the vested interests in non-collaboration. There was a detailed discussion on the VISA/Microsoft Secure Transaction Technology (STT) Standard, versus the Mastercard/Netscape/IBM SEPP work. It was clear that neither of the parties really wanted the IETF to participate in this discussion; they wanted them to restrict themselves to activities like browsing, and leave the secure transactions to the credit card companies and their cronies.
A short report was given by Robert Webber from PictureTel on the progress of ITU-T SG-15 with H.323 Standardisation. It appears SG-15 have decided to copy the IETF RTP specification as H.225 rather than reference it. This is contrary to assurances that the ISOC's ITU representative had been given. This is significant because it would mean that no single standard is available should either the IETF or the ITU need to modify RTP in the future.
See ftp://ftp.std.com/vendors/PictureTel/h323 for details of the H323.
Joerg Ott presented the recent developments on T.120 and H.323. The ITU-T conferencing group has been moving forward very quickly and concern was raised that little concern was being shown in the ITU for wide area IP conferencing issues, but that most companies were already committed to implementing whatever the ITU come up with.
Mark Handley presented the small number of changes that have been made to SDP since Stockholm. No significant objection was raised to these changes. Steve Casner raised some issues that the current draft does not adequately address. It was agreed these issues regarding dynamic payload types in RTP need to be addressed before the current draft could be taken forward to Proposed Standard.
Mark Handley presented a Stawman protocol for the Session Directory Announcement Protocol. No significant objections were raised to this protocol. Steve Deering suggested that the IPsec work was suitable for authentication in SDAP.
Carsten Bormann presented a talk on Local Session State Objects.
Mark Handley presented a Strawman protocol for a vertical Session Co-ordination Protocol which is based on LBL's conference bus architecture found in VAT and VIC.
Since early 1995, the intserv WG has been pushing forward three draft service models - Guaranteed Service, Predictive Service, and Controlled Delay Service. Guaranteed and Controlled Delay were lined up for being submitted to Proposed Standard status. Quite a number of members of the community had privately submitted reservations that Controlled Delay was too complicated to be implemented as a minimal better-than-best-effort service, and that a simpler minimal service was required. In response to this, a new service specification called Controlled Load was written two weeks prior to the IETF. This defines an access controlled service with only one service level which is supposed to provide conditions equivalent to best-effort service on an otherwise unloaded network. Although few of the people present had read the draft in detail, the consensus was that most people were happier with this reduced service than they were with Controlled Delay. Thus it will now be Guaranteed Service and Controlled Load service that are taken forward to Proposed Standard. As the Controlled Load draft had not had sufficient time to be read by sufficiently many people, and as it contained some minor errors and deficiencies, a new Controlled Load draft will now to produced before the end of 1995, and its status re-appraised early in 1996.
Chairs
Mark Handley, m.handley@cs.ucl.ac.uk
Ruth Lang, rlang@sri.com
Eve Schooler, schooler@cs.caltech.edu
MMUSIC met during two sessions at the 35th IETF, both of which were multicast. A summary of each of the talks given and a report of any follow-up action items follows. An on-line copy of these minutes and the accompanying PostScript slides are available from ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.96 and slides.3.96.{tar, tar.Z}. These notes were prepared by Ruth Lang.
Mark Handley (UCL) gave a presentation and solicited additional input on open issues on the Session Description Protocol (sdp.3.96.ps). The issues reviewed include expression of RTP profiles and payload types, format lists, format groups, and a proposed change to the "media" and "connection" lines which allow more general expression of connection topologies and media relationships (e.g., for layered encodings). Sufficient input was received to resolve some of the issues, but discussion will continue on the mailing list on others. Specifically, RTP profiles will be expressed on the "protocol" line of the description (i.e., RTP/profile); supporting dynamic RTP payload types was left as an open issue dependent on further discussions in AVT regarding the definition of a registration mechanism for them; the idea of re-introducing format groups was discouraged in favour of retaining explicit descriptions of a group of encodings; and changes to the "media2 and "connection" lines were left as an open issue. A revised Internet draft will be issued soon and the goal of issuing "last call" before the next IETF meeting was set.
Mark Handley (UCL) gave a presentation on the design goals and issues for a Session Directory Announcement Protocol (SDAP) (sdap.3.96.ps). This protocol was originally envisioned to only support wide-area multicast of SDP packets, but has been divided into a wide-area (server to server) and local-area (client to server) portions. The division was made to facilitate a segregation between session directory management and maintenance functions (e.g., multicast address allocation) and user-oriented functions (e.g., instantiating tools). It was noted that the Service Location Protocol could provide a means to locate directory servers, but lacked support for asynchronous update. Mark has proposed to write an Internet-Draft describing SDAP for review and discussion before the next IETF.
Mark Handley (UCL) provided an overview of the motivations for the creation of the Internet Multimedia Conferencing Architecture document (confarch.3.96.ps). This document describes the "big picture" which is driving the development of the MMUSIC protocols, and the relationship among the protocols in terms of a conference lifecycle. Allison Mankin (Transport Area Chair) encouraged that 1) the document be made an Informational RFC with note that the document is intended to change, and 2) MMUSIC formally ask the Security Area for a formal consultation. Additional comments received included an encouragement that this document be used to note the relationship between MMUSIC and the ITU work on session control, and that the document should provide descriptions of yet uncharted (by MMUSIC) technical challenges.
Ross Finlayson (Live Networks) gave a presentation aimed at motivating more general thinking about the use of the MBONE as a general groupware framework (groupware.3.96/1-10.ps). Some ideas Ross suggested for further thought include: developing a way to share more than just media (i.e., workspace sharing), a generalisation in how sessions are managed (e.g., multiple directories), use of object inheritance models in describing sessions, supporting additional persistence models in describing sessions (e.g., personal directories). Some discussion centred around the use of multiple directories and their similarity to net news. No action items followed from this presentation.
Rob Williams (Microsoft) and Eve Schooler (Cal Tech) each gave presentations on the topic of User Location [(uls.3.96.ps) and (userdir.3.96.ps) respectively]. Rob's presentation described a service that has been developed at Microsoft for which an MMUSIC Internet-Draft has been created. This User Location Service provides a means for users to build a common directory of information regarding the running applications that can be used for collaboration. The User Location Service I-D describes the client-side protocol for add/delete/refresh/query operations to a database of tagged records. Rob outlined several issues that the Internet-Draft does not yet cover; examples include defining identifiers for common schema elements, integration with DNS (seen as way to find User Location Servers), and security. Eve provided an overview of a multicast-based user directory she has developed. Goals of the effort are to enable a simple method for registering user communities, combine dynamic and static approaches of session management, and take advantage of other user information on "closeness" to bound scope of media relations for sessions. This user directory employs an announce/listen paradigm - everyone using same multicast addr/port is loosely bound; the scope of reception of the user announcement also defines the scope of reception of the session itself. Eve has implemented a prototype which will be released with the next release of MMCC. No specific action items were generated as a result of these two talks. It was later identified by the chairs that this topic is of interest to the working group and that a more thorough review of the problem area and options for providing such a service (e.g., based on already-developed Internet protocols) was needed and will be scheduled as an agenda item for the next IETF.
Eve Schooler (Cal Tech) presented the motivations for and specifics of the Session Invitation Protocol (SIP) (sip.3.96.ps). This protocol is targeted to complement the advertisement mechanism provided by tools such as SD and SDR by enabling the joining of users (as compared to users joining a session address). It can be used in the context of both tightly- and loosely-controlled sessions and is intended for transmission among peer user agents (or proxies for them). SIP uses SDP as a means of describing the sessions for which an invitation is being issues. It is meant to be conveyed over UDP and is therefore minimally stateful -- request/response pair messages are mandatory, but progress reports and acks are optional. Issues regarding the choice of transport mechanism of UDP as compared to TCP or remote procedure calls were discussed, and set-up delay imposed by timer-based retransmissions were discussed.
Henning Schulzrinne (Fokus GMD) presented the motivations for and specifics of the Simple Conference Invitation Protocol (SCIP) (scip.3.96.ps). This protocol is also aimed at complementing advertisement mechanisms but was developed with an eye towards supporting telephony functionality. The models and goals of the two protocols are similar, but SCIP can be contrasted with SIP by its use of TCP as a transport mechanism, leveraged use of HTTP and SMTP, and use of an alternate session description format (i.e., not SDP), etc. Some discussion on UDP vs TCP (T/TCP) vs RPC etc. occurred but no resolution was reached regarding a choice of a single transport mechanism for conveyance of an invitation protocol. It is expected that discussion of issues will be carried on the group's mailing list and an effort to resolve differences between these two approaches will be undertaken.
Carsten Bormann (Univ. Bremenn) provided an overview of the Simple Conference Control Protocol (SCCP) which is a protocol between conference control agents (horizontal) for orchestrating tightly-coupled conferences (sccp.3.96.ps). The protocol is intended to support managing a membership list including per-member capabilities, application/media sessions, floor control, and conductorship. It does not duplicate session advertisement or invitation functions and supports session control only. The protocol distinguishes protocol structure and protocol semantics (a document describing the latter was proposed as a complement to SCCP), and is intended to support bridging to T.120. Design goals for the protocol included simplicity and generality, but scalability to "large" groups (e.g., IETF broadcasts over the Mbone) was excluded. No discussion regarding the protocol occurred in the meeting due to lack of time. The draft document circulated informally to the mailing list will be revised and submitted as an Internet-draft.
Jim Toga (Intel) provided an overview of the ITU H.323 protocol and highlighted its ability to operate over the Internet (h323.3.96.ps). Specifically, H.323 supports having two (or more)
H.323 terminals be interconnected by an IP cloud. It supports the establishment of tightly-controlled conferences which can be centralised (hub) or distributed (peer-to- peer). H.323 is based on family of ITU protocols and interoperability among them is important. Thus the standard contains many guidelines for inter-operation via gateways. No discussion regarding H.323's use on the Internet and potential impact on protocols being developed by this group occurred due to lack of time. This will be carried on the mailing list.
Ed Ellesson (IBM) provided an overview of Internet Telephony and highlighted the impact on conference control as well as other IETF- and Internet-related areas (AVT, Integrated Services). Ed proposed questions such as whether solving issues regarding the lack of interoperability among the Internet Telephone tools was the purview of MMUSIC and pointed out that regardless, these tools in widespread use would have a significant impact on traffic congestion on the Internet. Ed offered to bring Internet phone vendors into the IETF for joint discussions on this issue. Discussion regarding the seemed mismatch between the bandwidth most Internet Telephone users have (e.g., 14.4 kb/sec) and the size of Internet protocols, whether the Internet should work to accommodate this type of traffic flow (Vs emphasise its ability to carry multicast traffic), etc. occurred. No specific conclusions were reached in this meeting.
Reported by Steve Casner
The primary output of the AVT working group is the Real-time Transport Protocol. With the publication in January of the RTP spec as RFC1889 and the companion RTP profile for audio/video conferencing as RFC1890, it appeared that the group's work was completed except for progressing RTP from Proposed Standard to Draft and full Standard status. As a result, the group did not meet at the 34th IETF in Dallas and initially there was no meeting planned for this IETF.
However, in a discussion on the group mailing list, several people brought forth topics appropriate for presentation to the group:
- Proposed new RTP payload formats
- RTP and Mbone monitoring
- RTP header compression for low bandwidth links
- Fostering industry adoption of RTP for interoperability
This meeting consisted of several presentations on these topics plus some miscellaneous issues as described below. These topics will be discussed further in Internet-Drafts and on the mailing list.
1. Proposed new RTP payload formats
In addition to RFC1889 and 1890, there are four drafts awaiting publication which define the RTP payload formats for H.261, JPEG, MPEG and CellB video encodings. At this meeting, three new payload formats were proposed. In addition, to accommodate hierarchical encodings, changes to some rules stated in the main RTP spec were also proposed.
1.1. RTP changes to support hierarchical encodings
Michael Speer from Sun Microsystems presented an overview of hierarchical (or layered) encodings and a proposal to adapt RTP to better accommodate them. Hierarchical encodings break the media stream into an ordered collection of layers. The base layer provides a complete but low-quality signal that may be enhanced by composing it with additional layers. Receivers adjust the number of layers received to avoid exceeding the network bandwidth available or the receiver's own processing power. The layers are sent on separate IP multicast addresses so that multicast routing can prune the distribution tree separately for each layer.
To keep track of the ordered collection of N layers, it is proposed that N consecutive multicast addresses and 2N consecutive port numbers be allocated (ports are used in pairs for RTP and RTCP). For unicast, the single address would be used for all layers. This convention does not impact the specification of RTP itself.
Two changes to RTP are proposed: 1) to use the same SSRC ID for all layers from a given source and perform conflict resolution only on the base layer; and 2) to omit the RTCP SDES information (including CNAME) for all but the base layer, since it would be redundant. RTCP RR and SR packets would still be sent separately for each layer because that information is independent.
RTP already allows a source to use the same SSRC ID in separate sessions, but does not guarantee that the ID will remain unchanged due to collisions. If conflict resolution is done only in the base layer as proposed, should BYE packets still be sent in the other layers?
A key question for RTP is whether omitting the CNAME for the enhancement layers would unreasonably impair the operation of third-party monitors that were not aware of the association of the N layers. Another question is what impact this consecutive multicast address allocation requirement would have on the allocation schemes such as SDP/SDAP (discussed in the MMUSIC working group). Assuming successful implementation and testing of this proposal and no technical objections, it is expected that the proposed changes will be incorporated into the RTP spec when it is revised for the transition to Draft Standard.
1.2. Payload format for H.263 video
H.263 is a new ITU-T Recommendation for video compression. It is similar to H.261, but includes optimisations to support lower bit rates. An RTP payload format for H.261 has already been defined and is currently in IESG Last Call before publication as an RFC. It is not possible to use the H.261 payload format directly for H.263 because more bits are required to specify the macroblock address, the additional motion vectors for Advanced Prediction, and the additional fields for decoding interleaved "PB" frames.
Chunrong Zhu from Intel presented a proposed payload format for H.263 that copies some fields from the H.261 format and adds more. To support all options of H.263 requires 10 bytes of payload header compared to 4 bytes for H.261, but fewer bytes are required when some of the options are disabled. Therefore, three different modes A, B and C are defined, each with a different payload header size (4, 8, and 12 bytes, respectively, to maintain 32-bit alignment). The three modes may be intermixed in a single stream to maximise efficiency as
allowed by the data observed.
The only significant question raised regarding this proposal was whether the additional complexity compared to H.261 is justified. Note that a packet format with optional fields requires extra tests in the data processing path and makes optimisation difficult. It also increases the likelihood of bugs. However, in this case, the smallest form of the payload header can only be used when a GOB will fit within a single RTP packet. The GOB size will often exceed the network MTU, so the larger forms of the payload header are required as well. The only way to simplify the format is to require the maximum size header be used all the time. This would be too inefficient, especially at low data rates. Therefore, the proposed design appears to be the reasonable compromise.
Comments from the working group are sought both on technical aspects of the design and on the completeness and clarity of the specification. Assuming successful implementation of the H.263 payload format specification, the draft should be submitted for publication as an RFC.
1.3. Payload format issues for redundant encodings
Mark Handley from UCL gave a presentation about work at UCL and INRIA to improve audio quality in the presence of packet loss through redundant encodings. The idea is to piggy-back one or more highly compressed redundant encodings of the audio data onto later packets of the primary encoding. That way, if a packet of the primary encoding is lost, a lower-quality version of the missing audio can be reconstructed from the redundant encoding in the later packet.
What's undecided is how to carry the redundant payloads in RTP, since RTP was only designed to carry a single payload. Three ideas were proposed:
- Put the redundant data in an RTP header extension (there are several problems with this idea so it is disregarded);
- Define a set of dynamic payload types to indicate the combinations of primary and redundant codings to be used in a session (this has the lowest overhead but allows at most 32 combinations);
- Define a single (static?) payload type that indicates redundant encodings, then in the payload section construct a chain of type-length-value blocks where the type is a normal payload type, the length is a one-byte field, and the value is the audio data. The presence of additional blocks is indicated by setting the MSB of the type byte. The primary encoding would come last and would have no length field so it is not constrained to a length of 256 bytes.
The INRIA and UCL teams differ on the choice between the second and third schemes, so advice is sought from the working group. No clear-cut deciding factors were identified in the meeting. As the work progresses, it is expected that a draft leading to one or more new RTP payload format specifications will be produced.
1.4. Payload format for ASF streams
Tim Kwok from Microsoft gave a preliminary presentation on a new proposal for "Active Stream Format" that is about to be introduced by Microsoft. ASF is a multiplexing scheme for audio, video, images, scripts and URLs that is intended to serve for both storage and transmission. Microsoft is seeking input on how to packetize ASF in RTP, and would also like to include in ASF a format that can record a collection of RTP packet streams constituting a multimedia session.
Only a few details were presented since the announcement of ASF was to be made the next week and therefore the document describing it was not yet available. ASF is a "framework" that can include filters for translation between storage and transmission formats. It is intended to be transform independent, and will provide a variety of error concealment methods. One question is how these error concealment methods can be co-ordinated with the RTP layer.
The proposal was that an RTP payload type be allocated to indicate a multiplexed ASF stream. One motivation claimed for multiplexing in this manner is that it simplifies synchronisation. However, this goes against the RTP notion that streams should be sent separately to allow receivers to select among them and synchronise the chosen ones using the timestamps provided in RTCP SR packets. There were several comments from meeting participants who questioned the motivation for multiplexing. Perhaps the strongest supporting reason is that high volume multimedia servers do not have time to take apart stored media and construct separate RTP streams.
Greg Minshall summarized the WG sentiment: the participants have a number of questions about the proposal, but would like to hear more details. Microsoft is to produce a draft proposing an encapsulation of ASF into RTP after the ASF document is available, and then this proposal will be discussed further in the working group.
1.5. Using dynamic payload types
Steve Casner presented one slide as a reminder to implementers to include support for dynamic payload types. Creators of new payload formats have asked for static payload types to be assigned, but the 7-bit space is not large enough to define a type for all who might request one. Instead, new encodings should be tested using dynamic payload types and might later have static types assigned if they prove to be important for inter-operation among implementations.
The RTP A/V Profile (RFC 1890) defines payload types 96-127 to be dynamic per session. The mapping between these types and format descriptions in a larger space is conveyed in a session protocol. For example, the SDPv2 spec under development in the MMUSIC WG provides this function. It may be appropriate to register the format names to be used in that larger space, but that is not strictly an RTP issue since the names are carried in session protocols.
2. RTP and Mbone monitoring
As RTP begins to see more use, we need to learn how RTCP feedback can help in the operation of applications and general monitoring of the Mbone. Steve Casner introduced the topic with a slide listing the information provided by RTCP: participant descriptions, packet loss and jitter as seen by all receivers, and propagation delay from the sender to each receiver. This information may be combined with route mapping data to produce a graphical display, as Paul Stewart did a year ago in his msessmon program. Now mtrace could be used to collect more accurate routes.
2.1. Tracking session participants
Kevin Almeroth and collaborators at Georgia Tech have implemented a tool called mcollect to gather statistics about participation dynamics in Mbone sessions. This program does not yet make use of the content of RTP or RTCP packets; instead it measures the start and end times of participation in a session based on source host addresses. A number of interesting observations of user behaviour, such as "session surfing" and significant variations in connection patterns for different types of sessions, were observed. Kevin posed as an open issue the question of how to take advantage of the information carried by RTCP.
2.2. Using RTCP feedback
Andrew Swan responded to a last-minute request to say a few words about work at UC Berkeley on using RTCP. He pointed out that many interesting events have been transmitted on the Mbone, but that we still need to be able to better diagnose problems in the multicast distribution. RTCP feedback will be an important part of the solution.
Collecting feedback with RTCP is easy. The hard part is figuring out how to analyse and present the information. The first idea, for example in presenting the loss rates seen by all receivers, is a table. But how should the table be sorted? Work is underway to implement and test different techniques, and will be presented in more detail in the future.
3. RTP header compression for low bandwidth links
Internet Telephony is a rapidly growing application, but the commercial products do not use RTP. Part of the reason may be that they were developed before RTP was published as an RFC, but another factor may be the bandwidth overhead imposed by RTP. Even though minimising overhead was a key consideration in the design of RTP, for very low rate audio the 12-byte RTP header may still be a problem.
Scott Petrack of IBM and Ed Ellesson of IBM have proposed that the working group define "C/RTP", a compressed-header form of RTP. Before the meeting, they sent a preliminary draft to the mailing list outlining a framework for C/RTP including examples of compression techniques that might be employed. Scott gave a presentation on these ideas at the meeting.
To motivate this effort, Scott provided a calculation showing that latency due to packetisation delay increases linearly with packet header size when bandwidth is constrained. That is because one must increase the packet size if the header size is increased in order to keep the overhead ratio constant and not exceed the fixed bandwidth limit. Since highly compressed audio signals may use frames on the order of 24 bytes, the 12 bytes of RTP header (plus 28 bytes of Ipv4 and UDP headers) are a significant overhead. Frames are generated every 20 or 30 milliseconds, and to minimise latency it is best to send only one frame per packet.
A variety of techniques for compressing the header size were proposed. Constant information such as the payload type and SSRC ID may be omitted if shared state can be established via some form of reliable communication (out of band). However, note that these values are constant only if the payload format is not changed and if there is only one source sending on the session (e.g., unicast). Some fields that are not constant may change by fixed amounts for contiguous packets, depending upon the media. It seems likely that the techniques designed by Van Jacobean for compression of IP/TCP headers over SLIP links may be applicable here, though some additional mechanism would be required to take the place of the TCP retransmissions that re-establish state after an error.
One issue is whether the compressed RTP should be implemented in applications (as RTP often is) and used end-to-end, or whether it should be implemented at the endpoints of slow links, perhaps in PPP as with IP/TCP header compression. It seems likely that for RTP header compression to be effective, IP and UDP headers must also be compressed, which suggests the latter approach. However, Mikael Degermark cautioned against tying compression of all three layers into one mechanism if RTP compression depends upon handshaking between the two ends. The UDP header compression that has been designed as part of the IPNG effort works over simplex connections without a handshake.
Scott's presentation did not include a specific proposal for the C/RTP protocol, but rather was a call for the working group to take up this problem as a work item. The general sentiment at the meeting was that this would be appropriate. Comments pro or con are solicited.
Scott also offered a GSMVQ audio encoding algorithm for consideration as a format to be used with RTP.
4. Fostering industry adoption of RTP for interoperability
The first topic that was raised in calling for the working group to meet at this IETF was a discussion of what should be done to foster industry adoption of RTP. However, there was not sufficient time to organise participation in the meeting by companies other than those who have been involved in the working group for some time, so there was not a lot of discussion here. Others cited adoption of RTP in Netscape's LiveMedia initiative and in the H.323 recommendation of the ITU-T as evidence that the industry is already paying attention to RTP. None the less, there may be issues such as the need for header compression that are industry concerns. It was suggested to try organising for more industry participation at the next IETF in Montreal.
One proposal was to sponsor a Connectathon-like event to test inter-operation and conformance. Ross Finlayson countered that it should not be necessary to organise an event in one place for this. Instead, interoperability testing should be conducted across the network.
5. AVT working group logistics
It became apparent at this meeting that there is new work that should be addressed by the AVT working group, and that AVT should continue to hold separate sessions at IETF rather than merging with MMUSIC. In particular, it was agreed that AVT should meet in Montreal. The new work includes:
- Additional payload format specs, as presented in this meeting
- RTP header compression
- Should there be an interface service definition for RTP?
- Extending RTP for applications other than audio/video
On this last topic, during IETF week a new draft on "RTP extension for Scalable Reliable Multicast" (draft-parnes-avt-srm-00.txt) was posted to the mailing list by Peter Parnes from LuTH/CDT. Everyone is encouraged to read that draft.
Since Vat's initial charter has been completed, this new work needs an updated charter. The chair will prepare a revised charter for comments.
6. Miscellaneous issues
Steve Casner brought up one last issue before adjourning the meeting. In Section 8.2 of the RTP spec, an algorithm is defined for detecting collisions of SSRC ID allocations and loops induced by RTP mixers or translators. As defined, that algorithm will work properly only if sources use the same UDP source port number (not destination port number) for both RTP and RTCP packets in a session. However, not all implementations of RTP do that; the VAT and VIC programs from LBL are counter examples. The algorithm can be modified to allow the ports to be different, at the cost of potentially locking on to the RTP packets from one source and the RTCP packets from another. On the other hand, some people have expressed the opinion that the algorithm is too complicated and hard to test (because collisions should be very rare). This is one area in which implementation experience is needed to determine what changes, if any, should be made before the transition of RTP to Draft Standard.
Due to time limits, there was no discussion of this topic at the meeting. Steve Casner intends to write an informational RFC on the issue so that implementers of RTP can be aware of it.
Notes on the MANICORAL/MERCI Liaison Meeting, UCL, 15 July 1996 issued by D.A. Duce 18 July 1996
PRESENT: C.S. Cooper D.A. Duce J.R. Gallop D. Giorgetti K. Robinson C.D. Seelig
R. Bennett M. Handley V. Hardman P.T. Kirstein C. Perkins
RAL circulated a background paper (MANICORAL Note 26) prior to the meeting, summarising experience with the MERCI toolset in the MANICORAL project to date, and identifying a number of topic areas for discussion. These were taken under the following headings.
By way of introduction, David gave an overview of the current state of the MANICORAL project and initial views on the architecture.
1. Chris Cooper explained that the need for audio support for multiple users at a single workstation had arisen naturally in the project. In addition, not all potential users have access to their own MERCI compatible workstation. If 2 or 3 are gathered around a workstation, should we be looking at the use of good quality speakers and individual microphones, or should everyone have a headset? Mark Handley suggested the use of echo cancellers if funds permitted. A small echo canceller costs around £2,000. UCL have found that silence suppression does work with good quality microphones, but a site with a poor set-up can wreck a whole co-operative session. The smaller the session, the better the chances of success.
2. Headsets with open ear muffs can be purchased, and also single ear headsets. These would allow local participants to engage in local conversations.
3. It was suggested that RAL should have a pool of audio equipment which other sites could borrow, in order to experiment.
4. UCL have moved towards individual headsets and find these very satisfactory.
5. It is possible that some form of echo cancellation will be provided in software in the future, but it is very expensive in terms of cpu load.
6. Vicky suggested that one could use a local PC in order to support additional audio inputs at a site.
7. Measurement of perceived audio quality is regarded as a future research topic. With experience, one can cope with higher packet loss. UCL are starting to look at adaptive transmission strategies based on an estimate of the packet loss at the receiver.
8. UCL feel there is a reasonable correlation between audio quality and packet loss rate. Mechanisms exist for obtaining packet loss rate. Ken suggested adding an audio quality indicator to the rat tool (e.g. in the form of red/ yellow/ green lights) to give an indication of the audio quality being received at each site, in order that users may adapt their presentation style accordingly. UCL will look into this.
9. UCL are planning another release of rat in about 1 month's time (version 2.6). This uses a packing format that is incompatible with the present release. N o further major incompatibilities are envisaged in the foreseeable future developments.
10. The approach taken in the MERCI consortium is that MERCI software is released publicly at intervals which the developers decide. This allows rapid feedback on innovations. A stable version is specified as a "MERCI deliverable" at the appropriate time. It was agreed that in order to handle version control within the MANICORAL project, new releases of MERCI software will be taken by RAL in the first instance. RAL will then handle distribution to the remainder of the MANICORAL project.
11. Ken suggested adding a level control to silence suppression. The silence suppression mechanism is adaptive, but the limits are rather arbitrary and there is no control over them. It was suggested that this topic be postponed until sites have been able to try out rat.
12. Mechanisms for dealing with "audio hogs" were discussed. It may be appropriate to address this at the session control level. Mark pointed out that blipping the microphone, which causes the owner's name to be momentarily highlighted, can be an effective way of indicating that someone else wishes to talk.
13. Vicky Hardman commented that the ReLaTe project (UCL project on use of MERCI by language teachers) worked in the audio continuously open mode. This gives more verbal cues than push to talk. Experience showed that people learn to give more verbal feedback in order to compensate for loss of non verbal cues.
1. Video performance over the local area network at the Graz workshop was sufficiently poor that participants made little use of it.
2. UCL commented that they tend to use video as an indicator of presence. Is the person I want to address my next remarks to still there?
3. Video was the first service the AFRICAR scientists would sacrifice. For the HCCC groups, the issues are somewhat different.
4. Video also gives the problem of sharing attention between video tool and other tools.
5. UCL are looking at automated window management on top of the tools (Jane Hughes et al.). Users would be able to select from a range of policies. This approach was used to good effect in the ReLaTe project.
6. Approaches to supporting lip-sync were developed in ReLaTe. It is worth thinking about for video rates > 6 f.p.s. Support is provided in rat (not vat), and a modified VIC (unfortunately it is not in the current version of VIC). The developers of VIC (Steve McCanne and Van Jacobson) have to do the integration of the code changes in VIC, it is not clear what their plans are to do this for the latest version. The mechanism is based on synchronising adaptive audio and video playout buffers. The problem is that VIC, by default, does not have an adaptive buffer and the changes are needed in order to add adaptive buffering.
7. It was noted that Steve Casner now has a company developing and marketing tools in this area.
RAL explained that the issues raised by the whiteboard should be understood as identifying requirements. It was understood that UCL were not in a position to make any modifications to the current whiteboard tool.
1. It is believed that Van Jacobson has plans to move wb from the current Interviews UI interface to tcl/tk and to reimplement the protocol on which it is based. It was felt that it is very unlikely that the source code of the new version would be released.
2. The protocols on which wb is based are not standardised. The protocols used by VIC, RAT, etc. are/have been standardised in IETF.
3. Mark pointed out that the ITU T.120 protocol suite has a whiteboard protocol (T.126). Although the T.126 standard itself is not appropriate in an MBONE environment, MERCI are considering writing a tool which will be able to interwork with T.126 standard applications via a gateway. T.126 includes bitmap images. INRIA and Stuttgart are involved in this. It is anticipated that this will be addressed in the second half of 1996. Mark is interested in defining a protocol that will serve as a foundation for the construction of a shared whiteboard, however, his imminent departure to a new post at ISI will, at least temporarily, impede this work. Details of T.126 appear at http://www.itu.ch/itudoc/itu-t/rec/t/t126_31814.html
4. Julian presented our thoughts on distributed co-operative visualisation and the approaches we have considered.
5. Mel Slater joined the meeting briefly and discussed his research projects o n shared virtual environments and VRML.
6. Mark favoured an approach based on a protocol for sharing generic objects, but no such protocols currently exist and there is no open whiteboard or open network text editor (NTE) around as yet.
7. There are currently no draft standards in IETF for reliable multicast, though there are many proposals around, all of which have more, or less, severe limitations. Mark commented that there is mounting pressure for a reliable multicast protocol, though there are still research issues to be addressed in this area. It is likely that a standard will have to emerge more quickly than is desirable.
8. Mark stressed that the requirements for shared applications are vastly different from the requirements for multicast file transfer. He described some systems and proposals that have appeared in the literature. rmp (for which a code library is available; Chris Seelig has obtained this) has inherent scalability problems; it relies on establishing absolute agreement about the membership of a session and forms a token ring from the people in the session. The best proposal is probably Van Jacobson's srm. The principles of the protocol are explained in a SIGCOM `95 paper, but there is no publicly available implementation. There is work at INRIA that has tried to take a generic approach (Walid Dabbous). There is a protocol called mtp.2 developed by Borman et al, either in Bremmen or Berlin which is likely to be good, but there is little in the literature about this yet. Mark's NTE uses a protocol tailored to the needs of NTE and the protocol rather permeates the structure of the code. Starburst also have a protocol, but this is oriented towards bulk data transfer.
9. Peter suggested holding a technical meeting in the autumn to address the issues of whiteboards, involving MANICORAL and the MERCI partners working in this area. This was felt to be a very good idea.
1. Encryption can be used with VAT, VIC and a version of RAT. It is believed that WB may contain encryption code.
2. The session announcement protocol does provide some support for encryption, but the facilities are not fully worked through.
3. When encryption is used, the tools will refuse non-encrypted data.
4. It is expected that tools with more secure features will be included in the September release.
5. The sdr tool supports Session Invitation. The invitation mechanism can address some of the problems identified in MANICORAL; the mechanisms are not very user friendly, but they do work. It was suggested that MANICORAL should look into using this.
1. The MERCI multimedia server will provide streams interface and indexing. Information can be located by relative time along a time track. The server looks like a multicast workstation.
2. Tools need to be stored with multimedia formats; retrieve returns information and the tools to present it.
3. There are plans to improve the user interface to the server.
RAL explained their interest in web-based CSCW tools and gave UCL a draft copy of a survey paper written by Daniela.
1. The JAMES contract has now been signed and documents have been issued. The procedures for gaining access to JAMES are not completely clear, but the starting point is the completion of a user description form. Peter has drafted a form for all the MERCI partners and the more active MICE National Support Centres. Peter would be happy for MANICORAL to submit a user description for MANICORAL and link it to the MERCI description. The topology of the proposed usage by MERCI is shown in the diagram below. The links to Italy and Austria are provisional. The UCL-Amsterdam-Stockholm link is a current production link, not a planned ATM link. The only overlap between MERCI and MANICORAL is UKERNA/RAL.
2. It was suggested that MANICORAL should await the reaction to the MERCI document before submitting its own proposal. There are a number of areas that are unclear, for example, links from local sites to Public Network Operators (PNOs) and the meaning of funded/non-funded on the user description form. At present links are planned between Austria (Linz), Stockholm, UCL, Amsterdam, Stuttgart, Italy and Oslo.
Chris Cooper explained the initial ideas on how to link Greece through BRI ISDN.
UCL suggested an alternative approach in the medium term. UCL are working on a mixer that will do bandwidth conversion and video switching for general transfers between mismatched networks. Using this approach, one can unicast to a mixer at an MBOne capable site. UCL aim to have this working by the end of the year. RAL indicated that they would welcome the opportunity to take part in experimental use of such a device.
The question about MBONE hop counts on the Graz tunnel needs to be referred to Magnus. It was agreed that RAL will send a message to Roy and Mark outlining the situation and they will forward it. There was agreement that the provider of the Graz MBONE tunnel has configured it incorrectly.
Angela Sasse was unfortunately unable to attend the meeting, but asked that MANICORAL be informed of her wish to collaborate with the MANICORAL HCCC groups on evaluation issues. She wondered, for example, whether she might be allowed to observe a MANICORAL session. The RAL participants commented that they were certain the HCCC groups would be very pleased to explore areas of mutual interest with Angela. It was suggested that the best way to progress this would be for Angela and Janni to communicate directly. Janni's email address is janni.nielsen@cbs.dk.
UCL said they would be very happy to set up networked technical meetings with RAL and other interested MANICORAL partners. RAL appreciated the offer and will take advantage of it as the need arises.
The 36th IETF, Montreal, June 24th-28th 1996
Peter T. Kirstein and M. Handley
University College London
At the 36th IETF meeting in Montreal, the MERCI project was again strongly represented. The IETF working groups directly relevant to the MERCI project are Audio/Video Transport (AVT), Multiparty Multimedia Session Control (MMUSIC), Inter-Domain Multicast Routing (IDMR) and Multicast Backbone Deployment (MBONED), Integrated Services (Intserv), Resource Reservation Protocol (RSVP), and Public Key Infrastructure (PKIX). Each is discussed below.
AVT
The majority of the AVT working groups time was taken up with discussion of several proposals for RTP header compression. This is important if RTP is to be used over very slow links such as 28.8Kbps modems, where the overhead of packet headers reduces the effective bandwidth available and increases latency. Two proposals were presented, one related to RTP compression only and the other related to combined IP,UDP and RTP compression. The latter appears to have much more merit, and the working group agreed that this should become a working group action, and be taken forward.
Walid Dabbous and Mark Handley presented the redundant audio encoding technique and payload format developed by UCL and INRIA. Mark Handley described the payload format used for redundant audio as defined in draft-perkins-rtp-redundancy-00.txt. This payload format is to be indicated by a single payload type of its own in the RTP header. Then, in the payload section of the packet, a separate block header is included for each encoding (original data and redundant encodings of earlier data). The block header includes the payload type of the individual block, the length of the block, and the offset of the timestamp for that block relative to the timestamp in the main RTP header. The original data occurs last and its block header includes only the payload type. The length is implied and may be greater than would fit in the 8-bit length field of the block header. No timestamp offset is needed since the RTP timestamp is used directly.
Various variations on this basic scheme were discussed, though most were of no great merit. One variation was proposed by Philip Lantz (Intel) which moves the encoding block headers together to the start of the packet. This decreases packet processing times. Since the IETF this proposal has been tested, described in a new internet draft and implemented in RAT.
MMUSIC
Many subjects were discussed in the MMUSIC session. Progress on SCIP (Simple Conference Invitation Protocol) was described by Henning Schulzrinne, GMD Fokus. Progress on SIP (Session Invitation Protocol) was described by Mark Handley (UCL). Both protocols have implementations now, SCIP from GMD and 3 SIP implementations from UCL, University of Loughborough and Intel. As there is much overlap between these protocols, time was spent discussion the design tradeoffs between the two. However, no conclusion was reached, and there appeared to be a certain amount of misunderstanding amongst some members of the audience as to the purpose of SIP. The SIP document will be revised to cure this ambiguity. A small number of enhancements to SIP were discussed. Most of these will not be included in SIP, but improved ability to handle unicast connections will be.
A new Session Announcement Protocol (SAP) draft was presented by Mark Handley. Most of the discussion here centered around the security aspects of the SAP header. As described in the current draft, SAP includes the capability to carry an authentication header. The general opinion of the working group was that this should be done by the IPSEC authentication header (possibly using the IDUP-GSS-API). This saved duplication of code but adds a whole set of additional problems when operating with IP4 as IPSEC is optional, and not yet completely defined. With IP6, IPSEC is mandatory, so this problem would not exist. The real question is what we should deploy today? No resolution was reached.
Progress on SDP has almost finished as the protocol has nearly stopped evolving. Mark Handley described a few suggested changed and why they would not be introduced in this version of SDP.
Progress on SCCP was described by Carsten Bormann.
Much time was devoted to the discussion of H.323, and its applicability to the wide area Internet. No resolution was proposed or reached - this was mostly informative. It is clear that many companies are going to implement H.323, though it is also clear that it cannot scale to wide-area large Mbone conferences, so although there is some overlap between H.323 and the other protocols discussed above, this overlap seems like it will have to be tolerated - there is little chance of changing H.323 at this stage and no chance of it solving all the problems addressed by the S*P protocols.
There were new suggestions for remote control of multimedia servers; the most interesting aspect of this is that the new initiatives came from NTT laboratories. There was little time to discuss them at the meeting, but in a session afterwards, we agreed to extend the work of the MMUSIC group to include this activity. The implications on the MERCI servers of WP7 are being evaluated.
MboneD
This is a new working group related to the problems of ubiquitous Mbone deployment. The most interesting development from this group was a near unanimous decision to disconnect any multicast router not supporting full pruning capability and mtrace diagnostics after 31st October 1996.
There was a special BOF session on multicast via broadcast satellite. This has the property that there is no reverse channel through the medium, but that a different reverse path must be set up. It was agreed that this was an interesting area, and would be addressed in future IETF Meetings. It is not yet clear into what Working Group it will fit. This area has considerable interest for MERCI because of the possible offer to INRIA by EUTELSAT to deploy earth-stations as part of an extended MERCI trial.
Intserv
Although the WG approved Guaranteed Service and Controlled Load Service to be put forward to Proposed Standard, there is still some discussion of details happening. These documents should be put forward to Proposed Standard shortly.
RSVP
RSVP version 1 is now close to being submitted to Proposed Standard status. The meeting spent some time discussing detailed changes to the current family of specifications. There should be product releases of RSVP version 1 from several manufacturers in Q4 1996. RSVP version 2 is also being worked on, though is considerably further off. Much time was spent discussing possible parts of RSVP v2.
IDMR
There is much good basic work going on in IDMR, but nothing of particular relevance to MERCI was discussed this time.
PKIX + IPSEC
This work is making good progress on the definition of many aspects of the infrastructure. However, on the fundamental question of key exchange, required for IPSEC, there is currently an impasse. One group (led by Sun) is advocating SKIP; another, led by NSA, is advocating Oakley. It is not clear that either has a real technical advantage; hence the Area Director has set up a working party to try to resolve the issue.
Part B - Future project plans
Complete either B.1 or B.2
B.1 For those projects whose contracts extend into next year please follow the following guide-lines. Use existing Project Programme forms where appropriate (see "Hands-out for the preparation of the Annex 1 - Project Programme to the Contract", available in electronic format on Web: http://www2.echo.lu/telematics)
B.1. 1 Summary
Give a brief description of the main work to be carried out in the following year and any significant changes to the overall project programme.
Here we briefly describe the coming year's work under the following heads which, in some cases, group workpackages together.
This is the work of WP5. We have a detailed work plan for this work to which we will adhere.
The first version of the operational MBONE / H.323 Gateway and of the Session Controller will be available for the second MERCI software deliverable in month 15 of the MERCI project. This will provide the basic gateway functionality and allow one MBONE Terminal to communicate with one H.323 Terminal.
A first version of the H.323 / H.320 gateway will also be available at that time so that one MBONE terminal will be enabled to enter one H.320 conference.
Subsequent work will then concentrate on the integration of security facilities and on an enhancement of the MBONE / H.323 gateway in order to allow more than one MBONE terminal to enter an ITU-style multimedia conference at a time. The corresponding enhanced versions of the MBONE terminal and the Session Controller will be available for the third MERCI software deliverable.
We expect also to investigate the feasibility of providing transcoding modules at the gateway; this should incorporate the more sophisticated codings provided for the Mbone in WP3.
We have completed both the Security Architecture, and the securing of the Basic tools; we have not yet developed the details of secured session announcements and invitations. We have mechanisms we can deploy in an ad hoc fashion; we must still get them agreed in the IETF. Our current aim is to complete a draft proposal to the IETF by the December meeting, and have an agreement on most of the details by the April meeting. In line with the way the IETF operates, we expect to have an implementation in place also by April - meeting the Deliverables schedule originally envisaged. Hence we should be able to have significant experience of easy-to-use secure conferencing during the last few months of the present project. We will also add secure authentication to remote operations on the Servers, which will greatly improve its acceptability.
While a pure Mbone architecture would probably use the SDR Session Announcement and Session Invitation mechanisms, the ITU world is developing a separate Session Reservation suite. The Mbone version should be largely agreed in the next few months; agreement on the ITU version will probably take significantly longer. In the interim, we can expect to see secure sessions announced between the two communities by one of two devices:
The exact form of secure directory or mail does not concern us in the MERCI project. However, the ICE-TEL project has agreed to concentrate on secured WWW access for WWW data, and on S-MIME for secure message systems, hence we plan to use their applications for an interim key distribution system. We will build interfaces to one or the other of these two to start our conferencing tools.
During the next year, we plan to deliver two further sets of software. The first, D1, due in month 9 of the project (August, 1996), will include the new Session Directory (SDR) and secure versions of the tools VIC (video), RAT (audio) and NTE (shared text editor). In D2, due in month 15 (February, 1997), we will deliver versions of the tools operating on PC platforms with Windows95 and NT operating systems. Subsequently we will deliver higher-quality, secured versions for all platforms. The higher quality video tools will incorporate wavelet encoding codecs and will interwork with the wavelet codecs to be implemented in VIC.
There are three major validation workpackages which will contribute to the work of the next year. In addition we will continue to get feedback from the tool evaluation aspect of Workpackage 4 and the feedback in our use of the tools for our management meetings. Taking each of these in turn:
We plan to continue our series of seminars and to increase the use of network analysis combined with user reaction questionnaires to evaluate the efficacy of both the tools and their use as a teaching medium. We anticipate a concrete contribution from CRC when they join us as partners.
The first of the two planned workshops has been postponed until February, 1997. This may prove beneficial if we are then fully linked on the new high-speed networks of JAMES and TEN'34. We will deliver an additional workshop in September, 1997 as planned.
Since the formal agreement was set up between Deutsche Telekom AG in Germany and MERCI contractor GMD to carry out commercial trials with MERCI tools at Telekom premises, user tests have only been done with audio and WB tools. Extensive trials have been arranged for the third quarter of 1996 to test the full range of tools and further developments in their use are expected to follow from these trials.
We plan for further feedback from our users, both external and within our sponsoring partners. With the additional work to be done by CRC, we anticipate performing detailed studies of the user interface in use by real users and also a correlation between actual network conditions and user perceptions of quality.
We provide underlying support for the following wide-area network technologies: N-ISDN (EuroISDN), B-ISDN (ATM), native IP (both over SMDS and point-point circuits). Our expectation is that , with the deployment of JAMES, we will soon be able to begin work again on ATM. We will provide software/hardware facilities for the different networks, but also deploy them in a seamless and concatenated way for our validation WPs, and provide guidance on when to employ which network.
The MERCI multimedia applications make heavy demands on the underlying network technology. To provide such services effectively, it is essential to measure QoS broadly, and provide suitable management facilities. We expect to take delivery of OpenView network management software donated by our sponsor, Hewlett-Packard. With this software, and newer generic, application-independent multicast monitoring tools based on the IETF Real-time Transport Protocol (RTP) such as Mview, we will be equipped for fault diagnosis, debugging and performance analysis of the Mbone infrastructure which is used for the multimedia conferencing service. The measurements tools will be demonstrated in D2, due in month 15 of the project.
Having upgraded existing conference and lecture room in KTH and UiO to include flexible facilities for conferencing, we plan to upgrade a conference room and a lecture room at UCL during the next year. The conference rooms will be demonstrated by being used both for the MERCI seminars and in the weekly project meetings. Some of these rooms have been deliberately over-provisioned to ensure that we are able to institute a good review on how to ensure high quality presentations.
As part of D2, we will demonstrate a completely working medium performance conference room; a high performance example will be available as part of D3 in month 21 of the project.
We will adapt the IETF RSVP WG bandwidth reservation mechanisms as they become available and integrate them into our conference set-up mechanisms and tools. The session description protocol used by SDR will continue through the stages of the Standardisation process in the IETF Multi-party Multimedia Session Control (MMUSIC) working group.
Booking, in the context of a set of linked conference rooms, is also a requirement and we will investigate whether existing protocols such as SNMP can satisfy the requirement for Standardisation and distributed implementation; we will specify a protocol, and will try to introduce it both in the IETF and in our own institutions.
The "session directory" protocol still needs a number of enhancements and we shall continue to participate within the IETF in its update and Standardisation. We will define mechanisms for the distribution of encryption keys needed for secure conferencing.
We plan to implement a gateway to allow the automatic set-up of transcoders and multiplexors at appropriate places in the network so that we can distribute multiplexing functionality. The enhancement of CCCP (Conference Control Channel Protocol), now being pursued through the IETF, should also allow relevant conference control information to be made available to multiplexors and transcoders as required.
During the next year we aim to deliver a multimedia server with the following features as part of D2, due in month 15 of the project:
The ability to provide authentication and privacy for providers and users of the service, which we have identified as a requirement, will be developed during this time, but not delivered until D3, due in month 21 of the project.
At UCL we will soon take delivery of an NT server provided by our sponsor, Hewlett-Packard, which we intend to use to evaluate the media on demand software of Starlight systems.
We will continue to work closely with ICE-TEL and MANICORAL and plan to increase our contacts with CoBrow. The latter two projects will be in the position of users to MERCI and we will continue to seek feedback on the usability of the new and enhanced tools which we plan to give them. From ICE-TEL we expect to get access to their European security infrastructure and use it to meet our objectives in securing our conferencing.
We plan to continue our close association with SCIMITAR, and through it, and the concertation events which it will organise, we will keep in touch with the other projects in the TELEMATICS for Research programme.
B.1.2 Update of the project programme
Description and diagram of the work breakdown structure
Description of the work breakdown structure
WP1 Management
This work-package deals with all aspects of the management of the project. It is entirely the responsibility of the Co-ordinating Partner. Both the Project Director and the Project Manager will be heavily involved.
WP2 Activity with External Groups
This work-package is concerned with all aspects of relationships with other groups. This includes concertation activities like the SCIMITAR project and anything else set up by the Commission. It also includes the three other groups with whom we have a particularly close relationship: MANICORAL, CoBrow and ICE-TEL. We try to ensure common interface specifications between the projects, co-ordinate deliveries of software between them, feed back an assessment of the quality of the deliverables, and ensure that the feedback is properly progressed inside the projects. Other activities include managing the interface between the project and other communities such as the relevant Standardisation bodies such as the Internet Engineering Task Force (IETF), the ITU Standardisation bodies, etc. We also relate to the various user groups in other programmes with similar needs.
WP 3 MM Conference Components and cross-platform support
This work-package is concerned with the development of the fundamental multimedia components: video, audio and shared workspace. Most developments represent improvements from the MICE components, but at least one new video tool will use a different coding scheme, and a shared whiteboard tool will arise from the MANICORAL project. Another aspect of the work-package is to ensure that the tools work on different hardware and software platforms.
WP4 Usability and Assessment
It is important to ensure that the developers really understand the user requirements, that the user interfaces are really user-friendly and that there is a proper evaluation of the tools produced. The work-package will serve as semi-independent activity between the developers and the users. It is no coincidence that it is in this work-package that Shell Research Limited, one of our sponsoring partners, intends to participate at its own expense.
WP5 Interworking
Of particular concern is the current split between the computer-based and the communications-based conferencing - and also that based on workstations versus that based on PCs. This work-package is concerned with addressing both these elements - and so is naturally led by an industrial partner. For some tools, this requires coding adaptation; for others, it requires inter-working units.
WP6 Network Support
Only too often the tools are integrated, unnecessarily, into the network support foreseen by the supplier. In the MERCI project we envisage a variety of interconnected networks: LANs, Packet-Switched Networks, SMDS, ISDN and ATM. This work-package is concerned with ensuring that the tools work over these different networks, and to provide interworking units to ease their operation across the different technologies.
WP7 Multimedia Server
Multimedia conferencing embraces much more than human-human interaction; it is often very important to introduce pre-computed data into the conference, or to record information developed during the conference. This work-package is concerned with implementation, deployment and utilisation of multimedia servers.
WP8 Conference Management and Control
The set-up, management and control of conferences is essential to allow widespread usage. This work-package is concerned with providing the components to allow distributed control: booking systems, the set-up of the conference and of intermediate relays, the control of active conferences and fault diagnosis.
WP9 Conference Room Support
It is currently fashionable to talk only of workstation conferencing. In some applications there is a natural agglomeration of people in a Conference Room. This work-package is concerned with aspects particularly appropriate to the Conference Room environment: Whiteboards, use of hardware codecs and full familiarity with echo-cancellers.
WP10 Security
Many uses of conferencing require confidentiality, and the assurance that only specific people are participating in the conferences. This requires authentication and encryption of the multimedia streams. The provision of encrypted streams is a function of WP3; the provision of the security technology itself is an activity of the ICE-TEL project. This work-package is concerned with the design of the architecture for secure conferencing, the key management architecture, the participant authentication, and the provision of encryption gateways where these are required.
WP11 MERCI Seminars
Distance education is an excellent consumer of the MERCI technology. For this reason, we have organised this validation work-package to apply the tools in several distributed seminars. The components developed in the technology work-packages (WP3 - WP9), are tried out in this work-package, and the feedback used to improve the tools further.
WP12 Surgical Workshop
Another important testbed for the technology is the annual series of surgical workshops held at the Middlesex hospital. The needs of surgical teaching and demonstration are more demanding than those of the WP11 seminars. This work-package will validate the highest quality Audio-Visual facilities demanded by the surgeons, together with the security (from WP10) needed in this domain and the instrumentation data, also vital to this area.
WP13 Commercial Trials
In this work-package, we are carrying through complete applications in close partnership with commercial bodies. Of course, it is first necessary to carry out detailed task analyses collaboratively, to ascertain which tools will be appropriate to the different potential applications - and which applications it makes sense to tackle with these tools.
Description and diagram of the interdependence and sequence of work packages
Interdependence and sequence of work packages
The following tables illustrate the dependencies arising between the deliverables and the feedback needed from the various evaluating groups. The feedback deliverables are 4.1, 4.2, 4.3 and 4.4.
In these tables the dependent objects are coded as:
D deliverable
I internal deliverable
Those deliverables to which the Work Package is a contributor are show in bold type.
The Tables 1.1 - 1.8 present the dependencies of the individual workpackages. Table 2.0 shows those between the Technical and Validation Work Packages.
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A3.1 High Quality Audio ------ ------- ------ IA4/D4. I10A-- D4.2-- I10B--> ------
-->D0 ------- -->D1 1-- ------ ----- D3 -->D4
A3.2 High Quality Video ------ ------- ------ I4A/D4. I10A-- I4B/D4 I10B-->
-->D0 ------- -->D1 1-- ------ .2-- D3
A3.3 Stream I4B--- -------
Synchronisation ------ ->D3
A3.4 Shared Work-space ------ ------- ------ I4A/D4. I10A-- I4B/D4 I10B->D
Support -->D0 ------- -->D1 1-- ------ .2-- 3
-
A3.5 User Interfaces D2/D4. ------- D4.3--
2--- ->D3 >D4
A3.6 Porting Activities D1----- ------ ------ ------- ------
----- -->D2 ------ ->D3 -->D4
-
Table 1.1 Inter-dependencies and Timing of Deliverables in WP3 - MM Conference Components & cross-platform support
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A4.1 Requirements ------ -------
Capture ------ >I4A
-
A4.2 User Interface I4A--- ------- ------
Design ------ ----- >I4B
A4.3 Tool Evaluation D0----- -----> D1----- -----> D2---- ----->D D3-->D
---- D4.1 ---- D4.2 ----- 4.3 4.4
Table 1.2 Inter-dependencies and Timing of Deliverables in WP4 - Usability and Assessment
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A5.1 Low-level ------ ------- ------ ------- -->I5B ------ ->I5C/D
Interoperability ------ ------ >I5A ------ /D2 ------ 3
- -
A5.2 QoS Negotiation ------ ------- ------ ------- ------ ------ ------- ------
------ ------ ------ ------ ------ ------ >D3 -->D4
- - - -
A5.3 Common Conference ------ ------- ------ ------- ------ ------ ------- ------
Control ------ ------ ------ ------ ------ ------ >D3 -->D4
- - - -
A5.4 White-board D1----- ------ ------ ------- ------
Interoperability ----- ->D2 ------ >D3 -->D4
-
Table 1.3 Inter-dependencies and Timing of Deliverables in WP5 - Interworking
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A6.1 Support for ------ ------- ------ ------- ------
Technologies ------ ------ -->D1 ------ ->D2
-
A6.2 Network ------ ------- ------ ------- ------ ------ ------- ------
Measurement ------ ------ ------ ------ ->D2 ------ -I6A ->D4
- - -
A6,3 Network Monitoring ------ ------- ------ ------- ------ ------ ------- ------
------ ------ ->I6B ------ >I6C ------ ------ ->D4
- -
Table 1.4 Inter-dependencies and Timing of Deliverables in WP6 - Network Support
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A7 Multimedia Server ------ ------- ------ ------- ------ I10A-- ------- ------
------ ------ --->I7 ------ -->D2 ----- >D3 ->D4
-
Table 1.5 Inter-dependencies and Timing of Deliverables in WP7 - Multimedia Server
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A8.1 Booking and ------ ------- ------
Conference Set-up ------ ------ -->D1
-
A8.2 Conference Relay D1----- ------
Set-up ----- -->D2
A8.3 Conference Control D1----- ------ D2---- ------- ------
----- ------ ------ ->D3 -->D4
-
A8.4 Fault Diagnosis ------ ------- ------ D1----- ------ ------ ------- ------
------ ------ -->D1 ---- -->D2 ------ ->D3 -->D4
- --
Table 1.6 Inter-dependencies and Timing of Deliverables in WP8 - Conference Management & control
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A9 Conference Room ------ ------- ------ D1----- ------ ------ ------- ------
Support ------ ------ ------ ----- -->D2 ------ ->D3 -->D4
- - ---
Table 1.7 Inter-dependencies and Timing of Deliverables in WP9 - Conference Room Support
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A10.1 Security ------ ---->D1 D10.1>
Architecture ------ 0.1 D1
-
A10.2 End-end security D10.1- ----->I ------ -----> -------
----- 10A ->D2 I10B >D3
A10.3 Participant D10.1- ------- ------ ------ -------
Authentication ----- ------ ->D2 ------ >D3
--
A10.4 Encryption D10.1- ------- ------ ------ ------- ------
Gateways ----- ------ ------ ------ >D3 -->D4
- -
Table 1.8 Inter-dependencies and Timing of Deliverables in WP10 - Security
ACT SUBJECT M3 M6 M9 M12 M15 M18 M21 M24
A11.1 Weekly D0---- -------- D1---- -------- D2---- --------- D3-------
Meetings ----- -->D4.1 ----- -->D4.2 ----- ->D4.3 -->D4.4
A11.2 MERCI D0---- -->D11.1 D1---- -->D11.2 D2---- -->D11.3/ D3->D11.4
Seminars ----- /D4.1 ----- /D4.2 ----- D4.3 /D4.4
A11.3 Other D0---- -------- D1---- -------- D2---- --------- D3-------
Seminars ----- -->D4.1 ----- -->D4.2 ----- ->D4.3 -->D4.4
A12 Surgical D1---- -->D12.1 D2---- --------- D3->D12.2
Workshop ----- /D4.2 ----- ->D4.3 /D4.4
A13 Commercial D1---- -->D13.1 D2---- --------- D3->D13.2
Trials ----- /D4.2 ----- ->D4.3 /D4.4
Table 2 Interdependence and Timing between the Technical and Validation Work Packages
Year 1 Year 2
WP pms KECU pms KECU
1 9.0 64.6 9.0 69.6
2 11.0 79.0 11.0 85.1
3 23.5 168.7 15.5 119.9
4 5.0 35.9 6.0 46.4
5 10.3 74.0 10.3 79.7
6 15.1 108.4 13.5 104.5
7 10.3 73.9 10.0 77.4
8 12.5 89.7 10.5 81.2
9 7.5 53.8 6.5 50.3
10 17.6 126.4 17.3 133.9
11 8.0 57.4 8.0 61.9
12 3.9 28.0 4.0 30.9
13 3.0 21.5 3.0 23.2
TOTAL 136.7 981.3 124.6 964.0
An updated list of deliverables with brief descriptions and target dates
Deliverabl Title Delivery Nature Dis-semina Type Work-Package
e tion ID, PD ID
ID date Level or X (f)
(a) (b) (c) (d) (e)
D0 Initial Software 3 TO RP PD WP2, WP3
D1 MERCI S/W - I 9 TO RP ID WP2, WP3, WP6,
WP8, WP10
D4.1 User Feedback - I 9 RE LI X WP4, WP11
D10.1 Security 9 SP PU PD WP10
Architecture
D11.1 Seminar - I 9 PR PU PD WP11
D2 MERCI S/W - II 15 TO PU PD WP2, WP3, WP5,
WP6, WP7, WP8,
WP9, WP10
D4.2 User Feedback - II 15 RE LI X WP4, WP11,
WP12, WP13
D11.2 Seminar - II 15 PR PU ID WP11
D12.1 Surgical W/Shop - I 15 PR PU ID WP12
D13.1 Commercial Trial - I 15 PR PU ID WP13
D11.3 Seminar - III 18 PR PU X WP11
D3 MERCI S/W -III 21 TO PU PD WP2, WP3, WP5,
WP7, WP8, WP9,
WP10
D4.3 User Feedback - III 21 RE LI X WP4, WP11,
WP12, WP13
D4 MERCI S/W - IV 24 TO PU PD WP2, WP3, WP5,
WP6, WP7, WP8,
WP9, WP10
D4.4 User Feedback - IV 24 RE LI X WP4, WP11,
WP12, WP13
D11.4 Seminar - IV 24 PR PU PD WP11
D12.2 Surgical W/Shop - II 24 PR PU PD WP12
D13.2 Commercial Trial - 24 PR PU PD WP13
II
Notes
(a) ID of the form 'Dn.m' where n = n in 'WPn' : n = number of the work package and m = deliverable number for that work package i.e. m = 1 - <total number of deliverables in WPn> - in chronological order down the page
(b) of the form: 'n' where n = 01 - ~ 36 i.e. project not calendar months
(c) PR = Prototype (Demonstrator) : RE = Report : SP = Specification : TO = Tool : OT = Other. PR, TO & OT will have an associated document for contractual purposes. All deliverables will be accompanied by a 'peer' review report
(d) PU = Public Usage of the result : LI = limited to programme participants : RP = restricted to project participants (Public documents shall be of a professional standard in a form suitable for publication)
(e) ID = An internal deliverable : PD = A 'Project deliverable' as defined in Article 4 of the contract : X = Submitted on request deliverables where appropriate available for review or dissemination purposes limited to participants of the TELEMATICS APPLICATIONS Programme
(f) ID of the form: 'WPn' where n = 01- ~10
B.1.3 Dependencies and relationships
If any change to the project relationships and/or dependencies is forecast, both within and without the Sector, these should be detailed here.
The project is in process of submitting a revised Project Plan to reflect the requested inclusion of the Communications Research Centre (CRC) of Industry Canada in the project. Assuming that the application to include CRC in the consortium is successful, CRC will contribute to MERCI by participating in the following Work Packages:
WP2 - Activity with External Groups
Under this Work Package CRC will be particularly concerned with co-ordination with three international projects that are concerned with trans-Atlantic connections and demonstration of user services across that infrastructure (NICE-Global, GIBN, MAY) and nationally with the CANARIE research activities, especially the Multicast Project and the NTN mbone trials. Within those initiatives complementary technical studies are being undertaken and possible collaboration where mutual benefit can be obtained will be explored. A brief description of the four activities follows.
NICE-Global The NICE (National Host InterConnection Experiments) project addresses the High Speed Networking area of the ACTS Workplan. NICE-GLOBAL addresses extending this work internationally. The primary objective of NICE is to integrate systems so as to enable EU, Central and Eastern European and Canadian National Hosts to provide broadband applications support functions.
GIBN GIBN (Global Interoperability for Broadband Networks) is a project started by the Ministerial Conference on the Information Society of the G-7 nations. The fundamental objective of GIBN is to provide a means for developing and testing trans-national applications that will support the promise of a Global Information Society. The purpose of the project is to facilitate the establishment of international links among existing high-speed data networks of the industrialised countries. The project will support experiments on interconnectivity and interoperability, the establishment of standards and serve as a testbed for a wide variety of research on education, industrial and other applications. Initial infrastructure efforts have concentrated on Europe to Canada, Canada to the USA and USA to Japan links.
MAY MAY (Multimedia Applications on Intercontinental High Speed Networks) is a consortium formed by Deutsche Telekom, Sprint and Teleglobe Canada under the Global-One Alliance. MAY contributes to the support of international (USA, Germany and Canada) co-operation in R&D of multimedia applications for office communications, education and training, distributed design and construction, publishing, medicine, tourism and interactive television. DeTeBerkom (Berlin) and the International Computing Science Institute (Berkeley, California) are the organisations supporting Deutsche Telekom and Sprint, respectively, in the consortium.
CANARIE CANARIE (Canadian Network for the Advancement of Research, Industry and Education Inc.) is sponsoring a MultiCast Test Project to develop a multicast capability between the routers located at the ATM National Test Network (NTN) nodes and to conduct a series of interoperability studies and application trials. One goal of the MultiCast Test Project is to explore the provision of a Canada wide mbone service on the CA*Net using trunking from the NTN. CRC (DRX & BADLab) has participated in some of the initial mbone/NTN activities. DRX will continue to explore possibilities for co-operation between MERCI and the MultiCast Test Project.
WP4 - Usability and Assessment
Within the auspices of WP4 -- which include capturing the user requirements, ensuring an appropriate user interface to the system, evaluating the tools provided, and assessing the tools needed for collaboration -- CRC will be specifically involved in the development of quantitative assessment tools that can encode all aspects of tele-interactions (static or dynamic; software parameters; user operations; timing). Efficiency of use (e.g. error patterns, redundancy in action sequences, use of short-cuts, superstitious behaviours) and cross-platform compatibility from the users perspective can then be documented empirically. In an attempt to incorporate user needs into the development process of the MERCI tools, performance measurements will be obtained from the software and correlated with performance from the user. As for the human performance measurements, a naturalistic observation approach will be adopted where participants will be videotaped (audio and video) and screen captures will serve to anchor participants' behaviours with the activity at hand.
Deliverables - In parallel with WP4 “User Feedback” deliverables (D4.2, .3 & .4) a series of reports on “Quantitative Pilot Data on Behavioural Patterns” will be delivered at months 12, 18 and 24.
WP6 - Network Support
The objectives for the CRC activities in WP6 are described under two work elements.
IP Multicast Networks - to successfully interconnect and integrate CRC into the MERCI/mbone infrastructure.
Performance Measurement and Network Management -
Deliverables -
CRC will act as a host site for reception and assessment of the MERCI seminar series and will provide at least one seminar in the series.
Deliverables -
Remote medicine is a topic of great concern in Canada and national activities are underway. CRC will provide a reception facility to host the MERCI surgical workshops and will invite representatives of the Canadian remote medicine community to participate in those events.
Deliverables -
B.2 If the project is scheduled to finish this year but needs to continue work into the next year, WITHOUT EXTRA FUNDING, please describe the tasks to be undertaken and the dates by which they will be completed.
Not applicable.
Part C - Plans for Demonstration, Exploitation, Implementation and expected achievements
All projects should complete this section, but those projects which complete their work by the end of this year should pay particular attention to this section.
This section should reflect the developments since the start of the project or previous review, bearing in mind that Article 10.1 Annex II of the contract requires that the project develops an exploitation plan (technology implementation plan) at the same time as its Final Report.
Description of achievements and likely impact should be made under the following headings.
C.1 What is the likely thrust and direction of your exploitation plan?
This project is already having a strong impact on the users. First, many users have access to different networks as part of their research or commercial activity; that they should be able to use their normal networks for these advanced services would be of immense value. Their organisation normally has a specific procurement policy be it PCs, UNIX workstations of various types or Macs; that the same platform can be used for multimedia conferencing has strong impact on the support requirements and investment decisions needed inside the organisation - and hence on the ease with which the technology can be introduced. At present there are still a number of distinct groups of users doing conferencing - and there is no means for them to interwork; the multi-platform and multi-network environment which we are developing will enable them to do so.
There are already many specific conferencing products; most are much more limited in their approach to security, incorporation of servers and control functionality. Particularly without the security aspect, there are many application areas which cannot be addressed. We have already developed much of the architecture which we will present as a deliverable in September 1996. The capabilities of our present approach, which is compatible with that in the research community in the US, will support much more flexible and comprehensive services; importing such a technology would be impossible given the present US export laws.
Suppliers are interested in this activity because of its potential impact in many of their products. From workstation manufacturers, we have had considerable support - because of their interest in seeing the technology developed further. Two server suppliers have seen the impact; Hewlett-Packard, one of the sponsoring partners, has donated both workstations and a large 180 GB server from their interest in its utilisation in these applications; another server supplier is providing its software free of charge with the same motivation. The network operators are, of course, enthusiastic; BT is supporting many British national initiatives in this area (including at UCL), French Telecom has sponsored showing the technology at the G7 summit and on a recent meeting with the French Prime Minister, and Norwegian Telecom would have been a partner in this project (as they were with MICE) if they could have completed the formalities in time. The research network operators are enthusiastic; UKERNA is a sponsoring partner, and is supporting the deployment of the technology over SuperJANET; others are supporting the deployment of the technology in European support Centres. Finally, training organisations see the potential; hence the sponsorship of Hewlett-Packard for this project comes from their education and training centre, and we have language centres in involved in three countries with national projects.
There is no doubt that the technology is fast moving from prototype to product. It will not only embrace one product; several applications projects are proposing to take pieces of the technology developed here and emphasising specific areas. One intends to include microscopy-specific shared workspace software and develop an integrated product suited to that domain; another to develop a multimedia server incorporating parts of WP7 directly. Several are eyeing our network experience particularly closely; they intend to incorporate our control strategies into their products.
We have a proven track record of broad dissemination in this area. We are deliberately making the software widely available - and this is very popular with the suppliers. Clearly the commercial partners have a considerable advantage; they will get the software at a much earlier stage, and will have more influence on what is produced. It is not expected that all the software from the commercial suppliers will be disseminated as freely as from the research ones - hence the advantage also of having so many research partners in this activity.
We disseminate information widely at conferences and exhibitions. During the first 8 months of the project we have published 7 papers at conferences or in journals, made 6 standards contributions, had 4 papers accepted for publication or delivery and have submitted a further 3. Details of these activities are given in A.9 DISSEMINATION ACTIVITY AND PLANS above.
We continue to feel that, in view of the basic nature of the many technologies incorporated in this project, it would be inappropriate to formulate a central business plan. Business planning will be pursued by the partners in accordance with their natural commercial allies. We still do not plan to form a single MERCI company as a result of this work; we do expect to spawn a number of products in companies, however.
C.2 Do you foresee moving to an implementation phase of the project, perhaps in some other EU action?
The project is already in an implementation phase since we have delivered initial software to specific users in other projects and to our sponsoring partners. As the tools are enhanced during the coming year, we expect the scale of this implementation to widen. This will happen quickly with the availability of the tools on PCs and the option of secure conferencing. The major limitation which we see at present is the lack of a stable wide-band network across Europe to complement the increasing capacities available at national level.
C.3 Development and/or enhancement of services.
With the planned availability of the multimedia conferencing environment on more platforms and over more networks, we foresee greater development of such services. This is subject to network availability, of course. Using the security infrastructure to be established by the ICE-TEL project, new PC platforms with improved, simplified user interfaces, we expect to provide a suitable environment for the development and use of conferencing services in far more places than is now possible.
C.4 Impact of work, including world leadership, catch-up and know-how.
We are among the leaders in our field world-wide. We have made important contributions to both the Internet standards (IETF) and those of the ITU (ITU-T) with 6 Internet drafts delivered during the 8 months of the project so far. We are leading the development of systems to allow interaction between conferences based on ITU standards and those using the Internet Mbone standards.
C.5 Future plans, commercial and market possibilities, and exploitation of results.
C.5. 1 Re-assessment of the market potential and of the markets to be addressed in the exploitation phase.
We have made no reassessment since the start of the project.
Reassessment of the potential for using the results of the project, e.g. in standardisation, to advance the state of the art or state of practice in the application domain.
We have made no reassessment since the start of the project.
C.5.2 Commitment and ability of the participants to operate in the market areas involved.
We remain committed through our commercial partner, TELES, to operating in the Multimedia conferencing market for both hardware and software.
Commitment and ability of the participants to assure the transfer of the results into practical and effective use.
Our commercial partner, TELES, is the leader of the workpackage providing for inter-operation between the conferencing using the ITU standards and that using the Internet standards. They are well established suppliers of ITU standard conferencing products and will be optimally placed to exploit the commercial opportunities available for interworking software.
C.5.3 Efforts so far undertaken and to be undertaken in the future to assure transition to a successful exploitation phase.
At UiO an initiative is underway to commercialise the conference room technology developed under the auspices of the MERCI project. It is anticipated that this will result in the establishment of a commercial company to market, supply and support conference rooms incorporating MERCI technology before the end of 1996.
We are maintaining our close contacts with the current users of our software and receiving valuable feed back from them. We are on target to achieve our plans for the further development necessary to assure that future exploitation will be even more successful than that achieved so far.
C.6 Demonstrations, findings, conclusions and future possibilities.
Demonstrations are planned in several areas during the next few months, to build up the case for larger-scale testbeds. We expect to see the technology move into products on a major scale - helped by the improvements being made inside the MERCI project.
Of particular importance is the emergence of cards supporting video capture and display integrated in with Standard APIs for Windows NT and Windows'95; these will make it increasingly popular to extend our work to those platforms. The portability of the facilities we are producing is particularly significant in this respect. We are also starting to see Standard Cards and APIs for ISDN, and much more widespread deployment of that technology. This is opening up the full home and low-cost business markets. We are exploring applications in business and commerce as a result, and expect to put forward major demonstrator projects in the next Call.
One outcome of the activities of this project is the commercialisation planned of components of the Electronic Classroom. This commercialisation is planned for 1997/98, and will lead to substantial markets opening up for Distance Education; we plan a major trial in this area for the next Call.
The area of Interactive Cable TV is suddenly flourishing. Some of the partners of the MERCI project will be transferring the MERCI technology to demonstrations using that technology over existing ACTS projects (AMUSE and IBCBN); however, we are also discussing with new industrial partners new initiatives in Home TV applications.
We have just started discussing with two Service organisations the implications of Direct Broadcast Television to this area. Here the natural applications are in various forms of education. Of particular interest is the potential for deploying the technology in distant learning situations where the conventional communications infrastructure is poor; for this reason we are discussing some major initiative with INCO partners in Cyprus and Eastern Europe applications of the technology for them.
The International Geophysical Union is going to start making important use of MERCI facilities for their meetings. Both they and MANICORAL have requested changes in Whiteboards; to the extent they are small-scale, they can be accommodated in the present activity. We expect, however, that as result of User Feedback during the present project, and a proposed new set of applications, some major changes will be needed both in the User Interfaces and some of the tools. These will probably also be included in an extension proposal.
We feel the Server facilities we are providing are important, and raise many interesting concepts. During the remainder of the project, we will be able to complete our resent servers, and have ours users evaluate them. We are also going to be installing some commercial Video-on-Demand servers developed for the Cable TV arena. It ill probably be necessary to merge these two mechanisms to provide the richness of facilities desired by the applications, together with the high performance and robustness required by the users.
Over the next year, the routers on the Internet will be moving to high performance Mbone technology, with the capability of adding Resource Reservation. This should allow significant deployment of the MERCI technology for high performance conferencing. We believe that this will make very serious inroads into the professional conferencing market. Here the integration of high performance ITU-MBONE gateways will be an extremely important addition, because of the time factor before the value of the MBONE mechanisms in this arena is fully accepted.
C.7 End Products of the Project, complete the following form.
C.7.1 End Product Description Sheet
End products may be of various types:
findings on problems (technical, economic, human behavioural etc.)
results of assessments
running systems
elements of systems (hardware, software)
tools for building systems x promotional material
Precise description of your end-product and its purpose.
MERCI will deliver a set of tools for building tailored applications for real-time interactive multimedia collaboration systems for specific user groups. The tools, all of which will conform to industry standards, will allow the following types of interaction:
These tools, from UCL and from INRIA, will provide options for high quality audio, good resistance to poor network conditions and encryption.
The video tool will provide new high quality video with in-built scaling for differing network conditions to allow users to receive the best quality which their connectivity will allow. It will also allow encryption to provide security.
This tool, NTE, will continue to be developed and enhanced during the second year of MERCI.
The new MERCI whiteboard tool, being written in JAVA, will be available for platforms which provide JAVA support including, we hope, the MAC. It is intended that this tool will provide basic functionality expected in a whiteboard including drawing, text input and the ability to import standard image files.
The current session announcement tool, SDR, will be further enhanced to provide the means to advertise and to invite attendance at secure conferences with authentication of those attending.
The Gateway will consist of several components, available as separate entities or as a single integrated tool. The components, comprising the Session Controller, the H.323/MBONE Gateway and the H.323/H.320 Gateway, will provide simple relaying between the two conferencing environments. This functionality can be further enhanced to provide transcoding and other sophisticated features in the future.
This tool will be provided by MANICORAL, a related project in the TELEMATICS programme.
Date when it is available
(E.g. - exists, planned for month-year, uncertain...)
November 1997
Source of output
(Name of project or sub-project)
MERCI & MANICORAL
Type
(E.g. brochure, software, demonstrator, specification, prototype, etc.)
Software toolkit
Client(s)/User(s)
Who profits from the product? If several, list in priority order.
The European research community.
European education institutions at all levels.
Benefits
Explain what benefits will be gained from your end product.
Increased co-operation within the European research community is anticipated as research collaborations are established which can communicate freely using these tools in addition to their meetings face to face and their use of indirect tools such as mail and email.
Other Comments
ANNEX
______________
Form to be used by the Reviewer
Review Report - Panel Programme sector :
Project Number:
Acronym :
Project Assessment
A. Work Done Delete as Comments
necessary
a Does the project still Yes / No
significantly contributes to the
objectives of the programme?
b Is it 'State of the Art' work, Yes / No
in terms of the application?
c Is it 'State of the Art' work, Yes / No
in terms of the technology used?
d Are the objectives of the Yes / No
project being met?
e Are there definite plans for Yes / No
exploitation of results?
f. Is there a reasonable balance Yes / No
between the work done and the
financial investment in the
project?
B. Application Results: Scores 1 to 5 Comments
a Are the user needs properly 1 - 2 - 3 - 4
reflected in the user - 5
requirements and/or the
implementation?
b Soundness of knowledge base 1 - 2 - 3 - 4
- 5
c Quality of application's 1 - 2 - 3 - 4
approach - 5
d Level of potential 1 - 2 - 3 - 4
interoperability - 5
e Content quality of 1 - 2 - 3 - 4
deliverables in relation to - 5
project objectives
f Soundness of the validation 1 - 2 - 3 - 4
phase - 5
C. Project Management
g Balanced & consistent methods 1 - 2 - 3 - 4
of approach - 5
h Realistic time scales and 1 - 2 - 3 - 4
resource allocation - 5
i Effectiveness of project 1 - 2 - 3 - 4
management techniques - 5
j Sound schedule of Deliverables 1 - 2 - 3 - 4
- 5
k Dissemination of results 1 - 2 - 3 - 4
and/or plans for reaching an - 5
effective consensus
l Strong synergy / integration 1 - 2 - 3- 4
between different parts of the - 5
project
Review Report - page 2 Programme / Area :
Project N° :
Title :
D. Modifications and Developments since the last Review:
E. View on Project Status:
E. Exploitation / Implementation potential
F. Recommendations for future work:
G. Overall recommendation:
Successful completion Continue
Modify Red Flag
Panel rapporteur: ................................................. Date : .../10/1994
Signature : ..................................................