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 date)	Number	Comments, problems with deadlines	
Activities on/before target	27		
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 reporting period	 1	D0 Initial software deliverable
Restricted to project participants	
Deliverables acknowledged by DG XIII	1		
Late deliverables - for reporting period	0		

C. Work done
Are project objectives being met?	Grade from 0 (not at all) to 4 (totally)	
    4	Comments
All deliverables are on track for delivery by due dates.	
Is work done within the project budget?	Yes		Comments	
Major achievements within reporting period	•	Secure versions of  VIC, VAT, RAT and NTE have been released
•	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 end-products (ref .......)
Name	Type	Comments	
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. 

E. 	Expectations for Implementation and/or Exploitation
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
(Initials)	Project Duration
in Months	
Telematics for Research		24	
Project Objectives, Summary description and anticipated results (up to 20 lines):
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.	
Major Validation sites1 :
Institution/
Organisations	City/Town
+ Postal Code	Region 2 . 	Country 3 . 	
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 Hospital	Gothenburg S-413 45	SE052	SE	
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
+ Postal Code	Region1  	Country 2	
University College London	London, WC1E 6BT	UK 55	GB	
Contact person from the Co-ordinating Contractor: 
Title, First Name, Name	Professor Peter Kirstein	Address:	Gower St, London, WC1E 6BT, UK	
Tel: 	+44 171 380 7286	Fax: 	+44 171 387 1397	
E-mail 1: 		E-mail 2:	kirstein@cs.ucl.ac.uk	
Other Contractors:
Participants Code3 	Name of Institution/Organisation	City
+ Postal Code	Region1	Country 2	
C 2	GMD - Forschungszentrum Informationstechnik GmbH	Darmstadt,     D-64204	DE 71	DE	
C 3	Institut National de Recherche en Informatique et Automatique	Nice, 06902	FR 82	FR	
C4	Kungliga Tekniska Högskolan	Kista, 16440	SE 01	SE	
C5	University of Oslo	Oslo,  N-0316	NO	NO	
C6	Rechenzentrum U Stuttgart	Stuttgart, 70174	DE 11	DE	
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.
A.1	Objectives of the project
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.
•	Better integration of the multimedia conferencing facilities to make them easier to use by untrained users: Here we have provided better integration with a new announcement tool SDR, and providing new User Interfaces for the Electronic classroom systems.
•	Better capability for higher quality video, audio and shared workspace facilities: We have proved codecs providing 16 bit audio and stereo are available in pursuit of our quest for higher quality. The audio tool has incorporated redundancy to make it more robust against packet loss. A new video tool and a shared workspace tool have been largely completed.
•	Inter-operable cross-platform support for many systems - UNIX workstations and PCs: We have ported session control, audio and shared workspace tools to PC platforms and have participated in the testing of video tools ported by others.  Since Apple are now providing RTP compliant conferencing in their Quick Time conferencing suite, we decided not to pursue the porting of the MERCI tools to the MAC.
•	Better support for the introduction and recording of multimedia information in conferences: The multimedia server developed for the MICE project has been adapted to handle more simultaneous streams and the redundancy protocol in RAT.
•	Support for different network technologies - mainly using IP: packet-switched, ATM or SMDS and ISDN (though this will also use native mode): We have begun working on the tools needed to allow the use of the conferencing technology over differing lower-level networks, especially in an environment where participants in conferences are using links with widely varying bandwidth.
•	Inter-operation between workstations running the multicast Internet and the normal procedures developed in ITU-T SG 8 and 15: Work is proceeding to schedule on WP5.
•	Facilities for  secure conferencing - with easy distribution of keys and information: We have produced an architecture for secure conferencing, to be delivered on 31 August, 1996, and have integrated security into audio, video and shared workspace tools.
•	Distributed measurement,  monitoring and control: We expect to take delivery soon of the  Hewlett-Packard network monitoring software OpenView.  We also will be using the new multicast monitoring software Mview.
•	Regular research  seminars given from the sites of the partners - and from North America: Two seminars have been delivered with further ones due from September 1996.  The delay in our access to JAMES, and congestion in the European Mbone, has lead to our postponing any expansion of this activity.
•	Annual interactive workshops in invasive surgery given at UCL - transmitted internationally, and with some operations coming from other countries: The first of these will now be given in February 1997.
•	Industrial trials with commercial organisations including our sponsoring partners Hewlett-Packard & Shell: Remote training sessions have been held for Shell and their contractor at Sheffield University.  We have conducted several trials with Hewlett-Packard, UK.  We are incorporating their feedback into our tools.
•	Use in the research community, including by our sponsoring partner UKERNA and by other Telematics projects including MANICORAL and CoBrow : UKERNA and MANICORAL use the conferencing tools in regular meetings. We  have had preliminary discussions with CoBrow, and a definite commitment from ICE-TEL.

