Nespole!	Funzione emittente

IS	Data

08.03.00	N° progress.

Report on the technological platform for Nespole! after the kick-off meeting in Trento (21-22/02/00)

This report provides a brief summary of the discussion on the platform setup suitable for supporting the two showcases (demos) addressed by the project. 
Several issues, essentially related to re-synchronization of the video/audio/data streams after possible manipulations, were still open at the meeting. The present document also gives answers to most of this issues, and a preliminary estimate of work items for development of the platform.

Low-end system setup

The proposal from UKA/CMU is based on the assumption that the negotiation service shall be made available to users with low profile terminals, namely terminals that are only capable of navigating web pages with Java applets.  The rationale for this proposal is that the “domestic user” wants to access the service using the web browsing functionality available to any Internet service user with a PC.  In the near future, the service could be available to users with even simpler terminals capable of web browsing, like, e.g., Internet TV set top boxes and Internet mobile telephones (please note that Internet TV set top boxes yet do not support neither VoIP nor Java Applets.).

High-end system setup

The proposal from Aethra, on the other end, comes from the experience of a commercially available service called “video call center” already available to Aethra customers with a terminal and connection capable of supporting audio-visual communication.  The “video call center” service is accessible to users equipped with a video conferencing terminal, which can be as simple as a commercial PC with microphone, camera, and speakers, running an H.323  or H.320 compliant application (e.g. the commercial H.323 implementations from Microsoft or Lotus).

The main issues left open at the conclusion of the meeting were:
•	the feasibility of carrying “proprietary data” (e.g., analysis/synthesis coefficients, IF, specialized whiteboard, etc.) on a T120 stream;
•	the feasibility of resynchronization (via either flat delays or time-stamps) of audio/video/data after manipulation of one or more of the H323 streams.

After further investigation we can now summarize our conclusions as follows: 
•	essentially any kind of data can be carried on a T120 stream, but this typically requires using proprietary software (e.g., a proprietary whiteboard);
•	data are transmitted with a sensible delay w.r.t. audio packets. Such delay could be comparable to the delay induced on the audio stream by the translation process;
•	possible time-stamps used to bookmark events on the data stream which call for resynchronization with the audio stream (e.g., pointing to a particular position and saying “This”) should be inserted at the source itself of the relevant data stream (whether or not the source is the user terminal);
•	data sharing via a whiteboard and resynchronization of audio/data streams require the use of a proprietary whiteboard;
•	implementing an ad hoc proprietary whiteboard takes 6-7 man months.

“Unified” system setup

After clarifying the motivations for the two different proposals, and considering that both have pros and cons, the discussion during the meeting concluded with a proposal to consider the feasibility of defining a single platform supporting both system setups.  The other conclusion was the need to identify the amount of work required for achieving different levels of integration between the two setups:
1.	Minimum integration: platform capable of HTTP and H323 connections, running as two independent applications;
2.	Interface integration: platform capable of HTTP connection and H323 connection launched and displayed as part of the Web browser window;
3.	Synchronization integration: platform capable of HTTP and H323 connection, with the Server performing demultiplexing/analysis/remultiplexing on the HTTP and H323 stream, to provide hooks for synchronizing the different types of data delivered in the two separate pipes.

It was also noted that the need for the (far more complex) work of synchronization between the HTTP and H323 streams is still to be proved.
The decision on what level of integration is actually needed for the goals of the project (or whether one of the two platforms should be dropped altogether) is obviously for the consortium to take, considering functionality supported, complexity of integration and related resources, overall consistency of the architecture.
We can however add a few technical remarks about the above possibilities of integration between the HTTP and the H323 streams.
•	Interface integration. Getting a video window as a Web browser window is feasible and takes 1-2 man months.
•	Synchronization  integration. This requires software modules for parsing HTTP  packets and extracting relevant data. In order to say more about the feasibility of this approach we need specific information about the downloaded Java applet, and the data packets sent under HTTP during a C*-like session. We already inquired the CMU partners about this, and will be more specific as soon as we get the necessary details.