AGOCG logo
Graphics Multimedia VR Visualization Contents
Training Reports Workshops Briefings Index
This report is also available as an Acrobat file.
Back Next Contents


10.1. Design Issues

There are conflicting realities to consider when designing a common multimedia architecture:-

The fact that the Internet was based on a single, common, virtual network service (IP) allowed a ubiquitous underlying communication infrastructure to develop upon which a set of services could be provided to the user. This also allowed for a large market to develop for applications which were built upon the underlying communications.

When there is a single common layer the selection of applications becomes the province of the end-user rather than the intermediate network provider such as a telecommunications, cable operator or computer services department. By having this common underlying infrastructure, users are able to select their desired/required application services based on their unique needs, with assurance that the intermediate networking service will support their communication requirements.

Designers of a common multimedia architecture face three problems :-
At what level in the protocol stack should common interfaces be provided?
Should the network level be the common point, able to handle many different requirements, or should a common transport layer be able to request the service of many networks?

Secondly any common architecture will have to recognise the existence and be able to operate with other architecture sets. For instance it is conceivable that the MMCF reference model may have to inter-operate with a Microsoft or IBM model, according to how the industry politics play out.

Thirdly each architecture will have to share resources at some point in the chain of memory, processing, network requests, and transport of packets on the network.

Achieving inter - operability and resource sharing is difficult. For example, sharing bandwidth on a link may not work effectively if one protocol suite backs off in its demands and the other does not. Inter - operability and resource sharing both require co-operation between the various developers and users. The process of co-operation is a dynamic one, when it works. Attempts to achieve inter - operability and resource sharing may bring the multiple architectures into some level of harmonisation, even if it is just to simplify the problems of inter - operability and sharing. Together with the normal process of evolution, there may then be lead to changes in one of the architectures, as well as the other suites. Thus, the need for new technologies leads to a natural process of diversion. The process of harmonisation leads to conversion.

The Internet community have decided that there should be single next generation Internet (IPng) protocol and are developing methods to ease the transition from IPv4 to IPng. The intention is to promote different approaches at the applications layer and let the users market decide which one is best for their needs. The Internet community have therefore staked a claim to the network layer, and it will be up to multimedia users and developers to decide if a similar common layer or architecture below multimedia applications is of benefit to users and achievable.

10.2. Multimedia Communication Models

In fact the Multimedia Communications Forum (MMCF) are developing a reference model [Zakowski94] for multimedia architecture to allow easy application development for independent software producers. The first result of this work will be Transport Services Interface which will be a type of multimedia WinSocket specification, able to negotiate bandwidth, delay, priority and other quality of service parameters required by multimedia. AT&T, Intel, Motorola, National Semiconductor, and Seimens are some of the companies involved. The MMCF work is intended to complement the work of the Interactive Multimedia Association which has initiated a compatibility project to develop solutions to multimedia cross platform compatibility issues.

The objectives of the MMCF Architecture Reference Model are to provide:-

The MMCF have developed a concept of Middleware as part of the Multimedia Architecture Reference Model. Middleware is a suite of applications, functions and programming interfaces that reside above the transport level in the OSI stack, but below the application level. The interface from the Middleware domain to the application and transport levels will be via application programming interfaces (APIs). It is not clear if the OSI presentation and session layers will be part of this architecture.

The intention is that through the use of these application programming interfaces and middleware 'software' that flexible, inter-operable multimedia communication applications can be built. Control of Quality of service requests and negotiation will be part of these interfaces. The MMCF has already proposed the multimedia transport level interface (TS1), and further work will continue during 1995.

Intel is also part of a Personal Conferencing Work Group along with AT&T, DEC, Hewlett Packard, Compaq, Compression Labs, NEC, Novell and Lotus, which are about to release a Personal Conferencing Specification. Part of this specification may include specifications for converting H.320 video conferencing data into a format which can be transported on a LAN.

Both the French and German ISDN communities have submitted outline proposals is being put to the European Telecommunications Standards Institute (ETSI) for a multimedia programming interface appropriate for ISDN and other wide area networks. Initial inspection indicates that neither proposal yet tackles the problems of multi - network multimedia communications.

Applications which are unable to work with similar applications from a different manufacturer will not reach the widest market. Even Microsoft appreciates this fact. Of course manufacturers will try to drive standardisation efforts to their own advantage, but users do have a voice. The standardisation of video conferencing around the H.320 series of documents, desktop conferencing with the T.120 series, and electronic mail with X.400 and SMPT MIME extensions are examples.

10.3. First Implementations

Implementation of TS1 is expected by the end of 1995. The API primitives include:- IBM has designed a Lakes Architecture for Collaborative Networking [Aldred94]. This is meant to be an open platform for personal video conferencing. However the package includes the IBM Person to Person application. Lakes was not designed around audio or video applications but claims to be capable of handling both. Lakes features are outlined below:-

Multimedia Communications Logical channels between applications, quality of service, synchronisation and data conversion, and call management.

Device Independence For audio, video, clipboard, display and capture

Resource Manager Management of communications and collaborating applications

Programming Interface For interface to file systems and network directory services

Lakes also claims to inter - operate with the H.320 and T.120 video conferencing / multi party conferencing standards. Lakes is probably the first of several attempts that will be made to create tools to handle multimedia communications.

Back Next Contents

Graphics     Multimedia      Virtual Environments      Visualisation      Contents