A.2	Work done
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.
Workpackage 1:  Project Management
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. 

Workpackage 2:  Activity with External Groups
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.
MANICORAL
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.
MICE National Support Centres in Europe
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.
CoBrow
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.
ATHOC
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.
SunTREC
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:
•	Transfer of research results and software systems to industry and research institutions
•	Demonstration of new approaches and solutions in enabling technologies as well as in specific applications domains
•	Continued enhancements of available results by direct co-operation between University and industry
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.
TERENA/TEN-34
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.
ICE-TEL 
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.
Internet Engineering Task Force (IETF)
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.
IMTC Meetings
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.

WWW  Consortium
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
Presentations
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).

Workpackage 3:  Conference components and Cross-platform Support
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. 
High quality audio
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
high quality audio coding at the source 
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
delivery of high quality audio even in the face of network congestion
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.
High quality video
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 
A resource scheduler
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. 
New coding schemes (a layered DCT scheme and a wavelet-based scheme)
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.
Shared workspace
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.
Porting activities
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.
Availability
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/

Workpackage 4:  Usability and Assessment
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.

Workpackage 5: Packet / Circuit MM Conference Interworking
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 ITU developed its H.3xx and T.12x series of recommendations to support multipoint multimedia conferencing - originally for circuit switched networks (H.320, H.324) where transmission bandwidth is guaranteed.  In its latest recommendation in this area - H.323 - the ITU also defines how to perform multimedia conferencing on top of packet switched networks. ITU members have developed this recommendation together with IETF members so that IETF protocols are employed by the MBONE Tools as well as by H.323. 
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.
•	MBONE videoconferencing tools such as RAT, VIC, SDR and others were designed to operate over packet switched networks. They make use of multicasting to distribute audio and video data streams, are based on IETF standards and are widely used in the academic community. Parts of the development of these tools as well as their application in international field trials was initiated by MICE and is being continued in the MERCI project. A specific focus of the work within MERCI in this context concentrates on security issues (WP 10).
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.

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:
•	MBONE conferences are receiver-oriented, i.e. MBONE Terminals receive and distribute datastreams via multicast and do not interact with specific remote sites directly.
•	In ITU conferences, on the other hand, each DMC terminal usually interacts with exactly one remote site which is often a Multipoint Control Unit (MCU). The MCU performs a filtering function: since the bandwidth to each participant is limited, it selects one video and one audio data stream from all incoming data streams and forwards it to the receiver: each receiver only receives one video data stream and one audio data stream. The DMC terminals have conference control facilities and can request to join or leave conferences to obtain speech rights and others.
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
Components of the MBONE / H.320 Gateway
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:
•	the Session Controller,
•	the H.323 / MBONE Gateway and
•	the H.323 / H.320 Gateway
A full description of these components can be found in Packet / Circuit MM Conference Interworking - Annual report, included in Annex 7 of this report.
Summary of Achievements:
In the first eight months of the MERCI project, the following results have been achieved in WP 5:
•	Definition of the workplan for WP 5.
•	Verification of interoperability between MBONE Tools and H.323 Terminal at the audio and video level.
•	Development of the Session Controller
•	Development of the MBONE / H.323 Gateway
•	RUS has started work on whiteboard interoperability in the design and development of a new Java-based whiteboard tool according to the project plan (A 5.4)

Workpackage 6:  Network support
Higher Speed Working 
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). 
ISDN and Low Speed Support
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: 
•	The Multiplex / Demultiplexer defined in ITU-T Rec. H.223 
•	Multimedia System Control described in ITU-T Rec. H.245 
•	Audio codec complying to ITU-T Rec. G.723 
•	Video codec complying to ITU-T Rec. H.263
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.

