University College London









Peter T Kirstein

Roy Bennett





Multimedia Education and Conferencing Collaboration over ATM Networks and Others


The objective of the project was to provide all the technology components, other than the data network itself, to support collaborative RTD through the deployment of enhanced tools for multimedia collaboration in Europe. The project aimed to improve and deploy the existing toolsets with a particular application aim of distance education and of conferencing. Verification activities were pursued inside the project, in other Telematics projects and other projects to stress each of the technical activities.


Setting the Scene

MECCANO continued the aims of the MERCI project to promote the use of packet-based multimedia conferencing amongst the European Education and Research community.

The project took an holistic view of the many problems which arise in the deployment of multimedia conferencing. Its overall objectives were to provide improved interactive tools, running on both UNIX workstations and PCs, using Internet and ITU-T standards, with Security and Server facilities, operating over a variety of networks and providing medium and high quality conferencing both on workstations and in conference rooms

The Approach

The primary thrust was not application development, but rather application support in other projects - developing further tools only when necessary.

Most developments were undertaken to meet users' stated needs; for example, the modification of NTE to allow multiple character sets for language teaching. The partners carried out many of these tool developments under related initiatives. The project used established standards and helped to set new ones. To provide user support, it made facilities available on multiple platforms, including IPv6. Major demonstrations were made in Teaching and Seminars over diverse networks, including DBS.


In summary we made major advances in the following areas:

Systems architecture

We delivered a major work on the architecture of multicast, multimedia conferencing systems.

User Toolkit

Most MECCANO tools were developed or adapted to run on a range of platforms, including most versions of MS Windows; core applications now run on IPv6 also. We have implemented new standards for error recovery in the audio tools RAT and FreePhone and delivered improved versions of the shared workspace tools AOFwb, dlb and NTE.

We have designed a new inter-tool communication protocol, Mbus, which we have implemented widely. In RAT and the video tool VIC, its inclusion has made synchronisation between them now possible. Mbus in RAT has also made possible the use of RAT’s component parts in novel ways in gateways and transcoders.

Performance of the tools ported to PC platforms has been improved. We released a version of VIC supporting transmission for several video boards.

Also, we have tested tools developed by others.

Conference recorder

A major redesign of the MMCR server has been completed, with the implementation underway.


We have developed several new gateways which allow communication between PSTN, ISDN and the Mbone. Others allow H.323 audio to Mbone and SIP to AVSC control translation. We delivered an RTP reflector which has been used to counter the effects of the unreliable multicast networking. Also, we have redesigned the transcoding gateway, UTG.

Video server

The implementation of the video server architecture which we delivered uses the Sun Media Center; we delivered also the NL multimedia server, software based on its hardware conferencing product.


We have used the DBS facilities provided by Eutelsat for satellite transmission with lower-bandwidth, multicast return channels. We have done this using links provided by the TEN-155 Managed Bandwidth Service (MBS) to convey material to the uplink at INRIA.


We have spent much time and effort with the network providers to improve the multicast connectivity in Europe. We used the MBS from TEN-155 to deliver high-quality conferencing between key partners.


We delivered an improved architecture for secure conferencing and have implemented a new Secure Conference Store (SCS) to provide more user-friendly access control and encryption via the web.


Seminars We have tried, with mixed success, to deliver seminars over the normal European multicast network. Those delivered via the TEN-155 MBS and EUTELSAT’s DBS were of consistently high quality.

Events We multicast the launch of TEN-155 from Essen in February 1999, including a successful demonstration of project technology using the TEN-155 MBS (see picture above).

Our user community

Our conferencing tools have been used by the many projects which we have supported. We have users in the Polish medical community in Krakow, and throughout the EC higher education and research community.

Conclusions and Plans for the Future

We have greatly improved the usability of the tools, at the same time simplifying considerably the use of the features for confidentiality and security.

We have demonstrated the efficacy of DBS for use in wide-area distance learning applications, especially in conjunction with higher-bandwidth MBS links. We expect this technology to be developed further.

Contact Details

Project Name:

MECCANO – Multimedia Education & Conferencing Collaboration over ATM Networks and Others

Research Area:

Multimedia Conferencing for the European Education and Research Community


1 June 1998 – 31 May 2000


Overall cost: 2,050,000 ECU

European Commission contribution: 1,100,000 ECU


Research, Videoconferencing, Multicast, ATM, IP, Mbone, Multimedia, Distance Education

Key Project Participants:

ACC                                       (PL)

CRC                                       (CA)

HPLB                                    (UK)

INRIA                                    (FR)

RUS                                       (DE)

TELES                                   (DE)

UCL                                      (UK)

University of Oslo                 (NO)

Project Co-ordinator:

Professor Peter T Kirstein

Tel:+44 (020) 7679 7286

Fax:+44 (020) 7387 1397


Project URL:





Table of content


Part I Executive Summary                                                                                                                                                      i


Part II Final Report

1.     Setting the Scene. 2

1.1.        The challenge. 2

1.2.        The background and the project.. 2

1.3.        The role of the key partners. 3

2.     Approach.. 4

2.1.        Application support for users. 4

2.2.        Tool development.. 4

2.3.        Standards. 5

2.4.        Evaluation and validation.. 5

3.     Results and Achievements. 10

3.1.        Concrete results. 10

3.2.        Networks created/used.. 17

3.3.        Standards contributions. 18

3.4.        Major results in execution.. 18

3.5.        Technical & socio-economic assessment.. 19

4.     Conclusions and future plans. 20

4.1.        Review of the technology achievements in the context of future activities. 20

4.2.        The Further Plans of the MECCANO Partners. 22


5.     Contact details.................................................................................................... 23


Appendices                                                                           (In separate cover)

Appendix A - Cover pages from all deliverables


Appendix B - Information dissemination materials.


Appendix C - Contract Management Information.

1.                Setting the Scene

1.1.             The challenge

Considerable interest in networked multimedia has been clearly identified, both in studies and in comments from many applications areas. 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 also for conference rooms

·         Security and Multiple Locations are often needed

·         Capabilities for Management and Trouble Shooting are vital

1.2.             The background and the project

This is the third in a series of projects – MICE[1], MERCI[2] and now MECCANO which has aimed to bring multicast, multimedia, conferencing from a research prototype to a useful and usable system. For reasons that will become clearer in Section 4 on Conclusions and further plans, it is also the last of that series. At the end of the MERCI project, the tools were usable and supported, but still did not run very well under Windows or in any sophisticated mode. Under MECCANO, the range of networks supported grew – with the emergence of ATM networks and DBS satellites. There was a fairly good European multicast service – largely co-ordinated by UCL under the MERCI project. The range of gateways was very limited, and they were not really in a deployable state. Significant efforts had been made to ensure that 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.

