The considerable interest in networked multimedia has been clearly identified, both in studies and in comments from many applications areas. The technology pervades the workplans of the Telematics Programme; most sectors have some aspect of multimedia services in them. Many users would like access to networked multimedia facilities for consultation, conferencing and database access. The need which the project identified was for a number of specific services:

• Multimedia conferencing facilities - often with a clear quality/cost trade-off;
• Audio, often with Video - the quality needed depends on the application and cost;
• Shared Workspace - different application areas need different functionality;
• Multimedia Servers are vital in many application areas
• Range of Network Support is required - again depending on availability and cost
• Range of Workstation Support is needed - and possibly also conference rooms
• Security and Multiple Locations are often needed
• Capabilities for Management and Trouble Shooting are vital

Significant efforts to make packet networks more suitable for network multimedia were coming to fruition. While the throughput of the 2 Mbps Internet was only marginally suitable, the lack of resource reservation made its use marginal. This was changing with both the initial deployment of Resource Reservation and multicast facilities in the Routers, and with the Internet bandwidth increasing with the deployment of ATM and other high speed solutions.

There were significant improvements in Codec boards for workstations at affordable cost; moreover, the general increase in processor speed made it possible to provide more of the functionality in general purpose hardware, requiring minimal specialised boards. This had resulted in only a marginal increase in the cost of making workstations able to incorporate multimedia facilities. Growth in switched ethernet hubs, UTP-5 wiring, low-cost higher speed 100baseT and FDDI LANs had made the local distribution of multimedia relatively straightforward. The quality and cost of video projectors to work directly from workstations made the equipping of conference rooms cheaper. Nevertheless, there were still problems in dealing with audio resulting from the variability of delays when linking multiple sites.

N-channel Basic Rate ISDN for circuit-switched networks had been around for some years; the growth was only then beginning and few workstations or PCs were then able to support these facilities for n>2. Moreover, the protocol structures supported on most of the ISDN boards available (PCs) were not compatible with those on the packet networks. This was changing in two respects: more PC software supported IP; ISDN gateways were becoming available which support the common ISDN protocol structures. It is realised that the H.221 adopted by the carriers for multimedia working on the ISDN is very difficult to input to computers. Some manufacturers were providing boards which do not rely on the H.221; others were providing special boards which allow for the H.221 peculiarities; yet others were providing alternate protocol stacks for next generation multimedia based on other coding algorithms.

Video Servers were (and still are) being developed frantically to supply the anticipated "video-on-demand" market. These had the requisite hardware base needed for this project - but the software facilities were less flexible than we required. Discussions with manufacturers of these devices, several of whom were mentioned in the proposal, indicated that they wanted to develop this market also.

Many providers of workstations wanted to incorporate security features. There was little problem in providing a light level of security; for this it is not clear that there was a serious demand. Stronger security, using RSA and DES, was desirable. Regulatory considerations, particularly in France and the US, still made it unclear whether uniform levels of secure products could be introduced on a world scale. This would restrain the growth of these products.

The research community, particularly in the IETF, always wanted to bring real standardisation into the packet-switched networking environment with a truly flexible multicast capability. This environment is clearly much more powerful, economic and flexible than the circuit-switched model using multiway control units (MCUs); nevertheless, it required and still does require further developments in network and router technology to allow easy deployment of such facilities. The technology was nearly there at the start of the project; the network speeds were nearly there to allow widespread deployment. The project intended to help deploy the technology in the Telematics Sector, that would only be able to embrace it much more slowly without such a project.

CRC (CA) was not in the original proposal, but joined the project de facto at the start. Its participation had not been finalised formally by the EC by the end of the project. Its principal roles were User Interfaces and development of measurement tools. GMD's (DE) main roles were a message-based security announcement system, and the co-ordination of experimental deployment of the technology in industry. INRIA's (FR) main roles were the development of audio & video tools and the protocols for use of DBS satellites. KTH (SE) produced the videos on the seminar and surgical demonstrators, and did some work on conference rooms; they also made detailed studies on multimedia servers. RUS (DE) produced a shared workspace tool in JAVA, and was the hub of the ATM networking. TELES (DE) provided the ITU-T - Mbone gateway. UCL (UK) co-ordinated the project; it provided an audio tool, a transcoding gateway, a considerable part of the User Interface work and the multimedia server; it co-ordinated the ATM activity, the security work, the Surgical demonstrator, and much of the measurement activity; they provided also a conference room. UiO (NO) provided, and co-ordinated, the main activity on Conference rooms.