Workpackage 7:  Multimedia server
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.

Workpackage 8:  Conference Control and Management
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.
1. Lightweight Sessions
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. 
2. The ITU H.323 Family of Protocols
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.
3. The ITU T.120 Family of Protocols
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.
4. Inter-operation Between IETF and ITU based session
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.
5. Local Session Control
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.
6. Mbone Relays and Mixers
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.
7. Security
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.
8. Server Control
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.

Workpackage 9:  Conference Room Support 
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: 
•	The software for the electronic whiteboard which is a shared workspace application. 
•	The audio and video conferencing software based on Hewlett-Packard UNIX-machines and the Bitfield video codec. 
•	Software for local control of conference room hardware components. 
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.

Workpackage 10:  Security 
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.
Workpackage 11:  Seminars
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.

Workpackage 12:  Surgical workshop
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.

Workpackage 13:  Commercial Trials
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.

A.3 	Problems encountered
An analysis of any problems or difficulties which have been addressed, whether of a technical or organisational point of view.
Lack of good network connections between partners
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.
Postponement of the Surgical Workshop
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.

A.5 	User Representation Groups
Describe the user representation groups, their contribution in the development and exploitation of the work.
MANICORAL
MANICORAL is a TELEMATICS for Research project (RE 1006). The project consists of three partners
•	The Human Collaboration and Communications group at Copenhagen Business School which is responsible for the assessment of the effects of the new technology on the working methods of the users.
•	The AFRICAR project which uses visualisation tools to help in the interpretation and analysis of satellite data.  The three project members communicate by e-mail and s-mail and meet normally once a year only. The data they use is now available from a common server. They wish to work with shared visualisation tools, including animations, as part of a multimedia conferencing environment.
•	RAL is responsible for the design and eventual deployment of a shared visualisation tool. Initially they will develop the requirements and identify a suitable architecture.  They have introduced the initial set of MERCI tools to the AFRICAR users and have provided feedback from these users to the MERCI project (see Notes on the MANICORAL/MERCI Liaison Meeting, UCL, 15 July 1996 included in Annex 7).
The feedback from MANICORAL will influence the ongoing development of tools, especially the design of their user interface.
Shell Research
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.
Hewlett-Packard
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.

A.6 	Validation Activities
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.
Plans for validation
The stated objectives of the project include:
•	To validate the tools by their deployment in three Validation Exercises inside the project:  A Seminar Series, some surgical workshops, some commercial trials.
•	To validate the results by deploying the tools in two related Telematics projects:  MANICORAL and COBROW.
We see four stages of verification:
1.	The components are shown to work by being transferred to another MERCI partner who is able to mount and use satisfactorily the components - usually in conjunction with other MERCI components
2.	We hold a bi-weekly multimedia project meeting.  The second stage of verification is that the components work well when introduced into the weekly meetings.
3.	We plan to demonstrate the MERCI tools as part of the Deliverables.  We will use public conferences or exhibitions to demonstrate our Deliverables to the CEC (and others).  This is a very harsh test on whether the components fit together and operate reliably.  Since all of our components have to be demonstrated, this stage is an important milestone for them.
4.	Finally, we will transfer the components to one of the validation workpackages.  Here they will be hammered by people outside the project.  Only when the results here are judged satisfactory, do we consider them ready for the demonstration phase - and even then any drawbacks are noted for use in further development of the components.
Validation undertaken to date
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.  
Outside the 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.
Inside the 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.
Observation
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.7	Co-operation activities with other projects and programme Sectors
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.

A.8 	Contribution to the application domain
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: 
•	a Distance Learning seminar series (WP11)
•	workshops in experimental surgery (WP12)
•	trials under commercial conditions (WP13)
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.