By the start of the project, the improvements in Codec boards for workstations at affordable cost, and the general increase in processor speed made it possible to provide most 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 was well-established, though 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 now usually supported IP; ISDN gateways were becoming available which support the common ISDN protocol structures. While the support of the H.320 adopted by the carriers for multimedia working on the ISDN was the most common, the H323 for working on LANs was becoming freely available – with H.323 – H.320 gateways commercially available. Some manufacturers were providing boards which incorporated IP and multicast; others were providing protocol stacks both for the next generation multimedia based on other coding algorithms, and for the next generation of IP – IPv6.

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 constrain the growth of these products. More seriously, the concern with network security was making it very difficult to deploy multicast-based services through firewalls in commercial environments.

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 there to allow widespread deployment.  The priority for deploying it nationally was already strong; however the interest in international deployment was still marginal. It was clear that the project intended to help deploy the technology in the Telematics Sector; that sector would be able to embrace it much more slowly without such a project.

1.3.             The role of the key partners

ACC (PL) contributed to five of the workpackages with major work in the development of gateways and a multimedia server. It was also active in the support of users in Poland, providing network support, helpdesk facilities and translations of the User Guides into Polish. CRC (CA) was a non-funded partner. Its principal roles were in the promotion and support of applications and the monitoring and troubleshooting of the network. The key contributions of HPLB (UK) were in the fields of defining the architecture and assessing the usability of the tools.  INRIA (FR) was concerned mainly with the development of audio & video tools and of the protocols for use of DBS satellites. RUS (DE) put much effort into demonstrations and user support, with translations of the User Guides into German. It continued work on its shared workspace tool in JAVA and provided also a major contribution to the network measurement activity. TKI (DE), in conjunction with TELES (DE), provided new gateway developments towards a full ITU-TŰMbone gateway, based on the Mbus protocol, and major contributions to standards developments. The universities of Erlangen, Freiburg and Mannheim contributed conferencing tools for Distance Education, which were being developed with German DFN financial support; they supported trials and provided facilities not otherwise available to the MECCANO team. UCL (UK) co-ordinated the project;  it provided a large part of the effort in defining the overall architecture and specifically that related to security; it was a major contributor to the project’s standards activities; it produced an improved audio tool, IPv6 versions of the key tools, and co-ordinated the Managed Bandwidth Service (MBS) trials for TEN-155. UiO (NO) co-ordinated the main activity on the consolidation of applications; it also made substantial efforts in the development of tools, in network support and in the conference control activities.

2.                Approach

2.1.             Application support for users

We aimed to provide software support to all our technology users to the extent that resources were available. 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.

We supported a number of major teaching projects which were using the tools. Most notable of these were the VIROR project[3] in Germany supported by UF and UM and the PIPVIC2[4] project in the UK supported by UCL. These activities are reported in the deliverable R9.2. Such users benefitted especially from the continued improvement to the tools on the PC platforms.

In addition to providing support for our users in the support workpackage, we facilitated the work of our associate partner SSEES in its promotion of a series of lectures given by the Institute of Social Studies of the University of Warsaw to students in London.

The porting of key tools to IPv6 was necessary for some of our users - in addition to being an important step forward for the technology in its own right.

For more general support of users we set up a series of email lists open to users for each of the tools. For first-line support we continued to rely on our links with those Multimedia National Support Centres which still exist, mostly unfunded, in several community countries; these are able to filter the user questions, passing on to the developers only those which need their attention.

Finally, we did not rely only on external feedback. Hewlett Packard, CRC and UCL made a detailed study on the usability of the whole system; this provided a semi-independent indication on the technical developments required

2.2.             Tool development

Our approach to the development of tools was to concentrate on improvement of existing tools and their integration into new user environments. A major example of this is the porting of the basic tools, RAT, NTE, SDR and VIC, to the IPv6 environment. Where the tools were not suitable for the tasks we were set to achieve, we developed the necessary new features. An example of this is the changes made to the shared text-editing tool, NTE to allow it to handle the multiple fonts needed for language teaching with other than Latin alphabets. Specialist tools were used for teaching in projects such as VIROR where AOFwb and dlb provided features including multi-format image distribution, and session recording with replay on demand.

Improvements were made to the main audio tools RAT and FreePhone to develop further their resilience in the face of packet-loss by the inclusion of Forward Error Correction (FEC). Improvements were made also in the Codecs for high-quality sound. We have introduced hierarchical coding into the video tool, VIC, together with an Mbus implementation which allows synchronisation with the audio tool RAT.

We aimed to address all levels of the spectrum of network provision. Where we had high bandwidth available, as with the MBS links provided by the TEN-155 project, we provided high-quality audio and video which could utilise this capacity. In the audio field this was done by using the high quality codecs in RAT and FreePhone. 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. This was achieved in RAT and FreePhone by use of the redundant audio encoding techniques, combined with the provision of low-bandwidth Codecs. Hierarchical video encoding allowed a broad range of quality, tailored to the actual network quality during a session.

Much effort was put into the development of gateways and relays to meet the needs of users to communicate over a selection of networks which are heterogeneous in terms both of their quality and their presentation. We have redesigned the UCL Transcoding Gateway (UTG), developed in the MERCI project, and, in AudioGate and StarGate, we have started development of a new range of tools which address these needs in a flexible and effective way. We have also developed straightforward RTP transcoding gateways to meet the immediate needs of our tool users, ourselves included, to have connectivity in face of the frequent failures in multicast connectivity.

2.3.             Standards

Participation in, co-ordination with, and influencing of, the IETF and the ITU-T standards activities were made very important activities in the MECCANO project. Through our 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-CAR to ensure that the facilities provided under MECCANO both fitted into the IETF framework and were usable with the ICE-CAR infrastructure.  From all our work we wanted to be sure that the standards used in the MECCANO project had worldwide compatibility.

In addition to participating in the key technical working groups of the IETF, co-chairing AVT, MMUSIC, SIP and UDLR, we took a leading part in the promotion of the Message Bus (Mbus) standards for local coordination which, originating in the preceeding MERCI project, have been considerably refined and improved during MECCANO. We were responsible for the promotion of standards for FEC in the RTP audio domain through their implementation in the MECCANO audio tools, FreePhone and RAT.

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

2.4.             Evaluation and validation

The main development work of the project was in the improvement of the tools and the development of a series of gateways and relays. 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.

2.4.1.         Plans for validation

The stated objectives of the project included:

·       Regular research  seminars given from the sites of the partners - and from North America

·       Use in the research community, including over the national research networks of UKERNA, DFN, UNINETT, and CA*Net II of seminars, lectures, research collaboration and home working.

·       Use by at least 8 other Telematics, ESPRIT and ACTS projects and several national ones. Besides tools from MERCI and ICETEL projects, it will utilise results from ICE-CAR, current National and EC projects.

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