We aimed to provide software support to all our technology users to the extent that resources were available.

We concentrated much of our efforts on our users in other Telematics projects, in particular MANICORAL. The scope of the support was limited by the budget available, but comprised a willingness to respond to requests for assistance via email, telephone and personal contact.

In addition to the support provided for other Telematics projects, we supported the UK project Remote Language Teaching (ReLaTe) which was already using the tools for language teaching between sites in London and Exeter. The ReLaTe project was particularly interested in being able to use PCs for their work so as to allow a widening of its scope and the lowering of the entry costs to this use of the technology. The porting of the tools to the Microsoft PC platforms (Windows95 and NT) was a major aim of the project and contributed much to the increased use of the tools during the project’s lifetime. The porting also generated more need for user support since PC users tended, in general, to include a higher proportion of the less technically skilled than did users of workstations.

For more general support of users we had to rely on the links we had with the Multimedia National Support Centres which exist, mostly unfunded, in several community countries. These centres provide a first line of support for the tools and are able to filter the user questions, passing on to the developers only those which need their attention.

Our approach to the development of tools was to concentrate on improvement of existing tools and their porting to new platforms, especially to the PC running the Microsoft operating systems Windows95 and NT. Where there were no tools suitable for the tasks we were set to achieve, we developed new ones. Examples of this are the JAVA-based shared drawing tool, TeleCanvas, and the UCL Transcoding Gateway (UTG). In the specific case of the H.320 - Mbone gateway, we were specifically tasked to create this in Workpackage 5.

Improvements were made to the main audio tools RAT and FreePhone to provide resilience in the face of packet-loss by the inclusion of redundancy and Codecs for high-quality sound. In the video component of the combined audio/video conferencing tool, Rendez-Vous, provision has been made for hierarchical coding and work has been done to develop a Codec for wavelet encoding.

We aimed to address both ends of the spectrum of network provision. Where there is high bandwidth available, as with the ATM links provided by the JAMES project, we wanted to provide high-quality audio and video which could utilise this capacity. In the audio field this was to be done by providing high quality codes for both RAT and FreePhone. Rendez-Vous was to provide the hierarchical video encoding to allow a broad range of quality tailored to the actual network quality during the session. At the other end of the spectrum, we aimed to provide mechanisms in the tools to adapt to the lower quality links whilst still providing useful human communications. In RAT and FreePhone, this was provided by the redundant audio encoding techniques implemented in the tools and developed to standards via the IETF.

Participation in, co-ordination with, and influencing of, the IETF and the ITU-T standards activities were made very important activities in the MERCI project. Through the MERCI activities, we aimed to ensure that relevant European practices were fully compatible with the IETF ones - in fact in some areas, like conference control, conference invitation, and key distribution for secure conferencing, we largely set the standards. We collaborated closely with ICE-TEL to ensure that the facilities provided under MERCI security workpackage both fitted into the IETF framework and were usable with the ICE-TEL infrastructure. From all our work we wanted to be sure that the standards used in the MERCI project had worldwide compatibility.

Through the IETF we aimed to maintain the good collaboration with ISI and LBL who are responsible for major US multimedia conferencing initiatives.

The main development work of the project was in the improvement of the tools and their transfer to other platforms, operating systems and networks. Therefore validation and evaluation were integrated into the structure of the project, not just separate activities. Here we rehearse our approach and describe our achievements.

The stated objectives of the project included:

• To validate the tools by their deployment in three Validation Exercises inside the project: a seminar series, surgical workshops and commercial trials.

• To validate the results by deploying the tools in two related Telematics projects: MANICORAL and CoBrow.

Our approach to validation used the following four stages of verification:

1. The components were shown to work by being transferred to another MERCI partner who was able to mount and use satisfactorily the components - usually in conjunction with other MERCI components
2. We held bi-weekly multimedia project meetings. The second stage of verification was that the components worked well when introduced into the bi-weekly meetings.
3. We demonstrated the MERCI tool Deliverables to the CEC (and others) using public conferences or exhibitions as vehicles. This is a very harsh test on whether the components fit together and operate reliably. Since all of our components had to be demonstrated, this stage was an important milestone for them.
4. Finally, we transferred the components to one of the validation workpackages. Here people outside the project subjected them to intensive testing in use. Only when these results were judged satisfactory, did we consider them ready for the demonstration phase - and even then any drawbacks were noted for use in further development of the components.

The validation which we have actually achieved is a mixture of work done within the project, including that done by our commercial partners, that done by other commercial bodies and the feedback from users in other European projects. We have also taken on-board the feedback from the peer reviews of our deliverables.

Within the project we have held 51 multimedia conferences during the course of the project. The conferences have been characterised by generally poor connectivity, despite the availability of JAMES links between some of our partners. The impossibility of integrating these high-speed links with the generally lower speed links to France and Canada has forced us to adapt to the lowest common denominator. We continue to overcome these problems, to some extent, by the use of tools resistant to the adverse network conditions, and anticipate the deployment of the UCL Transcoding Gateway (UTG) will allow some degree of differentiation of quality within a single conference I the future. Network Text Editor (NTE) is always used to show the agenda, which is then interactively developed into the minutes; if connectivity declines temporarily, participants use NTE to communicate. The use of the Robust Audio Tool (RAT) and FreePhone, with redundant encoding for audio, has enabled us to continue to speak and be heard in conditions where loss would have prevented this otherwise. Since we have had MPoll from CRC, we have used this multicast polling tool to record specific votes, such as agreement to the minutes of the last meeting, and to record general impressions of the quality of the conference.

The 10 high-quality seminars delivered during the past 2 years have been fully documented in our deliverables; extracts are shown in the videotape we have produced. Despite the provision of a web-form to allow on-line feedback from seminar participants, we have had only limited feedback from non-project people attending those seminars that were put out over the general Mbone. Most of the seminars have been given over the MERCI Mbone. Initially this was created by the physical separation of the JAMES ATM links; subsequently we used filtering in the multicast routers. We presented a very successful high-quality seminar from UiO as part of the MERCI presence at JENC8 in Edinburgh in May 1997. The seminars were replayed from a Server at the Barcelona Telematics Conference in February 1998.

A Workshop in Interventional Uro-Radiology and Endourology demonstrating novel, minimal invasive surgery techniques was held at the Middlesex Hospital in London on February 20, 1997. The workshop, consisting of lectures and a number of live operations, was multicast over the project’s 1 Mbps JAMES ATM links to surgeons in Glasgow, Gothenburg, Stockholm and Stuttgart. Two operations from the Sahlgrenska Hospital in Gothenburg were also multicast. This event, demonstrating improved technical quality over a similar event multicast by the MICE project in November 1994, used increased bandwidth, encryption and digital recording on the UCL multimedia server. A full report and video of this event was delivered as D12.2.

Our commercial partners submitted a report midway through the project which emphasised the need to increase the usability of the tools by improving the user interfaces. Since their report we have put significant work into the improvement of the usability and have produced new user interfaces for the Session Directory (SDR), the Robust Audio Tool (RAT) and the integrated interface originally designed for the language teaching project ReLaTe.

We began to run two field trials in collaboration with employees of the German Telekom during the first year of the project. Silicon Graphics workstations and Mbone tools were installed and trials began on a network consisting of two LANs interconnected over ISDN. Initially, user tests were done with audio and WB tools only due to problems with the existing SGI video cards. The two trials involved different groups of people within Deutsche Telekom and were completely independent from each other. They involved:

• Use on the desktop by a research and development team at both of the two locations which was given the tools for their everyday use.
• Use in a multimedia meeting room for demonstration and presentation purposes and for practical use in virtual meetings.

Installation and testing went well, but routine use was not achieved, largely due to organisational delays on the side of our partner and some technical difficulties. It was hoped to develop the trials further in the second year of the project. We found much support and interest within the user community and a workplan was formulated for these further trials; unfortunately the management was unable to commit itself to these trials, due to major organisational restructuring.

MANICORAL has had much support from us; we have provided the software and some guidance in its use to the project's end-users, AFRICAR, and our technical staff have given assistance to those engaged in the work of designing and developing a multicast shared-visualisation tool. Development of such a tool is not an easy task at present, since the underlying work on the development of standards for reliable multicast are still at an early stage of the standardisation process.

