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.