1.        The components were shown to work by being transferred to another MECCANO partner who was able to mount and use them satisfactorily, usually in conjunction with other MECCANO 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 MECCANO tool Deliverables to the CEC (and others) using public conferences or exhibitions as vehicles.  This is a very harsh test of 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, that done by other bodies and the feedback from users in other National and European projects.  We have also taken on-board the feedback from the peer reviews of our deliverables.

2.4.2.         Validation within the project

The activities within the project have been characterised by generally poor connectivity, despite the availability of improved international connectivity from TEN-155. The bandwidth has been adequate, but there has been consistent failure of the multicast infrastructure. The use of MBS links provided by TEN-155 has been very useful in the specific instances of demonstrations and our use of the DBS network provided by Eutelsat.     Multimedia conferences

During the course of the project, we have held 29 multimedia conferences for project management and a similar number for technical discussion. Since most of these conferences have suffered from the poor connectivity mentioned above, we have used Network Text Editor (NTE) 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. Unfortunately, no tool can counter the effects of the network partitioning caused by the multicast routing problems.     Lecture series from the Institute of Social Studies, Warsaw University

In conjunction with the School of Slavonic and East European Studies (SSEES), the Institute of Social Studies at Warsaw University (UW) transmitted a series of ten lectures under the title Social Change: Adaptation and Resistance. ACC, in conjunction with the Centre for Open Distance Multimedia at the UW, assisted in organising the transmissions and provided technical support during the project, specifically during the transmission of the lectures.    Seminars

During the course of the project, we have delivered 3 seminars over the public multicast network:



UDLR (Unidirectional link routing)

Walid Dabbous, INRIA Sophia Antipolis

The dlb seminar

Werner Geyer, University of Mannheim

Non-secret encryption and public-key cryptography

Dr. Whitfield Diffie

These have been documented in our deliverables. Despite the provision of a web-form for on-line feedback from seminar participants, we had only limited feedback from non-project people attending these seminars.

In view of the generally poor connectivity, we experimented successfully with using a combination of the TEN-155 MBS link from UCL to INRIA, the DBS infrastructure available from Eutelsat and the satellite reception dishes installed at the partner sites. Four recordings of seminars, given originally to the Basic Research Institute in the Mathematical Sciences (BRIMS), attached to HPLB, were multicast by UCL during the summer of 1999:



C_60 Buckminsterfullerene: Not Just a Pretty Molecule

Professor Sir Harry Kroto FRS

Royal Society Research Professor of Chemistry, University of Sussex

Topology and Quantum Physics: from Knots to Quarks

Sir Michael Atiyah OM FRS

Master of Trinity College, Cambridge

Tools for Brains: how Technology Created Human Consciousness

Professor Daniel Dennett

Department of Philosophy, Tufts University

Tangles, Bangles and Knots

Professor John Conway FRS

Professor of Mathematics, University of Princeton

Reception quality at the partner sites was excellent. The tools performed properly and user satisfaction was high.     Demonstrations

We have conducted a number of demonstrations, both to the commission, at our two annual project reviews, and to the general public:

June 1998              Demonstration of IP-multicast based videoconferencing during the official opening of new facilities at HP Labs, Bristol

December 1998     Information Society Technologies Conference & Exhibition, IST 98 Vienna

February 1999      The Launch of TEN 155 at the launch of the Fifth Framework programme, Essen. The demonstration was visited by the German Federal Minister for Education and Research, Edelgard Bulmahn

June 1999              TERENA-NORDUnet Networking Conference, Lund, Sweden

July 1999               Visit to UCL, London by the UK Secretary of State, Department of Trade and Industry. Parts of the event were multicast at 1 Mbps via a TEN-155 MBS link to INRIA and thence via the Eutelsat HOT BIRD satellite to those sites able to receive the transmissions.

October 1999        5th International Conference on Safety in the Port Environment, Environmental Protection and Information Technology, Bremen

2.4.3.         Evaluation and validation outside the project

During the course of the project, we have supported many user groups. We have delivered full descriptions of this work in the deliverable R9.2. These are a brief summary for the main projects supported:    Distributed Media Journaling (DMJ)

Media journaling is a blanket term to refer to a broad class of applications in which users are able to capture multimedia content and related information of real-world activities as they happen. Also, they can process the media so as to create a segmented, synchronised multimedia record of events. To be able to validate the theoretical results of this project, a prototype implementation has been established, including a media server and several work stations which are connected to the multicast Internet. During the past year, MECCANO provided the tools VIC, RAT and SDR for testing by the DMJ project and have supported its work.    Internet Collaboration Board (ICB)

We have continued to provide network and tool support to the ICB on request, and have received much positive feedback, particularly to our provision of IPv6 versions of the major tools as requested last year.    ICE-CAR

The objective of this project is to provide the technology components to support the secure use of the Internet for commercial and administrative applications in Europe. The project is improving security toolsets from the perspective of usability and interoperability and deploying them. We have liaised closely with the project on the improvements made to SDR in its ability to handle secure conferences. We have also helped them to deploy and test the new MECCANO secure conference store (SCS).    German philosophy workshop

This philosophy workshop consisted of a weekly series of discussions about Internet-related topics in philosophy. The workshop was planned between two German groups of philosophers (one in Stuttgart, the other in Leipzig) and officially announced to the public.

During the first two sessions, the philosophers, most of them not being trained computer users, had problems becoming familiar with the various MECCANO tools. However, from the third session onwards, they were able to concentrate on their discussion rather than the computer applications.    Piloting IP Videoconferencing (PIPVIC2)

The project started in December 1998 with the aim of undertaking piloting activities to gain a greater understanding of the issues encountered in running a large-scale IP videoconferencing service. The project, with thirteen partners, was co-ordinated by UCL. It was active in teaching, research and administration. The teaching activities provided a number of real courses, including languages, film studies, sociology, computer networking and business. Research activities were in the field of particle physics and collaboration in data archiving. Administrative tasks in which the project was active included external examiners meetings and project meetings of the several projects, including PIPVIC2 itself.

The support provided to the project by MECCANO can be summarised under four headings:

As a result of providing this help, we received important feedback from users of the tools both on their usability and the general utility of the technology for their purposes.

An initial study showrd the need for application sharing and reliable audio/video communication between three sites on the Internet. As a consequence, an H.323 tool (NetMeeting) was used along with the MECCANO tools VIC and RAT. There were some set-up problems, but after that the tools were stable and met the needs of the project participants. As part of this co-operation with REDISE, installation and operation manuals for the MECCANO tools were written in German and published on the WWW.

Since May 1999, the Institute of Informatics at the University of Oslo has been running a multicast support service on behalf of UNINETT. The main objective of this service was to stimulate use of real-time multimedia services (i.e. the MECCANO tools) on the multicast internet and to offer practical support to UNINETT users who either already use, or wish to start using, such tools. Support personnel visited institutions that were completely unfamiliar with the multicast world to help them start. A web site provides updated information on multicast, the services provided and other relevant issues. Recently, there have been an average of 73,000 hits per month on the web page,    Virtuelle Hochschule Oberrhein (VIROR)