MANICORAL has been using the tools throughout the two years of the project and we have maintained close collaboration with them in the evaluation of the tools. In September 1996 we met with them in Delft where their needs were discussed and their observations were made available. Subsequently one of their project members visited UCL to discuss their input to our evaluation procedures and, following this visit, in February 1997, we received a Heuristic Evaluation of the tools. This reflected experiences following on the increased use of the tools by the AFRICAR project, the end-user in the MANICORAL project.

Peer reviews have been generally positive, but have provided helpful suggestions, especially in the case of some of the tool deliverables. That for the Multimedia Conference Recorder (MMCR) was particularly pertinent. We have taken up the positive suggestions made where this has been appropriate; in some cases, where the deliverable was an early alpha or beta release, we have been aware of the need for improvements and have even had plans to introduce some of those suggested. We have had no major criticisms of our work from our peer reviews.

Our collaboration within the project has been excellent, helped by the fact that several of the partners have been in successful collaborations with each other over a number of years. It is evidently easier to absorb new partners into an existing successful group than to start from scratch.

We have had successful collaborations with our users, especially in the MANICORAL project. Collaboration with MANICORAL began in both technical and user support roles. The technical collaboration continued, but suffered form the differential timescale for development of the MERCI tool TeleDraw and the MANICORAL shared visualisation tool; collaboration at the detailed technical level is difficult in circumstances where one party needs something urgently which the other is developing on a longer term basis. Collaboration with the users of our tools was more successful since we had good feedback from them both in reports and from attendance at each other’s meetings.

Our objective in developing our conferencing software has been to provide high quality multimedia components to meet the conferencing needs of diverse users over a variety of platforms. Work has therefore focused on improving the quality of the components, and on increasing the range of platforms on which they can be run. We here distinguish between those components offered as part of the public domain software delivered by the project and the products which are sold by New Learning.

The initial H.320 to Mbone gateway from TELES will not be available as a product in the near term, although the H.320 to H.323 element of it is available now.

MERCI has delivered a toolkit for building tailored applications for real-time interactive multimedia collaboration systems for specific user groups.

The toolkit comprises a set of tools which conform to industry standards and allow much functionality in common. The tools allow users to communicate directly from one to one over the regular Internet, in the manner of a phone call, or, via the Mbone, to participate in a multi-user conference involving many simultaneous participants. They all offer encryption to preserve confidentiality. Individually they offer the following functionality:

Audio We have delivered two tools, FreePhone from INRIA and RAT from UCL. The tools provide options for high quality audio, offer good resistance to poor network conditions. RAT sessions can be encrypted.

Video The video tool in Rendez-Vous provides 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. The VIC video streams can be encrypted

Shared text editing This tool, NTE, allows the users to import or create, edit and save text documents. It distinguishes clearly between users and has proved its use in co-operative development of meeting minutes and in networked language teaching. The data streams can be encrypted.

Shared Whiteboard The new MERCI TeleCanvas whiteboard tool, written in JAVA, is available for platforms which provide JAVA support including, we hope, the MAC. It provides basic functionality expected in a whiteboard, including drawing, text input and the ability to import standard image files. The data streams can be encrypted.

Session announcement The current session announcement tool, SDR, provides the means to advertise and to invite attendance at multimedia conferencing sessions. It also allows the automated start-up of the sessions. The announcements can be made by secure multicast or by secure messages (SCUA).

Network Monitoring MultiMON is a monitor that collects, organises and displays all the IP multicast traffic that is detected at the location of the MultiMON Server. While MultiMON is a general-purpose multicast monitoring tool, it is intended in particular to monitor multicast traffic on local network segments and should assist a network administrator in managing the traffic on an Intranet. MultiMON is built on a client/server basis which allows the data collectors (Servers) to be distant from the GUI front end displays (Clients).

Opinion gathering MPoll is a real-time opinion polling and rating collection tool that uses multicasting to distribute questions and responses to all multicast session participants. MPoll was developed with the following uses in mind:

• collecting quality ratings during multicast sessions
• collecting opinions and votes during multicast collaborative work sessions
• collecting opinions on general topics or current events

