Minutes for CLUE at interim-2014-clue-1
minutes-interim-2014-clue-1-2

Meeting Minutes ControLling mUltiple streams for tElepresence (clue) WG
Title Minutes for CLUE at interim-2014-clue-1
State Active
Other versions plain text
Last updated 2014-02-03

Meeting Minutes
minutes-interim-2014-clue-1

IETF CLUE WG Virtual Interim meeting
January 27, 2014
13:00-15:00 UTC

Chaired by Mary Barnes and Paul Kyzivat

Attendees:
------------------
Keith Drage
Mark Duckworth
Roni Even
Rob Hansen
Christer Holmberg
Jonathan Lennox
John Leslie
Andy Pepperell
Roberta Presta
Simon Romano

Minutes by Rob Hansen and random notes/summary by Mary Barnes

---------
Summary:
---------
The objective of the meeting was to review the current WG status, review the
updates and open issues around the framework, and focus on the solution,
including the signaling, CLUE protocol, data model and data channel.  The
discussions and actions are summarized below, followed by the detailed minutes.

Current Status:
===============

- Use Cases: Completed IESG review.  Update to reflect comments required before
Gonzalo updates the status to put doc in RFC editor Queue.

- Requirements: Completed IETF Last Call. On the IESG Telechat Agenda for
February 6th.

Framework:
===========

Actions:
--------
- Take the resolution for the issue around Spatial information within a
composed MCC to the mailing list for consensus call.

New Tickets:
------------
1)  Associating received streams with captures. Open an issue for tracking the
resolution in the FW, signaling and RTP mapping documents.

2)  Overloading media channels. Need to open a ticket to track this in
signaling document.

3)  Do we support RTP multiplexing?

Data Channel:
=============
- Needs further discussion.

CLUE Protocol:
=============
- Simon will post a note summarizing issues with SDP when implementing the
prototype (and why their current implementation puts the encoding limits in
CLUE.

Way Forward
===========
We ran out of time to cover the revised data model.  We will cover that at an
upcoming design team meeting.  We also will circle back to framework issues at
a design team meeting.

Minutes by Rob Hansen
===================

  There was a review of the status of various documents and their various
  levels of progress. Mary Barnes clarified (in response to a question from
  Mark Duckworth) that the framework document will not be progressed as a
  document at the moment, as it may need changing in response to changes in
  other documents.

Mark presented slides on representing spatial information within a composed
multi-content capture. Mark pointed out that we had previously had a ticket
(#5) on this and had agreed to not to cover this, both due to whether this was
a suitable issue for CLUE, and because this was not an issue specific to CLUE.
There was consensus on the call to again not address this mechanism in CLUE,
and this will be taken to the list for final consensus.

The next issue addressed was on how the MCC references other captures. The
proposal was that the framework will introduce the concept, but that the
mechanism for achieving this reference will be defined in the data model
document. Discussion has taken place on this list about what these mechanisms
will be - this dicussion will continue, but it will be relative to changes to
the data model. The group agreed with this proposal.

The next issue is on the long-standing issue of how a topo-mixer advertises
switched captures that can sensibly lead to the consumer correctly receiving
switched streams that render multi-camera setups. There was a longish
discussion on whether a provider should advertise the switched captures as
multiple entries in a single scene, or as a multiple scenes. Various issues
were raised, but further discussion will be needed.

Mark then asked what should go in the framework related to a switched capture:
1) How to matched multiplexed media to a specific encoding (and hence capture)
2) In the switched case, how to identify the original source being switched
through Mary said she would open a ticket to track the issue.

There was then a question about the language the framework currently have about
media channels; feeling was that generally this should be removed. Mark agreed
to send another, more specific message to the list about the proposed removal.
Similarly the framework has language about RTP multiplexing - there was some
discussion about whether such multiplexing should actually be mandatory as part
of CLUE. This will also be removed and a note posted to the list. Rob Hansen
took ana ction to ensure that there is sufficient information on this in the
framework document.

Finally Mark presented a summary of open tickets.

Christer Holmberg presented slides on the RTCWeb data channel. He summarised
the structure of the current RTCWeb design. His proposal was that the CLUE
protocol is implemented on top of the RTCWeb data channel - Mary and Jonathon
Lennox asked whether this was necessary, and whether we could use SCTP/DTLS/UDP
directly (with a CLUE data channel on top, or with all negotiation in SDP).
Christer's analysis was that the RTCWeb data channel is sufficiently simple to
be worth using if we do not find any technical obstacles to doing so.

Christer then proposed a message format CLUE could use with the RTCWeb data
channel. Only two messages are needed to configure the SCTP streams (OPEN and
ACK). Roni Evans asked whether there was actually a need to use the RTCWeb data
channel protocol, or whether the data channel itself was sufficient. Christer
took an action to investigate why this middle layer was mandatory (and if so,
why).

Christer then provided an example of how the SDP would look, with the new
sctpmap attribute (as per draft-ietf-mmusic-sctp-sdp), followed by a flow of
establishing the data channel (opens and acks in both directions), followed by
CLUE messages. To be interoperable with RTCWeb, the messages will need to be
formatted in the Javascript string format; Christer will look into the
specifics of these encoding rules, along with other details.

Simon Romano presented some slides on the initial work they had done
implementing CLUE over WebRTC, showing a call flow for how a call is set up,
and then a live demo of CLUE being used, with logs of advertisements and
configures being sent and received. He showed it working, and identified some
additions that will be needed. Simon raised the issue that adding new values to
CLUE is much simpler than SDP, such as the encoding limitations, though Roni
reiterated the point that we should avoid redefining things that are already
available in SDP and other locations. For this reason the demo currently puts
encoding limits in CLUE; it would have taken considerably more work to do so in
SDP. Simon agreed to post a summary of the implementation issues of doing SDP

At this point we were out of time, so Roberta Presta's presentation on the data
model was delayed to the next design team meeting (4th Feb). Mary took an
action to send a reminder to the list of the draft deadlines for London (Keith
Drage noted that it is 14th Feb for both -00 and -01 draft).

Notes by Mary
=============

Framework:
- Slide 2. Spatial information within a composed multi-content capture. 
SUggestion is that the consumer should not make any assumptions about the video
layout with an MCC (nor is this information provided in an advertisement. 
Chairs: Need to post a note to the mailing list noting consensus.

- Slide 3. MCC referencing other captures. Discussion of using a label.  Need
to agree what goes in framework and then the details should go in the data
model.

- General question on FW.  We will finish as much as possible and then we will
revisit the framework for consistency with solution once that's mature.

- Slide 13. Associating received streams with captures. Issue for signaling and
RTP mapping.  Need to figure out what toss summarize in FW.   Action: chairs
open a ticket to track this.

- Slide 16.  Overloading media channels. Suggest to move out the detail. Mark
will post a note to the list.  Need to open a ticket to make sure this is added
to the signaling document.

- Slide 17.  RTP multiplexing. Suggest to move this out of the FW.  Mark will
post a note to the list.  Action: chairs open ticket as to whether we support
RTP multiplexing.