A.9 	Dissemination activity and plans
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.
Actual  dissemination of results
Attendance at Standards meetings
34th IETF meeting in Dallas, December 1995
INRIA and UCL both sent delegates. A UCL report of the meeting is included in Annex 7.
35th IETF meeting in Los Angeles, March 1996
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.
36th IETF meeting in Montreal, June1996
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.
ITU SG 8 meeting in Boston
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.
Publicity
World-Wide Web servers
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
Printed materials
RUS have produced a two-page colour handout with information about MERCI which is available from the RUS web server.
Demonstrations 
Demonstrations of the MERCI technology have been given for:
•	a sub-committee of the British House of Lords Select committee on Science and Technology.
•	Shell Research and Leeds University, one of their subcontractors with whom they will be conferencing using the MERCI tools.
•	the Distance Learning Initiave (DLI) workshop held at UCL and sponsored by HP in February 1996.
•	MERCI was jointly responsible for the Mbone transmission of the 5th  World-Wide Web Conference held in Paris, 6-10 May.  
•	CeBIT '96 in Hannover
•	SunTREC Colloquium in Stuttgart organised by Sun Microsystems, 16th April
•	CSCW Workshop organised by Deutsche Telekom, 10th May in Darmstadt.
Conference Presentations
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).
Seminars
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.
Publications
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.
Watson, A. & Sasse, M. A. : “Assessing the Usability and Effectiveness of a Remote Language Teaching  System”.  Presentation at ED-MEDIA 96 Conference in Boston, Mass. in June 1996.
Standards contributions
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.
Planned
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:
Papers accepted for 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.
Papers submitted for publication
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.11 	Contribution to Telematics Applications Programme objectives (if applicable)
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.
What is the economic and social impact of the project?
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.
How does the project contribute to the European Union 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 international discussions it promotes the goal of 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 lead to opportunities for profitable exploitation by European industry.  The project is a leading contributor in the field of multimedia conferencing to the international standards bodies of both the ITU and the Internet.
How does the project contribute to the competitiveness of industry?
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:
1.	Most directly oriented to the industrial world is our work with Deutsche Telekom AG in Germany. As part of the industrial trials planned in Workpackage 13, we expect to define the extent to which the technology can be effectively used in a commercial environment.  The results of the trials will be widely published to the commercial world.
2.	The benefits which we anticipate from its use by such industrial research bodies as Shell Research and Hewlett-Packard Laboratories, we expect to percolate through to other branches of their operations.  This will be a less direct contribution, but, over time, equally effective.
3.	Through our work with non-commercial research bodies and other organisations, such as the hospitals involved in Work Package 12, we expect a gradual improvement in their efficiency and cost effectiveness.  This should result from the ability to work closely with their peers throughout Europe, an effect which we have demonstrated previously in the successful MICE project and which we continue to find with MERCI. 
The improvement in the network infrastructure resulting from the investment in JAMES and TEN’34 will complement and enhance our activity with these users.
How does the project contribute to meeting the needs of identified 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.  
How is the project’s exploitation going to contribute to the sector domain activities?
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.
What is the Involvement of SMEs in the project and is the work oriented towards the special needs of this sector?
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.
How has the project encouraged the involvement of users in the project and benefited from their presence?
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.
What is the European added-value of the project, in terms of inter-operability and multilingual services and products?
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:
•	It will be of use where application sites do not have the latest and most expensive communications infrastructures
•	It will be able to make good use of improved infrastructure (e.g. JAMES, TEN’34) as soon as it becomes available
•		It will act as a searching probe to discover weaknesses in the European communications infrastructure - even though it will continue to be able to operate at reduced performance

Annexes: Supporting information
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 Role	Type of Organisation	Budget (KECU)	Person - Months	
UCL	C1	Project co-ordinator	A1	385.0	84.0	
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 planned (Person-months within the reporting period)	Manpower used (Person - Months)
	
WP1	Management	6.0	5.7	
WP2	Activity with External Groups	7.3	5.5	
WP3	MM Conference Components and 
                           cross-platform support	