All the tools are based on the Internet protocols and use IP multicasting to achieve scalable multi-user interactions in all the functions provided. They are independent tools which can nevertheless be integrated into novel ad-hoc interfaces such as that developed for the ReLaTe project (see details under Integration below).

Software The software is available free of charge via the MERCI web site [ref]. It runs on a Windows95 and WindowsNT platforms on the PC and is available for Sun’s Solaris and several other Unix platforms.

Hardware Any Sun workstation will run the tools, including audio using the built-in audio and video reception. To transmit video requires the addition of a SunVideo framegrabber board and a camera.

For the PC, the minimum specification needed to run the Mbone tools is:

• Pentium PC (133mhz or above) running Windows 95 with 16Mb ram, 10Mb of free hard drive space
• 16bit full duplex sound card (e.g. Turtle Beach Daytona)

• Video for windows compatible frame grabber card (if transmission required)
• graphics card capable of a minimum resolution of 1024x768x16bit (colour palette)
• video camera (if transmission required)

More is better in this situation. If you can manage it, get:

• Pentium P200MMX or better running Windows 95 with 32Mb ram, 10Mb of free hard drive space

• 16bit full duplex sound card (e.g. Turtle Beach Daytona)
• 3D graphics card with 4Mb RAM with DirectDraw support (eg the Matrox Millennium II 4Mb)
• 17" colour monitor
• Video for windows compatible frame grabber card (e.g. Haupauge WINTV card)
• Colour video camera

We have an integrated interface which allows the tools to be combined into a single window containing audio, video and shared workspace tools. This interface was originally developed for the Remote Language Teaching (ReLaTe) project and has been modified to allow the user to use both text editing capabilities of NTE and the drawing and image display features of wb in the same session by selecting which to use at any given time. The integration makes it easy to move between the use of a text editor when this is needed, especially for recording material for subsequent reuse in another context, and the whiteboard for freehand drawing and importing images. This integration has given a more powerful tool to the language teachers which is also available to other communities of user.

This integrated interface has been ported to the PC platform during the project, but was not sufficiently reliable at the end of it to be delivered with the final software deliverable D2. We have nevertheless made great strides in porting the tools to the Windows PC platforms and have delivered the tools on all of the following platforms Sun SPARC running Solaris and PCs running Linux, Windows95 and WindowsNT.

Portability has been enhanced by the development of the Java-based shared drawing tool TeleCanvas.

The recorder has been considerably improved. It has been integrated with conference announcements, provided with fast forwarding and the capacity to record wb sessions. In can now record and replay encrypted sessions.

The recorder consists of two parts a server and a client. The server program listens for connections from the client(s). Clients can access the server to perform the following functions: recording, playback and browsing the stored sessions.

The server records and replays RTP packets. It comprises a server engine written in Objective C and a User Interface written in Java. It can store and replay all streams in multimedia conferences including encrypted sessions.

The server runs on Solaris 2.x and should be installed on a machine that has as much power and storage as possible. The client will run on any platform supporting Java 1.1 with the Mbone tools (RAT, vic, wb, NTE and sdr) installed and an IP connection to the server.

The server runs only on Sun Solaris platforms, but the client can run on any platform which supports Java 1.1 and the Mbone tools.

This new tool, released as part of the Software deliverable D3, allows a client at the end of a low bandwidth link, such as ISDN-2, to link to an Mbone conference through a server running on the Mbone. The gateway server can multiplex and/or transcode audio and reduce video bandwidth by lowering the rate or sending only selected streams. Plans exist to enhance this gateway to provide relay facilities for shared workspace tools also.

The gateway can include a client running on a Java 1.1 platform in an Mbone conference allowing the client to define the allocation of bandwidth between the various media streams over the link in use. The server can handle multiple clients.

There are two main components, the gateway and the client, each of which comprises a number of smaller modules. The gateway is written in C and uses the tools SDR, RAT and the Video Gateway (VGW) from University of California at Berkeley (UCB) to effect the relaying functions. It consists of a set of daemon processes from which a client application may receive relayed unicast streams from the multicast-capable server. The client application for the gateway server is written in Java.

