1          Introduction

This document contains the summary of the discussions made during the Ad-hoc Group on Chillout on 2007/01/29-30 in Beijing.

2          Next demos

2.1        MPEG MAF Awareness event (San José on April 28^th)

This is an event where all MPEG Multimedia Application Formats who have reached sufficient maturity will be presented to the industry in the Silicon Valley. Being the Media Streaming Player MAF – the one originated by the DMP proposal- one of them, a 25 minute slot for a "short" presentation and a "long" Chillout demo will be given.

Some MPEG delegates have volunteered to participate in the development of the demo, which could show a complete IPTV system including, among other features:

1. the streaming over RTP of Content (DCI and resources) using Digital Item Streaming
2. the adaptation of resources and Digital Items on the Server side based on the device characteristics of the requesting client
3. a number of SAVs in a Domain moving Content and using it according to license terms

Figure 1 below shows the interactions between a SAV and a CPD: 

Figure 1 – Interactions between a SAV and the CPD

Figure 2 below shows a high-level walkthrough of the operations that should be performed on the CPD any time a new dmp2rap:RequestContent message is received: 

 Figure 2 – Operations on the CPD

Figure 3 below shows the Digital Item Streaming and the Digital Item Adaptation components which should be integrated in the current CPD for the purpose of this demo. 

Figure 3 –CPD components performing Adaptation and Digital Item Streaming 

3          Domain management architecture

The figure below shows a high-level architecture of the modules necessary to implement Domain Management: 

 Figure 4 –Domain management modules

The figure shows that the following modules shall be developed:

a.       SAV:

·        GUI (new panel in the SAV) allowing to create a Domain and join/renew/leave a Domain

·        Domain logic: module performing all the domain-related operations on a SAV and creating the WSDL messages to send when performing Domain-related protocols

·        Database: to store domain-related information

·        DMD talker: module sending and receiving WSDL messages with DMD

b.      the DMD

·        SAV talker: module sending and receiving WSDL messages with DMD

·        LPD talker: module sending and receiving WSDL messages with LPD

·        Database: to store domain-related information

·        GUI(Web): a web page (e.g. jsp) to configure the DMD – this page could also be accessed using the SAV browser window.

·        DID: For a first phase, Domain Identifiers could be created at runtime e.g. randomly

·        DMD logic (not shown in the figure): module performing all the domain-related operations on a DMD and creating the WSDL messages to send when performing Domain-related protocols

c.       LPD components:

·        DMD talker: module sending and receiving WSDL messages with DMD

·        Domain logic: module performing all the domain-related operations on a LPD and creating the WSDL messages to send when performing Domain-related protocols

·        GUI(Web): a web page (e.g. jsp) to configure the LPD (maybe this is not necessary in a first phase)

4          CCD architecture

Good steps were made in defining the Content Creation Device specification. The figure below shows a preliminary block diagram of such architecture.

Figure 5. – CCD block diagram

 The following tasks were completed:

1. Specify the Protocols between CCD and external Devices that have not yet been specified in DMP AD3, such as:
   1. CCD – TPD

                                                               i.      Protocol to get the TPD's Tool list

2. CCD – LPD

                                                               i.      Protocol to declare Licence preferences to be applied by the LPD (to be developed)

3. CCD – CPD

                                                               i.      Protocol to send DCI to CPD

2. Specify the CCD internal architecture

The work made in defining the above protocol brought the conclusion that for the new protocols, and for many of those already specified in IDP-2, the payload shall include a field containing information identifying the user who is actually carrying over the Protocol using a Device. For instance, how can an LPD distinguish a User who has bought a license for a Content Item from one who hasn't? (such as username and password) information in order to allow the LPD to "recognise" the user who must have e.g. created an account on the LPD before he can actually  

5          Digital Item Streaming

1. on the CCD:
   1. We need an authoring Tool allowing to generate streaming instructions for every Content Item and associated Resources

                                                               i.      The Authoring Tool shall allow a User to specify at which time a certain metadata node of the DCI shall be sent and displayed to the User

                                                             ii.      The Authoring Tool shall be capable of reading the "StartDTS" and "EndDTS" values in a dmp2rk:TimeKey and generate appropriate streaming instructions for sending each key at the right time

2. We need to integrate the BBL processor into the CPD
1. on the SAV
   1. We need to integrate the BBL client on the SAV. Every time a new node of the DCI is received from the stream, the DCI parser should parse it and:

                                                               i.      If it is metadata --> Show it to the User

                                                             ii.      If it is a key --> Send it to the appropriate DRM Tool

6          SAV Manager – DRM Processor interface

1. Specification
   1. At the last meeting we did a great job on this, but no further progresses were made between the meetings. The specification of the interface is still pending and needs to be addressed ASAP
2. software architecture
   1. At the last meeting we came up with a pretty good architecture of the SAV including the SAV Manager – DRM Processor part. We need to finalise this architecture

7          Maven issues

Issues:

1. Software build: Which problems are preventing us from generating a SAV as an executable jar and making it available to everyone?
2. maven build for server Devices
   1. Not needed at the moment
3. Chillout web site built with Maven
   1. Interesting: Lan will investigate this possibility

8          Mutual Authentication issues

1. We will not develop a Mutual Authentication library
2. We will use Mutual Authentication libraries which are publicly available (e.g. http://java.sun.com/products/jsse/index-14.html)
   1. We will provide in Chillout:

                                                               i.      An example of messages signed using DSIG

                                                             ii.      An example of messages sent over SSL/TLS

9          Plan for the next developments

NB: When an activity has been completed, please send an email to the chillout@dmpf.org reflector to notify that the task has been completed, the code is available (location, etc.) and provide documentation on the Wiki.

Review the following table.

• Items in green: completed.
• Items in yellow: progressing
• Items in red: no known activity