15.7	
19.3	
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 involved in	Manpower planned (Person-months)	Manpower used 
(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 number	Title	Date due	Date submitted	Target date 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. 
D0 Initial software
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

Workpackage 4
 Usability and Assessment 
Progress Report May 1996
Compiled by D. J. Pilon (CRC)
Submitted to M. A. Sasse (UCL)

1. SURVEY OF EXTANT LITERATURE
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.
2. FRAMEWORK FOR ASSESSMENT OF USABILITY
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.
Subjective evaluation
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;
Objective evaluation
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. COMPLETED WORK
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. PLANNED STUDIES/TRIALS 
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:
•	on the one hand, the ITU developed its H.3xx and / T.12x series of recommendations to support multipoint multimedia conferencing - originally for circuit switched networks (H.320, H.324) where transmission bandwidth is guaranteed. In its latest recommendation in this area - H.323 - the ITU also defines how to perform multimedia conferencing on top of packet switched networks. ITU members have developed this recommendation together with IETF members so that IETF protocols are employed by the Mbone Tools as well as by H.323. 
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.
•	on the other hand, Mbone videoconferencing tools such as RAT, VIC, SDR and others were designed to operate over packet switched networks. They make use of multicasting to distribute audio- and video data streams, are based on IETF standards and are widely used in the academic community. Parts of the development of these tools as well as their application in international field trials was carried out by MICE and is being carried out in the MERCI project. A specific focus of the work within MERCI in this context concentrates on security issues (WP 10).

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:
General
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:

•	Mbone conferences are receiver-oriented, i.e. Mbone terminals receive and distribute datastreams via multicast and do not interact with specific remote sites directly. 

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.).

•	In ITU conferences, on the other hand, each DMC terminal usually interacts with exactly one remote site which is often a Multipoint Control Unit (MCU). The MCU performs a filtering function: since the bandwidth to each participant is limited, it selects one video- and one audio data stream from all incoming data streams and forwards it to the receiver: each receiver only receives one video data stream and one audio data stream. The DMC terminals have conference control facilities and can request to join or leave conferences to obtain speech rights and others.

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

Components of the Mbone / H.320 Gateway

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
•	the Session Controller,
•	the H.323 / Mbone Gateway and
•	the H.323 / H.320 Gateway
are described in more detail.

The Session Controller
The Session Controller (SC) provides the essential conference management functionality for Mbone terminals, i.e. it allows Mbone terminals 

•	to join and leave conferences, 
•	to invite additional conference participants, 
•	to exchange of session keys within conferences and 
•	to realise other conference management functions. 

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.