The MECCANO toolkit is used for a large remote education project between the four upper Rhine universities: Freiburg, Mannheim, Karlsruhe, and Heidelberg. The project encompasses several departments ranging from computer science to business and language studies. It has provided feedback on the use of the MECCANO toolkit from a large group of real users. MECCANO tools are used for VIROR in two different ways: for the live transmission of regular lectures and for the recording, storage, and replay of past lectures. The most important aspect of VIROR in the context of MECCANO was that regular lectures and seminars were multicast as teleteaching events. This was a service for real users - lecturers and students. MECCANO partners were responsible for the set-up and maintenance of the tools and for network connectivity     WINSPECT

This German research project on the combined use of wireless networking, interactive multimedia conferencing and data mining/data base technologies for inspecting and maintaining industrial machinery was provided with the MECCANO tools and support for evaluating their use on wearable computers. This included consulting in the areas of system design, tool selection and network analysis as well as preparing (installation, test, etc.) mobile computing equipment and carrying out specific field trials. WIPTEL

The WIPTEL project, piloting an IP telephony infrastructure for the German research network (WiN), was supported with respect to gateway design and deployment. A prototype of a PRI IP telephony gateway was made available and experience from the design of AudioGate and StarGate (as well as pieces of the software itself) were provided as input to the project.  WIPTEL is an infrastructure project and, as with WINSPECT, the project is still in the stages of development.

2.4.4.         Peer reviews

Peer reviews, generally positive, have provided several helpful suggestions, especially in the case of some of the tool deliverables. We have taken up the positive suggestions made where this has been appropriate; for example, where additional material in a report would assist understanding. In some cases, where the deliverable was an early alpha or beta release of a tool, we have been aware ourselves of the need for improvements and have made plans to introduce them. We have had no major criticisms of our work from our peer reviews.

2.4.5.         Collaboration lessons learned

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 were unable to maintain the good collaboration which we had achieved during MERCI and the early part of MECCANO with the UiO spin-off, New Learning AS; the company, in common with many other such technology startups, experienced both managerial and financial difficulties during the second year of MECCANO and had to concentrate on solving these problems, which it was able to do. Since the contribution of the company was not planned to be large, the project was not seriously affected. We have had successful collaborations with our users, especially in the PIPVIC2 and VIROR projects, from whom we had good feedback both in reports and from attendance at each other’s meetings. These activities, presented briefly above, are described in some detail in the deliverables R9.1 and R9.2.

3.                Results and Achievements

3.1.             Concrete results

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, including IPv6 platforms.

3.1.1.         MECCANO user toolkit

MECCANO has delivered a toolkit of end-user tools for building tailored applications for real-time interactive multimedia collaboration systems for specific user groups.    Main functions supported

The toolkit comprises a set of tools which conform to industry standards. These tools allow users to communicate directly with each other over the regular Internet, in the manner of a phone call, or, via the multicast network, to participate in a multi-user conference involving many simultaneous participants. We offer both authentication and encryption to preserve confidentiality. Individually the tools offer the following functionality:

Audio During the project, we have delivered improved versions of the two audio tools: FreePhone from INRIA and RAT from UCL. The joint development and implementation of IETF standards for the use of error correction techniques for audio over RTP were followed by proof of interworking. From this point FreePhone development was done commercially by Detexis. RAT development continued throughout the project with a major redesign into a modular tool, the component modules using the Mbus protocol for communication. This design allows the individual components to be used separately and has provided the means for an implementation of audio-video synchronisation between RAT and the UCL version of the video tool vic. It has allowed also the use of the RAT engine in the AudioGate tool and the development of a prototype audio transcoder. We have produced an IPv6 version of RAT.

Video The project has used and developed two video tools: Rendez-Vous from INRIA and the UCL version of VIC. Rendez-Vous, which incorporates the audio tool FreePhone into its user interface, was enhanced during the first year to provide an improved version of the layered video codec, many bug fixes and a contextual help system. With the acquisition of the commercial rights by Detexis, development stopped within the project. VIC development consisted of the integration of a layered codec, support for new framegrabbers and the integration of IPv6 capability.

Shared text editing NTE, developed in the MICE and MERCI projects, provided a basic text editing facility at the start of the MECCANO project. Although text editing is also available in the more sophisticated whiteboards (eg dlb), there has been a continued need for a text editing component able to be integrated with other tools as needed. The tool, also a part of the ReLaTe integrated interface (see below), has been developed further to handle multiple fonts for our language teaching users and to work under IPv6. It is a good illustration of the benefits of developing components which can be integrated with others in novel interfaces for specific users, rather than integrating a full range of features in a monolithic tool which must be used whether or not all the features are needed.

Shared Whiteboard The shared whiteboards AOFwb/AOFrec and dlb, with their enhanced facilities for handling a range of graphics formats and recording features, provide tools with the functionality required for distance learning applications, albeit limited to Unix platforms. In the view of the organisation funding the development of these tools, there was no perceived need for Windows platform operation, secure communication or use over IPv6 networks. The developers are collaborating to integrate the AOFwb/AOFrec and dlb tools into a new common successor, the multimedia lecture board (mlb), in a national project, ANETTE, which started in October 1999. This new tool will be available on the Windows platforms.

Session announcement Session announcement through the SDR tool was improved considerably in the first year of MECCANO with the addition of authentication and encryption, using both PGP and PKCS#7. We have subsequently adapted it to IPv6 operation using code developed at ISI. The IPv6 version of SDR does not include encryption. Latterly we have concentrated on making a secure conferencing announcement service available via a secure web server and we delivered this as the UCL Secure Conference Server (SCS). The web-based model makes it easier to develop secure services and to migrate to IPv6. SCS uses the experimental GLOP addressing, described in RFC 2770, to avoid address clashes.

ReLaTe integrated interface This tool, originally developed for the ReLaTe[5] project, provides a single-window user interface incorporating functionality from RAT, VIC, NTE and Wbd. During MECCANO we have modified this so that it can be launched from the Secure Conference Server (SCS) and we have relaunched the Unix versions for Solaris and Irix.    Technologies and components

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 although many can be integrated into novel ad-hoc interfaces such as that developed for the ReLaTe project    Software and hardware requirements

Software The software is available free of charge via the MECCANO web site[6]. It runs on most Windows platforms 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 MECCANO tools is:

·         Pentium PC (133Mhz or above) running Windows 95 with 32Mb ram, 10Mb of free hard drive space

·         16bit full duplex sound card

·         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. The higher the specification the better. For example the lower performance PCs would not be able to manage as high a frame rate for video, or be able to support as many simultaneous video windows.    Integration and portability