The gateway must run on a Unix workstation running Solaris 2.x which is linked to the Mbone. The client will run on any platform supporting Java Development Kit (JDK) 1.1 and must be linked to the server via an IP channel which will, typically, be running over ISDN2.

The server is modular and potentially portable to other platforms. The client is a single application which is as portable as Java.

The world of teleconferencing is roughly split into two areas as far as standards are concerned: the IETF which has developed a conferencing architecture that primarily supports loosely coupled teleconferences in the Internet and the ITU-T which has developed several series of Recommendations for more tightly coupled multimedia communications in various networks including particularly ISDN (H.320) and the Internet (H.323).

The gateway allows multimedia terminals (typically Windows or UNIX-based workstations) that are based on either of the two standards to interoperate seamlessly. Specifically, H.320-based end systems connected to the ISDN – these systems include typical conference room equipment – are able to communicate with Mbone tools running on workstations connected to the Internet.

To achieve interoperability, the MERCI project partners have developed a gateway. Architecturally, the MERCI gateway consists of two gateways:

• an H.323 - Mbone gateway as developed within the MERCI project
• an H.323 - H.320 gateway, developed in the EU project DIVINE and extended for MERCI

This subdivision not only allowed us to leverage results from other European projects, but also had benefits from the market perspective. With the advent of H.323, the industry is converging towards using this standard for teleconferencing in corporate networks as well as in the Internet and as a basis for Internet telephony. This makes the Mbone - H.323 gateway very valuable in its own right. The gateway functionality comprises

• converting the control protocols
• adapting transport protocol types
• providing a mapping between the two conferencing paradigms

Architecturally, the MERCI gateway consists of two gateways:

• an H.323 - Mbone gateway as developed within the MERCI project
• an H.323 - H.320 gateway, developed in the EU project DIVINE and extended for MERCI

These tasks are distributed across the two gateway components as follows:

This gateway implements the entire H.320 protocol suite including access to basic rate ISDN lines. It is responsible for the conversion of packet based information transmission on the H.323 side to bit-stream oriented transmission on the H.320 side. Furthermore, this gateway translates the H.320 call set-up and control protocols into the respective H.323 counterparts.

This gateway is implemented on a PC platform for Microsoft Windows 95. Internally, it consists of an instantiation of both a full H.320 and a full H.323 protocol stack as they are found in terminals. Linking these is a bridging application residing on top of the two which is responsible for receiving calls from either side and forwarding them to the other instead of locally answering the call. Besides translating the control protocols, the gateway accepts audio and video data packets from the Mbone side and transmits the information as bit streams to the H.320 side and vice versa.

This gateway implements the adaptation of the H.323 call set-up and control protocols to the corresponding Mbone protocols (if available) and provides new mechanisms for mapping the functionality where no Mbone counterparts exist.

The H.323 - Mbone gateway uses a similar internal structure to that of the H.320 - H.323 gateway; however, it is currently implemented on two workstations rather than integrated on a single one. A PC running Windows 95 is used for the H.323 side – to re-use the H.323 protocol stack of the H.323 - H.320 gateway while the Mbone part is implemented on a SPARCstation under the Solaris 2.5 operating system.

On the PC side, a simple client accesses the H.323 protocol stacks and forwards the messages received from the H.323 to the workstation using a simple RPC-style mechanism on top of a TCP connection. By this mechanism, it also receives messages to be sent via H.323 from the workstation and forwards them accordingly.

The actual protocol converter of the gateway runs on the workstation. It is based on the SIP/SDP implementation of SDR and accepts SIP messages from the Mbone side and generates the corresponding H.323 call signalling and vice versa. The H.323 - Mbone gateway is in principle not required to access the media streams themselves since H.323 and Mbone applications use the same protocols and data formats. However, it can, optionally, launch a multicast-to-unicast converter (MUC) to convert media packets multicast on the Mbone into unicast packets on the H.323 side and vice versa, if this is required.

Figure 1 shows the architecture of the gateway implementation and its components.

Finally, the conference control protocol SCCP which is still under development needs to be integrated into the gateway – for reliable detection of call termination on both ends, for providing elaborate conference control mechanisms, and for exchanging capability information about the involved systems.

Issues for further study beyond the MERCI project comprise mixing audio and (remotely or automatically) selecting the video feed to be forwarded from the Mbone to the ISDN, the integration of loosely-coupled conferences into H.323 according to Recommendation H.332, and the provision of more elaborate security mechanisms in the gateway.

