IETF CLUE WG Interim meeting, June 25, 2013 Participants: ------------ Mary Barnes Paul Kyzivat Christer Holmberg Cullen Jennings Dan Romascanu Emil Ivov Gonzalo Camarillo John Leslie Jonathan Lennox Keith Drage Mark Duckworth Rob Hansen Roberta Presta Roni Even Simon Romano Stephan Wenger Recording: ------------ https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=13563457&rKey=d27e3dec5e09149a Notes by: Mary and Paul ----------------------- 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 signaling solution Current Status: =============== - Roni and Jonathan are working on an MMUSIC document related to the RTP mapping. [Note - document has been submitted since the interim: http://datatracker.ietf.org/doc/draft-even-mmusic-application-token/ ] - Use Cases: document is deemed ready for WGLC. Action: chairs start a 1 week WGLC. - Data model: has been kept updated to reflect FW. Should be ready for consideration as a WG document. Action: Chairs. Start a one week review period. Framework: =========== - Switched Captures: The primary discussion was with regards to draft-duckworth-clue-switching-example-00 (noting that this is just one example). Paul pointed out that this highlights important issues: how receiver decides how many of the advertised scenes it needs, how an MCU assigns coordinates in its virtual scenes. For the example with multiple scenes, priorities can be used by receiver to decide what to get if it can’t take all. But we have no way for the receiver to decide which captures represent the site of the current talker. Discussion of one-scene vs. multiple-scenes for describing spatial relationships. No conclusions. Some thought single scene, with coordinates showing the intended layout would work. Action: Mark to bring up the specific issues on the list. - Other open issues: -- Roles: Christian still has an outstanding action to post a document evaluating the various options that were discussed on the mailing list. Action: Christian submit the document no later than July 15th, 2013. Note: this is tracked by Ticket #32 -- Update examples section. Action: authors to do this in next version. New ticket #34. -- Ensure Framework and Data model terminology are consistent. New ticket #35 -- Cleanup encoding parameters for pixels/sec (computational complexity) - these should be independent of codec. Action: discuss on the mailing list - need WG feedback. New Ticket #36. -- #20: Rejecting configure. As noted in May 21st interim, this needs to be mentioned in Framework, but details belong in the solution document. -- #25: Advertisements (complete or not). Action: Christian needs to get out a proposal within two weeks [Note: one week from time of the publication of these notes.] -- Security section needs to be completed. Action: Mary work with Mark once the security details for requirements document are detailed. New ticket #33. Signaling/solution: ==================== - Paul noted the lack of progress and input for this document: -- While Paul has folded Rob's proposal (from the May 21st interim) into the kyzivat-clue-signaling document, it's not yet thoroughly integrated and Rob needs to sanity check it. Action: Rob to do this before July 15th document cutoff. -- Paul has added a schema for the CLUE messages - Folks agreed to provide a detailed review of what's there now: Christer, Rob, Mark and Mary. - Discussion of who will populate which sections: 1) Approach to versioning/options/extensions. Assignee: ? 2) Approach to message ack/nak/error reporting Assignee: ? 3) Approach to stand-alone messages or deltas: Assignee: ? 4) Elaboration of message sequencing. Note: This is important upfront. This may be ready for call for consensus. 5) Mgt of CLUE channel lifetime & error handling. Assignee: ? 6) Review/refinement/detailing of msg syntax. Assignee: ? 7) Decision on encodings: SDP or ADV. Assignee: Rob 8) Decision on relation of clue msgs & SDP. Assignee: Rob 9) Legacy mode. Assignee: Christer 10) Update of examples/call flows Assignee: ? Action: Mary to pull out topics for which there appears to be consensus and post to list for confirmation. - General Discussion: Simon is concerned that there is little energy on this. In particular he thinks this works best if people are trying to implement this, and feeding back based on implementation experience. He can’t do telepresence right now in his company, but he wants to know that some are doing this. He is concerned that we are developing something that nobody is interested in implementing. Cullen says Cisco is concerned with speed of progress, and how much incremental value does this provide relative to what they have today. He suggests sitting down in Berlin, at dinner or whatever, to discuss how to refocus in a relevant way. Way Forward: ============= - Actions above to be addressed. - If we don't have enough additional content or proposals for the signaling solution and updates to the framework, we will not need our WG slots in Berlin.