We have further developed the ReLaTe integrated interface which combines RAT, VIC, NTE and Wbd into a single window. The new SCS environment integrates the proven security available via standard web browsers with the secure conferencing toolset to give users a simpler way to announce sessions, with authentication and encryption, when necessary.

We have delivered the tools on the following platforms: Sun SPARC running Solaris and PCs running Linux, Windows95/98 and NT.

Portability has been enhanced by the development of the new SCS which uses Java to launch the tools via the SPAR applet.

3.1.2.         Audio Mbone-Telephony Gateway (AudioGate)

AudioGate provides users on an arbitrary telephone network (PSTN, ISDN and GSM) with access to the audio channel of Mbone conferences. Upon connection setup, functions such as dynamic conference selection and user authentication are provided. Pass codes and calling party numbers are employed for this purpose. As soon as a connection into an Mbone session is established, additional services such as user identification and muting are provided. The  MECCANO deliverable D6.2/7.2 contains more detail on the design and implementation of the gateway.    Main functions supported

AudioGate 0.3 provides the following features:    Technologies and components

The AudioGate architecture splits the functionality provided into several logical components as shown in the figure below.

Architecture of AudioGate 0.3

These components are implemented as separate processes; only the utilisation of the same ISDN board for control and data exchange requires the ISDN call-controller and the RAT engine for a single ISDN B channel to reside within the same process, although forming two independent Mbus entities. The components are:

the RAT media engine acts as a line-switching to packet-switching converter, supports numerous audio codecs and packetisation formats as well as audio redundancy coding;

the ISDN call-controller (AudioGate Module) provides a simple interface to allow setup and teardown of calls, detection of busy and call completion indications, an interface for detection and generation of DTMF signals and the generation of voice clips for the ISDN side;

the AudioGate controller glues these entities together by accepting input from the various other Mbus entities and forwarding them appropriately.

the SAP/SDP module receives session descriptions from the announcement channel(s), extracts the information relevant to identifying and joining Mbone conferences and provides this information to other Mbus entities in an Mbus-specific format.

the Conference selection module receives session descriptions from the SAP/SDP module and turns them into a choice list assigning a numeric identifier to each conference by which the user can select the conference to join (via DTMF). The conference selection module also implements a filtering mechanism (to be configured e.g. via a simple resource file) to limit access to a certain subset of conferences. 

the Additional control module is an Mbus entity intended to provide an extensible set of additional features, largely based upon DTMF selection by the telephone user. Such services may include muting/un-muting the telephony user and changing the volume, amongst others.

The conference selection and additional control modules are integrated with the AudioGate controller and the AudioGate module rather than implemented as separate Mbus entities.    Software and hardware requirements

AudioGate 0.3p5 requires a Linux PC, an ISDN BRI board, and an ISDN basic rate interface. It was developed on a RedHat6.2 System using Kernel 2.2.14 and the HiSax Version 3.3. It should work with any distribution which uses glibc >= 2.0.7.

The ISDN-card must be supported by the HiSax-driver, because it is the only driver which supports audio via ISDN.  AudioGate was developed using a TELES S0 16.3 ISDN board. For kernels older than 2.2.12, the ISDN subsystem must be updated. HiSax versions must be 3.3 or later. The kernel must support audio via ISDN and IP: multicast.    Integration and portability

Since this is a gateway application, the question of integration with other tools is less important. The design of the gateway to use the Mbus protocol to link its component modules allows for easy addition of other functional components. Hence the ease with which it can presently use RAT and will, in future, use the RAT transcoder currently under development.

3.1.3.         IP-PSTN gateway

The IP-PSTN gateway allows an Internet workstation to communicate with a PSTN phone and vice-versa.    Main functions supported

The gateway translates voice between the analogue and digital domains, a process which can be initiated from either end – IP or PSTN.  It receives analogue audio from the PSTN, which is presented by the hardware as µ-law PCM, packetises it and sends is as an RTP stream to the IP receiver. There is an option to convert the input signal to GSM prior to transmission to the receiver. IP packets received are sent to the hardware for conversion to analogue µ-law PCM and put out to the PSTN. If GSM audio is received from the IP side, it is converted.    Technologies and components

The gateway uses off-the-shelf components to provide a simple solution to point-to-point communication between IP workstations and the analogue telephone network. IP-PSTN uses Dialogic D/41ESC telephony card, which provides: 4 external ports (to phone lines), 4 analog/digital channels, each with specialised DSP, SC-BUS for connecting other cards/devices, possibility to connect 2 channels to one port, making it full-duplex, A-law and µ-law sound codecs, echo cancellation, silence suppression, low latency.    Software and hardware requirements

The software runs on Windows NT 4.0 because the SDK for the Dialogic D/41ESC telephony card works only with this system. This fact influenced the choice of other packages/libraries used: Dialogic DNA 3.1 and Gatenet 3.0, sipd (Columbia University), RTPlib (elemedia Lucent), GSM codec (TU Berlin).    Integration and portability

The software is a fine example of the integration of components to provide a simple solution for a common requirement. It cannot be made portable since the hardware component predicates the use of Windows NT.

3.1.4.         MURS/RTSPC gateway

We are delivering the gateway from UiO which consists of the MURS server with its associated client application, RTSPC. The system offers a straightforward reflector without transcoding facilities which is easily accessible via the web and is simple to operate.    Main functions supported

Multicast-Unicast Reflector is a system providing multicast-to-unicast packet reflector functionality combined with WWW interface and an easy-to-use client. The purpose of this architecture is to enable users without access to a multicast-enabled network to participate in multicast sessions in a user-friendly manner through web integration. Functions supported in version 2.1 are:    Technologies and components

The reflector consists of three components: the reflector application, the RTSP server and the session announcement system (SEXT).

Reflector application is the central component in this architecture. It plays the role of proxy for its unicast clients and joins multicast groups on their behalf. Reflector forwards data packets from multicast addresses to their associated unicast addresses and vice versa. Its operation is externally controlled using Reflector Session Protocol (RSP), a text-based protocol including the necessary features for adding/removing multicast channels and listeners etc.

RTSP server, which includes an RTSP client unit that controls the associated Reflector, is based on a reference implementation available from Apple Computer.

Session announcement system (SEXT) collects, and locally caches, multicast session information from SDP multicasts which it provides to interested clients (WWW and RTSP servers) upon request.    Software and hardware requirements

The reflector and SEXT are written in Java and require Java version 1.1. It has been run successfully on Solaris, Linux and Windows NT platforms. An RTSP server binary is available for Linux.    Integration and portability

The Java elements are portable, and other functions can be ported in the future. Integration with the Web simplifies the user interface and allows integration with other web-based applications. We have linked an H.323 IP telephony product from Cisco into this reflector to allow H.323 audio clients to join multicast conferences this way.

3.1.5.         SIP to AVSC Gateway Architecture (SAGA)