The Mbone / H.323 Gateway

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

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:
•	Definition of the workplan for WP 5.  In line with this workplan, the Mbone / H.320 Gateway will be based on the TELES H.323 terminal and the TELES H.320 / H.323 Gateway.  Thus, existing software can be re-used and the development process will be accelerated.  Security issues and conference control for the MERCI tools are of great importance for the development of the gateway. 
•	Verification of interoperability between Mbone Tools and H.323 Terminal at the audio- and video level:
•	the TELES H.323 terminal - which will serve as the as the basis for the development of the gateway - is being adapted to support the latest version RTP as specified in ITU-T rec. H.225. In this context, multicasting facilities have also been integrated into the TELES H.323 terminal in order to ensure that it is interoperable with the Mbone Tools at the audio- and video level.
•	Interoperability tests between the Mbone Tools (Win 95 version) and the H.323 terminal at the audio- and video level have started to ensure that both implement the underlying standards correctly.
•	Development of the Session Controller
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.
•	Development of the Mbone / H.323 Gateway
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. 
References:
[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. 
1. Lightweight Sessions
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:
1.	a naming scheme for users
2.	a mechanism to locate the desired user
3.	a protocol to inform the user of the desired session and to inform their software of the media, protocols and addresses to be used.
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. 
2. The ITU H.323 Family of Protocols
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.
3. The ITU T.120 Family of Protocols
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.
4. Inter-operation Between IETF and ITU based session
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.
5. Local Session Control
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.
6. Mbone Relays and Mixers
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.
7. Security
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.
8. Server Control
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.
9. Background and Additional Reading
Internet Drafts
"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
Internet Proposed Standards
"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
ITU Recommendations
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.
INTRODUCTION
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.
NETWORK ACTIVITY
RSVP
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.  
Inter-Domain Routing
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.
Mbone Engineering
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. 
SECURITY ACTIVITIES
The Standards Track
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.
The Internet Infrastructure
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.
Authentication
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.
The Public Key Infrastructure
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.
World Wide Web
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.
Secure Transactions
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.
CONFERENCING ACTIVITIES

Audio Video Transport
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.
Multimedia Sessions
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.
Integrated Services
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.

Multiparty Multimedia Session Control Working Group (MMUSIC)
Minutes from the 35th IETF
Los Angeles, California, USA
March 4-5, 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.

Audio/Video Transport Working Group
Minutes from the 35th IETF
Los Angeles, California, USA
March, 1996

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. 

CCLRC MANICORAL/N29/96
RUTHERFORD APPLETON LABORATORY
COMPUTING AND INFORMATION SYSTEMS DEPARTMENT
MANICORAL NOTE 29

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

1. Agenda

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.
•	Audio and user interface
•	Video
•	Shared workspace
•	Server - recording
•	Web issues
•	Networking issues
By  way  of  introduction,  David  gave  an  overview  of  the  current  state  of  the MANICORAL project and initial views on the architecture.

2. Audio and User Interface
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.

3. Video
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.

4. Shared Workspace
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.

5. Security
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.

6. Server- recording
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.

7. Web issues
RAL explained their interest in web-based CSCW tools and gave  UCL a draft copy of a survey paper written by Daniela.

8. Networking Issues
8.1 ATM/JAMES
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.

8.2 ISDN
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.

8.3 MBONE
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.

9. Other Areas of Interest
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.
Packet/Circuit Interworking 
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.
Security
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: 
•	setting up a secure Session Directory, derived from the SD announcements, accessible from the ITU world;
•	invitations sent by some secure mail system
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.
Tool development/enhancement
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.
Validation of the new tools
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:
Seminars (WP11)
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.
Surgical workshops (WP12)
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.
Industrial trials (WP13) 
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.
User feedback on use of the tools (WP4)
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.
Infrastructure maintenance and improvement
Network support (WP6)
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.
Conference rooms (WP9)
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.
Conference management & control (WP8)
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.
MM server (WP7)
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:
•	Record multicast conference data whose source may be any of the conferees
•	Playback recorded material either directly to one user or into another multicast conference
•	Allow users to create their own edits of recorded material and to create their own presentations
•	Supply a large repository of archive space which is accessible to network  users  who  wish  to  record or playback multimedia data
•	Optimise multimedia storage with respect to storage cost and retrieval time
•	Define flexible hierarchical storage mechanisms for organisation, indexing and retrieval of multimedia document collections.
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.
Work with other projects
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	-------->D0	--------------	-------->D1	IA4/D4.1--	I10A--------	D4.2-------	I10B-->D3	-------->D4	
A3.2 	High Quality Video	-------->D0	--------------	-------->D1	I4A/D4.1--	I10A--------	I4B/D4.2--	I10B-->D3		
A3.3	Stream Synchronisation						I4B---------	-------->D3		
A3.4	Shared Work-space Support	-------->D0	---------------	-------->D1	I4A/D4.1--	I10A--------	I4B/D4.2--	I10B->D3		
A3.5	User Interfaces						D2/D4.2---	-------->D3	D4.3-->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 Design			I4A---------	------------	------>I4B				
A4.3	Tool Evaluation		D0---------	----->D4.1	D1---------	----->D4.2	D2---------	----->D4.3	D3-->D4.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 Interoperability	-------------	-------------	------>I5A	-------------	-->I5B/D2	-------------	->I5C/D3		
A5.2	QoS Negotiation	-------------	-------------	-------------	-------------	-------------	-------------	------->D3	-------->D4	
A5.3	Common Conference Control	-------------	-------------	-------------	-------------	-------------	-------------	------->D3	-------->D4	
A5.4	White-board Interoperability				D1----------	------->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	-------------	-------------	--------->I7	-------------	-------->D2	I10A-------	------->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 Set-up				D1----------	-------->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 Support	-------------	-------------	-------------	D1----------	-------->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 Architecture	-------------	---->D10.1	D10.1>D1						
A10.2	End-end security			D10.1------	----->I10A	------->D2	----->I10B	------->D3		
A10.3	Participant Authentication			D10.1------	-------------	------->D2	--------------	------->D3		
A10.4	Encryption Gateways			D10.1------	-------------	-------------	-------------	------->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 Meetings		D0---------	---------->D4.1	D1---------	---------->D4.2	D2---------	---------->D4.3	D3--------->D4.4	
A11.2	MERCI Seminars		D0---------	-->D11.1/D4.1	D1---------	-->D11.2/D4.2	D2---------	-->D11.3/D4.3	D3->D11.4/D4.4	
A11.3	Other Seminars		D0---------	---------->D4.1	D1---------	---------->D4.2	D2---------	---------->D4.3	D3--------->D4.4	
A12	Surgical Workshop				D1---------	-->D12.1/D4.2	D2---------	---------->D4.3	D3->D12.2/D4.4	
A13	Commercial Trials				D1---------	-->D13.1/D4.2	D2---------	---------->D4.3	D3->D13.2/D4.4	
Table 2  Interdependence and Timing between  the Technical and Validation Work Packages

Allocation of project resources by Work Package: person-months1 and KECU2 
	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 
Deliverable
ID
(a)	Title	Delivery 
date
(b)	Nature

(c)	Dis-semination
Level
(d)	Type
ID, PD or X
(e)	Work-Package
ID
(f)	
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 Architecture	9	SP	PU	PD	WP10	
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 - II	24	PR	PU	PD	WP13	

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 - 
•	to establish an initial network monitoring capability that can be used to support operation
•	maintenance of the infrastructure and to establish a measurement capability, to conduct performance characterisation experiments and to contribute to the collection of long-term performance statistics 
•	to refine those measurement and monitoring tools and develop new tools as needed to study QoS and network management issues.
Deliverables -
•	trans-Atlantic ATM-IP multicast infrastructure to D2 at month 12.
•	initial performance characterisation results to D2 at month 12.
•	network measurement results to D3 and D4 at months 18 and 24.
•	demonstration of a prototype integrated performance monitoring platform to D4 at month 24.
WP11 - MERCI Seminars
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 -
•	reception and assessment of Seminar series.
•	arrange and transmit a seminar in the series.
•	contributions to MERCI deliverables D11.3 and D11.4.
WP12 - Surgical Workshop
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 -
•	arrange and host the reception of MERCI Surgical Workshops in Canada.
•	contributions to MERCI deliverables D12.1 and D12.2

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?
The Users
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.  
The Suppliers
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.
The Dissemination Strategy
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.
Business Plan
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:
•	Audio
	These tools, from UCL and from INRIA, will provide options for high quality audio, good resistance to poor network conditions and encryption.
•	Video
	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.
•	Shared text editing
	This tool, NTE, will continue to be developed and enhanced during the second year of MERCI.
•	Shared Whiteboard
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.
•	Session announcement 
	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.
•	Internet/ISDN gateway
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.
•	Shared visualisation
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 necessary	Comments	
a	Does the project still significantly contributes to the objectives of the programme?	Yes / No	
	
b	Is it 'State of the Art' work, in terms of the application?	Yes / No	
	
c	Is it 'State of the Art' work, in terms of the technology used?	Yes / No	
	
d	Are the objectives of the project being met?	Yes / No	
	
e	Are there definite plans for exploitation of results?	Yes / No	
	
f.	Is there a reasonable balance between the work done and the financial investment in the project?	Yes / No		
B. Application Results:	Scores 1 to 5	Comments	
a	Are the user needs properly reflected in the user requirements and/or the implementation?	1 - 2 - 3 - 4 - 5	
	
b	Soundness of knowledge base	1 - 2 - 3 - 4 - 5	

c	Quality of application's approach	1 - 2 - 3 - 4 - 5	

d	Level of potential interoperability	1 - 2 - 3 - 4 - 5	

e	Content quality of deliverables in relation to project objectives	1 - 2 - 3 - 4 - 5	

f	Soundness of the validation phase
	1 - 2 - 3 - 4 - 5		
C. Project Management			
g	Balanced & consistent methods of approach	1 - 2 - 3 - 4 - 5	
	
h	Realistic time scales and resource allocation	1 - 2 - 3 - 4 - 5	
	
i	Effectiveness of project management techniques	1 - 2 - 3 - 4 - 5	
	
j	Sound schedule of Deliverables	1 - 2 - 3 - 4 - 5	
	
k	Dissemination of results and/or plans for reaching an effective consensus	1 - 2 - 3 - 4 - 5		
l	Strong synergy / integration between different parts of the project	1 - 2 - 3- 4 - 5		

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 : ..................................................