The current version of the gateway requires a Sparc station running Solaris 2.5 and a PC running Windows95.

Further work is needed to complete the integration of both H.323 - Mbone gateway components into a single system (potentially a PC running Solaris 2.5) and the integration of means to detect that an Mbone terminal has terminated a call (by parsing the media control streams for packets indicating this). The nature of the gateway means that it is inherently difficult to make portable. The need for efficient and timely conversion predicates the use of efficient low-level code which is difficult to make portable.

We set up and extensively used a high quality MERCI MBone between several of the partners using the JAMES ATM links. The JAMES ATM infrastructure provided permanent ATM VPs between five of the MERCI. Each VP carried an Mbone tunnel which, when not in use for special experiments, carried normal Mbone traffic. The bandwidth of the ATM VPs was normally 1 Mbps ; there is significantly less bandwidth at the IP level. For higher quality video, a minimum 512 Kbps is required per video stream, with additional bandwidth required for the audio. At times we were provided with 2Mbps or even 4 Mbps channels.

Figure 2: Network topology including the JAMES links.

was more difficult. We tried to achieve this by use of increased thresholds and metrics on the tunnels, but this was not effective. Input packet filtering was also considered, but would have had an adverse effect on general multicast streams since surrounding multicast routers would have continued to route traffic to the filtering multicast router causing such traffic to be lost in a so-called black-hole. The use of such techniques requires features in multicast routing programs which are not currently available.

Special precautions were taken to prevent global Mbone traffic from reaching the subnets involved; this was achieved by packet filtering and by the use of stub subnets. These stub subnets were created by isolating the subnets from tunnels carrying non-MERCI traffic, by taking tunnels down in the local multicast router or by reconfiguring tunnels in other multicast routers.

We have set-up and used the DBS facilities provided by Eutelsat to allow satellite transmission with low-bandwidth, multicast return channels. The downlinks operate with 2 Mbps streams - i.e. equivalent to the better ATM channels provided. The transmission used the DVB European digital television formats,. It required a special decoding card between the satellite antenna and the receiving PC. This configuration is very suitable for sites which cannot be serviced economically with international medium speed internet traffic.

Using the UCL Transcoding Gateway (UTG), it was possible for users to participate in high quality multicast conferences from simple PCs over slow access networks. Because the UTG does multicast-to-Unicast conversion, there is no need for the access workstation to support multicast. Because of the support for audio multiplexing, it is possible to ensure that all the audio traffic is passed down the low speed link if at least that amount of bandwidth is available. The low-speed side of the UTG is rate-limited, so that one can ensure that the shared workspace traffic has the next priority, and that the video makes use of any bandwidth remaining. Using this UTG, we have been able to participate from home using one or two channel ISDN in high quality multimedia conferences. Of course the quality to the home workstation was of comparatively low quality, but its use did not impact the high quality conference proceeding. It is advisable to use two B-channels if video is required.

By using the ITU-T - Mbone gateway, it was possible for one H.320 workstation to enter an Mbone multimedia conference. It should have been possible to go in the reverse manner, but the signalling between the Mbone workstation and the ITU-T MCUs had not been completed by the end of the project.

Our interest in developing and applying standards in the development work of the project has been manifested in the considerable efforts we have made to participate in the work of the relevant standards bodies of both the Internet and of the ITU-T.

We regularly attended the multimedia conferencing and security sessions of the IETF. We were key members of the MMUSIC group on conference control, and the Audio Video Transport group. Through the MERCI activities, we ensured that relevant European practices were fully compatible with the IETF ones - in fact in some areas, like conference control, conference invitation, and key distribution for secure conferencing, we largely set the standards.

We have been participating in the new initiative to standardise multimedia server interfaces. In the security area, GMD and UCL were particularly strongly involved both from the MERCI and ICE-TEL perspectives. We collaborated to ensure that the facilities provided under MERCI fitted into the IETF framework - but also that they were usable with the ICE-TEL infrastructure.

We retained also good collaboration with ISI and LBL who are responsible for major US multimedia conferencing initiatives. Reports on all the IETF meetings we have attended are available through the Scimitar project.