This SAGA gateway represents a very specific extension of an established CORBA AV stream control system to allow control via the Internet Session Initiation Protocol (SIP). It represents a typical MECCANO integration effort in extending the scope of existing tools by making them usable in new environments and for new purposes.    Main functions supported

The gateway translates SIP calls into AVSC stream control process activity so that the SIP user agent can initiate connections between SIP and AVSC users.    Technologies and components

This gateway was designed to achieve interoperability between two different procedures for initiating media streams: one based on the AVSC specification and the other the SIP protocol. SIP is an application-layer protocol used for establishing and tearing down multimedia sessions, both unicast and multicast. The AVSC represents a platform independent CORBA approach to the problem of multimedia streams management. CORBA mechanisms are used to perform control functions, multimedia stream transport protocols and QoS parameters being orthogonal to the control architecture. It is possible to use transport protocols such as RTP, UDP, AAL5 or any other protocol developed to transfer the multimedia streams. A diagram of the structure of the SAGA gateway is presented below.

This approach makes possible the implementation of multimedia client and server applications on two different platforms able to exchange multimedia data. This requires interoperability of the session establishment and control protocols on both client and server sides. The gateway provides a solution by translating SIP calls into AVSC stream control process activity. Currently only a SIP user agent can initiate connections between SIP and AVSC users, however, media streaming provides full bi-directional audio connections. The Locator interface currently uses static data rather than external locating facilities.


SAGA Gateway    Software and hardware requirements

This gateway runs only on the Linux platform and needs the AVSC multimedia device implementation core, which is currently implemented on Solaris and Linux only.    Integration and portability

The SIP interface to the AVSC video server system enhances its utility by increasing the sytem’s accessibility. Unfortunately, use of the Vovida SIP package predicates the Linux platform; other SIP implementations could be used to widen the availability in future.

3.1.6.         SVDA server system

The Scalable Video Distributed Architecture (SVDA) is an environment that handles enormously large storage capacity devices. SVDA enhances the functionality of video servers by adding third-party devices that can save video files on their large capacity, low access time storage devices. Clients, by and large, want the most recent video recordings available directly from the video server; other files can be stored on devices with a large storage capacity and a longer time to access, then migrated onto the video server as needed.    Main functions supported

The system supports Java-based client access to a CORBA server system which can provide simultaneous transmission of stored video as a video-on-demand system.    Technologies and components

The system consists of three elements:

·         CORBA servers: MainServer, VFS Proxies (which cover video servers) and AS Proxies (which cover storage devices) – they form the core of SVDA system,

·         SVDA client (available as standalone Java application or web browser applet),    Software and hardware requirements

The server system requires:

·         a Unix-based computer to run Sun MediaCenter MSM & CM servers for the cache functionality

·         any mass storage device with UniTree software (in our case an ACL 2640 tape library) for back-end storage.

The client for the SVDA system can be run on any Java machine. The system was developed on Solaris 2.5.1. It was built using Iona's CORBA implementation Orbix2.3 (patch 02.18) and requires also the Orbix Names service. Sun MediaCenter Release 2.0 or 2.1 at the cache side and UniTree+ V3.0 at the mass storage device side are also required.    Integration and portability

The system provides an interface to a Sun MediaCenter video server, which both demonstrates the project’s commitment to extending existing tools for new uses and highlights the difficulties of making such servers truly portable. ACC is continuing work on the system to allow it access to other VoD server hardware and software, initially the Oracle server.

3.1.7.         New Learning AV server

The New Learning server is fully commercialised as a Microsoft NT version of the hardware shared whiteboard sytem developed under MICE/MERCI and now the company’s main product.    Main functions supported

The server provides:

·         H.261 video over RTP.

·         PCM, IDVI, L16, L8, GSM audio over RTP with redundancy. PCM, IDVI, L16 and L8 with 8 and 16 Khz sample rate.

·         Hardware H.261 compression (using a card from Bitfield OY).

·         ISDN H.320 videoconferences, with an additional VideoServer ISDN card installed.

·         control through a simple tcp -based interface

·         very high video quality, up to 2 Mb/s video bandwidth    Technologies and components

The New Learning A/V-server handles the audio and video communication for New Learning’s electronic classroom product. The server can also be used stand-alone, or for integration in other usage scenarios.    Software and hardware requirements

The server runs on a Windows/NT 4.0 platform having a Bitfield videocompression card and a suitable sound card (e.g. most Turtle Beach cards)    Integration and portability

The AV-server is normally used integrated with other software components from New Learning AS. These include an easy to use touch-screen based control system and a shared electronic whiteboard for presentation of learning material.

3.2.             Networks created/used

We have given a detailed description of our networking activities in the deliverable for the Network Support workpackage, R5.1/5.2. Here we give the highlights.

3.2.1.         MECCANO use of  TEN-155 Managed Bandwidth Service (MBS)

MBS enables connectivity among research projects in countries connected to TEN-155, the European Research Network. The service allows projects to request bandwidth for specified periods of time, connecting specified nodes, with various service guarantees. Access, via ATM, is available to institutions connected to a National Research Network (NRN) or directly at a Point of Presence of TEN-155.

Deployment of the MBS was scheduled to occur in three phases: alpha test, beta test and full service. The aim of the test was to verify procedures for establishing an MBS account, to verify working of the ATM NOC service, to identify and resolve issues re NRN interworking, and to identify and resolve issues re NRN internal workings. The sole alpha tester was the MECCANO project, acting on behalf of ERCIM; this project was chosen because it was one of the very few multi-national ones which were both able technically to take advantage of the MBS and required its facilities for better performance.

After the expected initial problems, the service was tested successfully and put into service. One of the tests comprised a major demonstration made as part of the opening of TEN-155 at the official launch of the 5th Framework programme in Essen in February 1999. This involved links between the MECCANO partner sites at INRIA, RUS and UCL and an additional link from RUS to Essen. This demonstration was very successful, showing clearly the potential for this ad-hoc virtual network, made possible by the MBS.

Subsequent to this testing activity, the project made use of the MBS to provide high-bandwidth connectivity between INRIA, RUS and UCL for the delivery of high-quality seminars to the DBS uplink at INRIA for onward transmission to partners with satellite receivers.

3.2.2.         Direct Broadcast Satellite

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 at 2 Mbps using 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.

3.2.3.         Gateways

The gateways developed in MECCANO were mostly completed towards the end of the project. The exception to this is the AudioGate, which was delivered at the end of the first year and was used on a regular basis for participation in multicast project meetings from mobile phones. This functionality proved a useful means of including in such meeting those who were not only remote from other partners, but away from their home bases.

3.3.             Standards contributions

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.

3.3.1.         Internet Engineering Task Force (IETF)

We provided joint chairs for four workgroups, Audio Video Transport, MMUSIC, SIP and UDLR and  regularly attended the security sessions. Through the MECCANO activities, we ensured that relevant European practices were fully compatible with the IETF ones - in fact in some areas, such as conference control (MMUSIC), conference invitation (SIP), 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, UCL was particularly strongly involved both from the MECCANO and ICE-CAR perspectives. We collaborated to ensure that the facilities provided under MECCANO fitted into the IETF framework - but also that they were usable with the ICE-CAR 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 and from our project web site.

During the life of the project, we have been represented at all the IETF meetings, from the 42nd IETF in August 1998 to the 47th in March 2000, and we we have made major contributions to the standardisation process, which are recorded in our progress reports.

3.3.2.         ITU-T

We participated in the ITU-T H.323 meetings in November 1998 and in February 1999, contributing to the discussion on the continued development of H.323, with a particular focus on gateway architectures. In October 1999, we made a core contribution on robust/redundant/fault-tolerant H.323 components by leading the discussion in one of the ad-hoc groups and by drafting terms of reference for future work. We have participated also in the following meetings and conferences: ITU-T and SG16 Q.11-15 Joint Rapporteurs meetings in August 1999 and the SG 16 meeting in February 2000.

3.3.3.         IRTF Meetings

We have been represented at the meetings of the IRTF Reliable Multicast Research Group.

3.3.4.         ETSI

The project participated in the ETSI Tiphon Meeting in October 1998 with a contribution on the architecture for IP Telephony and general audio communications in the Internet. We participated also in the January 1999 meeting.

3.3.5.         Other

MPEG We represented the AVT group of the IETF at meetings of the MPEG workgroup in October and December 1998 and in April 1999.

Joint work TELES contributed as a member of the design team to the design of capability syntax in the MEGACO WG of the IETF and ITU-T SG16 Q.14.

VON Conference in September 1998

3.4.             Major results in execution

3.4.1.         Multimedia Conferencing Architecture

Early in the project, we developed an architecture for multimedia conferencing which we delivered as R3.1. This document provided an overview of the Architecture for multimedia conferencing on the Internet to be used in the MECCANO project. The protocols mentioned are all specified elsewhere as RFCs, internet-drafts, or ITU recommendations. Each of these specifications gives details of the protocol itself, how it works and what it does. The document provided an overview of how the components fit together and of some of the assumptions made, as well as some statement of direction for those components still in a nascent stage. Parts of this document were strongly based on a draft provided for the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Nevertheless, it covered a number of areas not tackled in that draft - or even relevant to the IETF. It was designed to be a guide to what we were trying to address in the MECCANO project. Specifically it updated and amplified the work previously done in MERCI on the architecture for secure conferencing.

The intention is to periodically review the document and maintain it as a valid, practical introduction to those new to the technology and as a reference for those working in the area.

3.5.             Technical & socio-economic assessment

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, UF and UM are already putting on full courses.

In the medical education field, UCL has long been involved in providing integrated courses across the three medical sites for which they are responsible and have also been part of a larger British project, funded nationally, to provide surgical education embracing 6 universities and using SuperJANET. ACC, with the high-bandwidth metropolitan-area network at their disposal in Krakow, have provided excellent, high-quality access to actual operations for educational purposes. When international multicast connectivity is consistently available, we expect to see greater use of our technology for medical applications; it was pioneered in the MICE and MERCI projects and has been successfully used where capacity and connectivity were adequate.

These arguments extend to other application areas.  It should be noted that the entry costs are not high.  Now that robust applications are available on high-end PCs, much larger numbers of users are using our technology. Clearly the higher performance workstations, PCs, servers and networks do improve the facilities that can be offered, but if the network connectivity problems can be solved, there are many applications which do not need more bandwidth than is currently there. The economic justification for further deployment is clear.



4.                Conclusions and future plans

4.1.             Review of the technology achievements in the context of future activities

The fundamental media technology has already moved into products and we are experiencing a number of enquiries. One important aspect is the emergence of cards supporting video capture and display integrated in with Standard APIs for Windows ’95, ’98 and 2000; these have made for greater use of our work of porting to those platforms. The speed of processors and cards is making much more media processing possible also in workstations; some manufacturers have asked us to port our tools onto their hardware using its native capability – rather than the more generic APIs now in use. There are better codecs – some of which are proprietary and require high licence fees. These developments imply that university work in the basic media tools is no longer needed or appropriate. There is still a need to have a better understanding of the benefits of hierarchical and layered coding for heterogeneous environments. There is also a need to signal media requirements for Quality of Service (QoS). This work requires, however more than just the basic tools; it requires also network support in relays and gateways – partly at the edge of the Wide Area Networks, and possibly even in routers themselves.

The one part of the media tools that we have found difficult to provide over a wide range of platforms is the synchronisation between audio and video. The problem is that while we can provide time stamps once the media streams reach the processor, the delay in that occurring depends both on the operating system implementation and on the processor speed. We can easily tune the parameters to deal with specific processors and cards; we find it much more difficult to do this over the broad range of platforms we are supporting. With the higher speeds of current processors, this is no longer as serious; it remains, however, a problem that needs resolution for strict synchronisation.

We see also many cards for the newer communications offerings such as ADSL. While connections for GSM impact the data and audio market, its speed of communications is too low for video. This will change with the coming of GPRS and UMTS. Another impact of GPRS and UMTS, is the need to move to IPv6 for many (or possibly even all) mobile services. Our activities in this direction under MECCANO have shown that it is not difficult to move the applications to operate under the new protocols. To take full advantage of the potentials of these protocols will require much more radical activity inside the media tools themselves to label the different parts of the data streams. There will have to be a closer collaboration between the labelling at the application level, and the policies to use the labelling information for routing, QoS and even security policies.

We realised at the beginning of MECCANO that the development of relays and gateways would play a key role in the deployment of multicast conferencing across the heterogeneous networks we were considering. A very significant proportion of our technical effort went both into the provision of a technical infrastructure for such gateways and into the gateways themselves. We have developed several – though not with all the facilities we would have liked. Moreover their deployment has been limited – partly due to the limited use of heterogeneous networks by the MECCANO partners. The introduction of such components does raise risks to availability and robustness. Their widespread deployment will also require attention to be paid to problems of providing robustness, maintainability and replication in the gateway architecture.

Secure conferencing is another area we have pursued inside MECCANO. Again the provision of encryption at the application level has proved relatively straightforward – with just one set of security algorithms, and with appropriately written applications. Nevertheless it has been difficult to apply it at that level in a way that is consistent across different platforms, and continues to work with both IPv4 and IPv6. Moreover it requires a particular discipline in writing the application. In NTE, for example, the use of IP addresses were much too prevalent inside the application; it required a much cleaner separation to provide an application which could be used across both IPv4 and IPv6. The mechanisms for key distribution in the multicast environment have proved even more difficult. The use of Session Announcement in secure conferencing, while attractive from the user viewpoint, has proved difficult to get through the IETF standards body. The use of a web-based service has proved easier to deploy, and is more in keeping with other moves in distributed applications. Moreover, by using the web-based service, the transition to IPv6 has been much simpler. It required merely the use of IPv6-enabled web services, and the appropriate tool-launching Applets.