During the course of the project we have made the following contributions to the standardisation process:

At the IRTF meeting associated with the 38th IETF meeting in Memphis, UCL was represented at the meetings on reliable multicast.

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.

TELES participated in the H 324 Interoperability trials at Gaithersburg.

TELES has regularly attended the meetings of the ITU-T SG 8, SG15 and SG16.

Since the Web allows the integration of sound and video with other media types, increased interest has been shown in the integration into the Web of live audio and video applications such as those developed in MERCI. 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" was held at INRIA to examine the relevant issues.

INRIA worked with the W3C to prepare/participate in the RTMW workshop. Mark Handley, Jon Crowcroft (UCL) and Jean Bolot (INRIA) were the representatives for MERCI.

Early in the project we developed an architecture for security in the project which we delivered as D10.1 This deliverable provided an overview of the facilities available in a number of other projects, concluding that only a specific subset of ICE-TEL’s were applicable. Van Jacobson's were not well documented, the IETF and the ITU-T activities were not fully compatible and, in many cases, the relevant standards were still being defined. We reviewed general security considerations, made an analysis of security implementations as they are relevant to conferencing and provided an overview of the ITU-T protocols relevant to conferencing; many of which needed to be extended for secure conferencing.

In light of all this we were able to specify the security procedures to be used for Mbone conferencing. These included both securing the basic tools and providing mechanisms for key distribution. Our main proposals were the use of modified versions of the Session Announcement and Session Description protocols, which are reliant on Public Key systems, and methods for key distribution by Directory, WWW and electronic mail procedures. We also reviewed the need for securing coupled ITU-T and Mbone conferences. The ITU-T mechanisms were not fully defined and we concluded that different facilities for securing the coupled systems were needed.

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 and KTH are already putting on full courses and UCL plan to use the technology to assist in the teaching of a course in the Computer Science department in the next academic year. Hewlett-Packard are working with this project to gain an insight on how feasible it now is to organise technical 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. With the deployment of the JAMES links between partners across Europe, we have been able to use these, in conjunction with our good local infrastructure, to relay operations from an operating theatre in Sweden and a surgical workshop at UCL to sites across Europe. These operations were watched by doctors at that workshop, in seminar rooms at other hospitals and on individual workstations. The impact this will have for medical consultation will be immense as we are able increase the use of our improved tools over the JAMES and TEN’34 networks, incorporating higher quality video and audio, and to introduce better quality instrument data used by the medical practitioners. Because we have embraced lower levels of technology, namely ISDN through a new gateway service, we can also 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 for further deployment is over-powering.

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 have made for greater use of our work of porting to those platforms. 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 have plans for major demonstrator projects in the MECCANO project scheduled to follow MERCI in early 1998.

One outcome of the activities of this project is the commercialisation of components of the Electronic Classroom through the UiO spin-off company New Learning AG, created in early 1997. This commercialisation is expected to lead to substantial markets opening up for Distance Education. We plan a major trial in this area for MECCANO which will involve the use of Direct Broadcast Satellite (DBS) technology. Of particular interest is the potential for deploying this technology in distance learning situations where the conventional communications infrastructure is poor. We are planning a major initiative with INCO partners in Cyprus and Eastern Europe to deploy applications of the technology for them.

The area of Interactive Cable TV is now 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 IBCoBN); however, we are also discussing with other industrial partners new initiatives in Home TV applications.

We feel the Server facilities we are providing are important. During the past year, we have completed a survey of current commercial and other multimedia conferencing servers and released the MultiMedia Conference Recorder (MMCR) as part of the Software deliverable D3.

Over the next year we expect the routers on the Internet to continue to migrate towards high performance Mbone technology. As this movement progresses, it should also provide the capability of adding Resource Reservation. This will make possible significant deployment of the MERCI technology for high performance conferencing. We believe that this will make very serious inroads into the professional conferencing market. The availability of high performance ITU-Mbone gateways the development of which has begun in MERCI, will be extremely important because of the likely lag time before the value of the Mbone mechanisms is fully accepted; this work will be continued in the MECCANO project.

Various manufacturers have expressed interest in producing commercial products based on the MERCI toolkit. Details of specific plans are contained in the Technology Implementation Plan (TIP) which we submit with this Final Report.

Copyright information.