The deployment of security in commercial and governmental environments has many policy and regulatory implications; these will not be met by single sets of algorithms, mechanisms and polices as in MECCANO. The use of IPSEC should ease the difficulties of deployment; its flexible reliance on security policies should make it more acceptable in sensitive environments. As discussed in the relevant deliverables (D3.1, D4.3 and D5.1/5.2), the use of IPSEC could not be considered in MECCANO.

One activity in MECCANO has been the use of Direct Broadcast Satellite (DBS) technology. We have shown that this is quite feasible technology, and have even made it work with IPv6 components. Because of the cost of using the up-link, the applications scenarios for which it is used must be evaluated carefully. However it is clearly very appropriate in distance learning situations both to the home market and to areas where the conventional communications infrastructure is poor. One of the MECCANO partners is planning a spin-off in this area, which is discussed in the Technology Implementation Plan (TIP).

The Server facilities that we are providing are important. During the period of MECCANO, there have been many advances in these servers outside the project – but those inside are also important. A recent development in MECCANO has been that of distributed recording and playback; this is particularly important when the communications is poor or variable in quality. The present facilities that we are providing requires that the recorders and play-out facilities be located specifically; more automated procedures for their location depending on traffic characteristics would be desirable.

There remains a serious question to what extent multicast technology is needed for conferencing. For only a few conferees, it is convenient but not essential. For large numbers viewing the same presentation, it is very important. Over the lifetime of MECCANO, multicast router technology has improved, and the operators have ensured that performance on the national portions of the Research networks has become quite acceptable. This is why the national experiences in Canada, Germany, Norway and the UK have been very satisfactory.  However, the same effort has not been made internationally; different nations are still running different routing policies, have not necessarily committed enough international bandwidth and are not really monitoring international performance so closely. As a result the international performance, as experienced by the MECCANO partners, has remained unsatisfactory. We have had to resort to Unicast tunnels, which are increasingly undesirable in the light of the national routing policies. As the different networks move to a uniform routing policy nationally, and as they give due weight to international multicast performance, these communications should improve.

At different times the users have requested better configuration facilities and more integrated workstation packages. We have made considerable progress in this area under MECCANO. The provision of binary releases, which are self-installing, has eased the mounting of the applications – particularly in the Windows environment. Nevertheless, we are eagerly awaiting the auto-configuration facilities promised with IPv6 to ease the problem further. The RELATE interface does combine the tools under Windows. The problem of more open, integrated releases, which combine the separate tools and work over the multiple platforms supported under MECCANO, has proved much more difficult. The MARRATECH activity starting has shown that the integration can be done over a single platform; however their toolset is restricted to their tools; it is not possible to integrate in other tools. That decision may be based partly on commercial grounds, but the MASH experience from the UCB seems to show otherwise. They again have an integrated toolset, which operates over both Unix and Windows. Again, however, it is closed; it is infeasible to add in other tools which do not adhere rigidly to the interface specifications of their system.  Since these system do not necessarily support all the features we require, the users must decide which approach more closely meets their needs.

In summary, the experiences with national applications projects like PIPVIC and VIROR show that the technology can be very successful, Various manufacturers have expressed interest in producing commercial products based on the MECCANO toolkit. Details of specific plans are contained in the Technology Implementation Plan which we submit with this Final Report.

4.2.             The Further Plans of the MECCANO Partners

The MECCANO partners have not put in a direct follow-on proposal themselves. This was not because there was nothing further to do; it just seemed that the constitution of that consortium was not ideal for a follow-on. If it was going to be the sort of project of MECCANO, the main theme should have been either a commercialisation of the tools or a strong commitment to an applications project. Indeed one such proposal was made by a Consortium which included two of the MECCANO partners (but not with one as Co-ordinating Partner). The application was unsuccessful mainly because the commitment to commercialisation was not stated in a credible fashion. Nevertheless, particular MECCANO partners are continuing further some of the activities they have been carrying out under MECCANO. Another such project, ANETTE, is being pursued further as a development project by the universities of Freiburg and Mannheim under DFN funding. Yet a third is being pursued as a national project by UiO.

It is clear from Section 3.2 that some of the more interesting aspects of QoS, security and deployability require assistance inside the network. For this reason, UCL will be deeply involved, with other partners, in providing such network support in the ANDROID project. Initially the work will be done in the context of IPv4, but eventually this will be IPv6. The consortium is very commercially oriented, with strong involvement from the supplier and telecommunications industry.

Five of the MECCANO partners (Cracow U, CRC, TZI, RUS and UCL) will be moving to another network technology in the 6WINIT project. Here the main theme will be the use of IPv6 in the GPRS/UMTS context. The work with the multimedia applications, gateways and security again figure prominently – but the whole consortium is more commercially oriented, with strong involvement from the supplier and telecommunications industry. Here the deployment of the technology in the clinical and health-care domain are a major direction being pursued.

The pursuit of the satellite technology remains important. A spin-off from INRIA is being started to commercialise this technology. INRIA is continuing to pursue the technology in a number of important international distance education environments. In addition UCL is discussing a significant effort to introduce this technology into Central Asia, where the communications infrastructure remains poor.

Project Consortium

ACC Cyfronet

Communicatons Research Centre

Hewlett Packard Limited

Institut National de Recherche en Informatique et Automatique

Rechenzentrum Universitaet Stuttgart


University College London

University of Oslo



Shell International Exploration and Production BV



Contact address for the Project:

Name               Peter T Kirstein

Company         Department of Computer Science, University College London

Street              Gower Street

City                 London WC1E 6BT

Country           U K


Telephone       +44 (0)20 7679 7286

Fax                  +44 (0)20 7387 1397




The Project MECCANO (Multimedia Education and Conferencing Collaboration over ATM Networks and Others) has been supported by the European Commission under the auspices of the TELEMATICS APPLICATIONS Programme.


Further information on the TELEMATICS APPLICATIONS Programme:

You can obtain more information on the projects of the TELEMATICS APPLICATIONS Programme from:

European Commission, DG XIII, C/1

TELEMATIC APPLICATIONS Programme Information desk

Rue de la Loi 200 - BU 29 - 04/05

B - 1049 Brussels

Fax: +32 2 295 23 54


Or on the TELEMATICS APPLICATIONS Programme’s homepage:

Copyright information.

[1] Multimedia Integrated Conferencing for Europe (

[2] Multimedia European Research Conferencing Integration (

[3] Virtuelle Hochschule Oberrhein (http://

[4] Piloting IP Videoconferencing (

[5] Remote Language Teaching (