IETF90 CLUE WG Date(s): Monday, July 21, 2014 (15:20-16:50, Salon A) Thursday, July 24 (13:00-15:00, Manitoba) Location: Toronto, Canada Chairs: Mary Barnes, Paul Kyzivat Notetakers: - Session 1: Paul Coverdale, Roni Even - Session 2: Stephan Wenger, Keith Drage, Christer Holmberg Jabber Scribe: Jonathan Lennox Meetecho recordings: - Session 1: http://ietf90.conf.meetecho.com/index.php/Recorded_Sessions#tue (scroll to find CLUE) - Session 2: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_CLUE_II&chapter=chapter_0 Discussion Summary/Conclusions/Action Items: ============================================ General: --------- Action (chairs): New Ticket for each of the current WG deliverables with regards to security considerations. Action (chairs): Post an email to the list around whether the CLUE WG documents should have a dependency (and align with) the AVTEXT taxonomy document. Status: CLOSED. There were no responses at all to the email: http://www.ietf.org/mail-archive/web/clue/current/msg03999.html Data Model (draft-ietf-clue-data-model-schema): ------------------------------------------------ Discussion: Audio Issue. Action: (Roberta/Simon) Ensure list is extensible. Action: (Roberta/Simon) Remove audio channel format from audio capture type. Action: (Roberta/Simon) Submit revision in anticipation of starting WGLC on Aug. 25th. CLUE Protocol (draft-ietf-clue-protocol): ----------------- Action: (Simon/Roberta) Fix version issue. Decision: Do we need a separate READV response message to carry clue Data? Consensus: Yes. CLUE Channel (draft-ietf-clue-datachannel): ------------------------------------------------ Decision: If the Keith Richard's draft is updated within a few weeks (i.e., No later than Sept. 1st, 2014), then the CLUE WG might consider whether to incorporate that document into the CLUE solution, pending the documents approval as an MMUSIC WG document by WGLC date for CLUE data channel document. Action: (Chairs) Post a note to the CLUE WG mailing list reflecting this decision. Decision: Do we need a version number in DCEP? Consensus: No. Decision: Is there a need to determine whether an m= line describing an SCTP/DTLS association can be used together with bundle-only? Consensus: No. We don't need to talk about BUNDLE at all in this document. Decision: Do we need to describe the generic SCTP/DTLS association offer/answer procedures? Consensus: No. This document can just reference draft-ietf-mmusic-sctp-sdp. Decision: Do we need to define a fixed SCTP port value for CLUE? Consensus: No. Action: (Christer) Update draft to reflect these decisions. Action: (Chairs) Open new issue with regards to defining max message size Action: (Chairs) Open new issue with regards to whether chunking is required for CLUE. Do we know how big the messages will be? Action: (Chairs) Add data channel document to WG deliverable timeline on wiki, noting that there are a number of dependencies that need to be through WGLC in other WGs before this document can go through WGLC. Signaling (draft-ietf-clue-signaling): ------------------------------------------- Action: (Chairs) Open issue with regards to how fallback to a normal session will be handled. Action: (Chairs) Close Issues: #28, #24 (BFCP). Action: (Chairs) Reassign Issue #25 to CLUE protocol Action: (Simon, Stephen, Cullen, Christer). Review document by the end of August, 2014. Call Flows (draft-even-clue-call-flows): ----------------------------------------- Action: (Roni) Add fallback example. Add example showing the usage of secure media. Framework (draft-ietf-clue-framework): -------------------------------------- Consensus: Change "Capture Scene Entry (CSE)" to "Capture Scene View (CSV)". Consensus: change "Global CSE List" to "Global View List" Action: (Mark) Change FW. (Editors of other WG docs - i.e., data model, protocol and signaling) Make this change as appropriate. Action: (Mark) Put forth a proposal for describing the coordinate system without using left/right/front/back terminology. Action: (Mark) Consider possible changes to example 12.1.1 due to current confusion. WG should consider whether there is an obvious error that has caused the confusion. Way Forward: ----------- - Continue with regular design team meetings in August progress the solution details. - Update schedule for pre-WGLC and WGLCs. _______________________________________________________________________________________ Monday Notes by Roni Even _______________________________________________________________________________________ 15:20 Agenda, Status (Chairs) Presented by Mary, no comments 15:30 CLUE Data Model (Simon Romano/Roberta Presta) draft-ietf-clue-data-model-schema-06 The microphone pattern is back and also in the framework The list should be extensible The audio channel format should be removed from the audio capture type 16:00 CLUE Protocol (Simon Romano/Roberta Presta) draft-ietf-clue-protocol-01 Open issues: Version expressed using major and major number. Do we need a READV response message since there will be an advertisement. Allows the provider to know that this is a response to his request. No objection to keep READV Mark proposes to have shared type between the advertisement and READV and not separate ones. 16:30 CLUE Data Channel (Christer Holmberg) draft-ietf-clue-datachannel-00 is ejzak-dispatch-webrtc-data-channel-sdpneg going to progress. Keith is still working on it but if not progressing we will not use it. No version number in DCEP open data channel On bundle only we do not need to talk about it in the draft Next steps: update based on closed open issues: WGLC will wait for the dependencies CLUE Agenda, IETF90 Thursday July 24, 2014 13:00-15:00 Location: Manitoba 13:00 Agenda Bash (Chairs) 13:10 Framework (Mark Duckworth) draft-ietf-clue-framework-16 * Encoding Group multiple media types - say it is allowed, and update framework and data model to make it clear * Captures not in any CSE - clarify captures do not have to be in any CSE * Area of Capture - Video only!!! * Terms and taxonomy - Do we need to reference the taxonomy in some form - not referencing at all. There was discussion if there was consensus _______________________________________________________________________________________ Monday Notes by Paul Coverdale _______________________________________________________________________________________ Mary Barnes opened the meeting with a review of the WG Status. The Requirements document has been published as RFC 7262. The Use Cases document has been published as RFC 7205. The Framework document has completed pre-WG Last Call. Mark Duckworth will discuss the remaining open issues in his presentation. For the Data Model document, the pre-WG Last Call has been completed. For other documents: CLUE Protocol: - Agreed as a WG document CLUE Signaling/Orchestration: - Agreed as a WG document CLUE Data Channel: - Agreed as a WG document CLUE Call Flows - Roni Even agreed to serve as editor RTP document: - Revised ID required - One open issue: #47 - simulcast There are a number of related documents being discussed/developed in: - MMUSIC: BUNDLE - draft-even-mmusic-application-token - AVTCore: Support of multiple stream docs - AVTEXT - draft-ietf-avtext-rtp-grouping-taxonomy Simon Romano gave a presentation "CLUE Data Model", based on draft-ietf-clue-data-model-schema-06. The data model draft is becoming quite mature. Among other things it includes Christian Groves comments from the mailing list; aligned with framework draft. New material for version-07 will include: - Encoding group reference not mandatory for all captures - Update the encoding group text to state that it is not mediaType-specific - Some editorial nits It was noted that the document is intended to be "Standards Track" rather than "Informational". Open issues include Definition of Clue Participant; Restoring (microphone sensitivity pattern) to improve the description of audio captures. On this point it was agreed that this should be an extensible list, to allow for different microphone sensitivity patterns in the future. There is still some work to be done to make the document consistent. Simon then went on to review the status of the CLUE data model, based on draft-ietf-clue-protocol-01. Open issues include: - Consensus needed about how to express protocol version.The current proposal is v="M.m". This was agreed. - Do we need a separate READV response message to carry the CLUE data? Simon proposes "Yes". This was agreed. - Couldn't the READV simply trigger the MP to send an ADV? Simon proposes "No". This was agreed. There may need to define an extra XML element. Simon then reported on a "homework" assignment of how call flows would look, based on the CLUE protocol. An example was given of the mesaages for Options offered and the corresponding response, then Advertisement and corresponding Configure + ACK. Christer Holmberg gave a presentation on the "CLUE Data Channel", based on draft-ietf-clue-datachannel-00. There are several open issues: Whether the SDP-based WebRTC Data Channel Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used with the CLUE Data Channel? It depends on whether the draft will progress in MMUSIC, and whether it will be finalized before the publication of the CLUE mechanism. Nothing has happened since IETF 89 in London. This was left for further study. There is a need to determine whether to include a version number in the DCEP DATA_CHANNEL_OPEN message 'protocol' field value for CLUE. Christer doesn't think that this is needed, and this was agreed. There is a need to determine whether an "m=" line describing an SCTPoDTLS association can be used together with bundle-only, in which case there will be cases where an offer with a zero port value will create a corresponding answer with a non-zero port value. Christer suggests that, in fact, there is no need to talk about BUNDLE at all. This was agreed. Since the SDP offer/answer procedures are generic to SCTPoDTLS association, do we need to specify them, or can we simply refer to draft-ietf-mmusic-sctp-sdp? Christer proposes to refer to draft-ietf-mmusic-sctp-sdp, and specify generic CLUE Offer/Answer procedures in draft-ietf-clue-signalling. This was agreed. Christer noted that there are some dependency impacts for CLUE based on draft-ietf-mmusic-sctp-sdp-07: - SDP sctpmap attribute has been removed - SDP sctp-port attribute introduced - With DTLS/SCTP, indicates actual SCTP port His suggestion is that there is no need to define fixed port value for CLUE. This was agreed. - SDP fmtp attribute used to indicate maximum message size - Message size indication optional His suggestion was that there is no need to define a maximum message size for CLUE. This was generally agreed, but during discussion it was noted that there is a need to line up with rtcweb, and some concern was expressed about what the maximum message size could be for CLUE. The next steps are to update the draft based on closed open issues and changes in dependencies, but need to wait for dependencies to be finalized before WGLC. Mark Duckworth gave a presentation on "CLUE Framework Status and Issues". He noted the main changes since IETF 89 in London: - Add Global CSE List - Disallow Area of Capture for audio, and add audio capture sensitivity pattern. Remove audio channel format attribute. - Add voice activated switching example - Clarifications and editorial Outstanding issues include: Can an Encoding Group include multiple media types? Mark's proposal is to say it is allowed, and update the framework and data model to make it clear. This was agreed. Do we allow defining a Media Capture that is not included in any Capture Scene Entry? Mark's proposal is to clarify that captures do not have to be in any CSE. This was agreed. The Area of Capture attribute was originally envisaged to apply for any media type, but it has recently been determined that it should not apply for audio. It was agreed that it should only be used for video. It was further agreed that text doesn't need any spatial information right now. Do we want the CLUE Framework document to reference the avt-ext Grouping Taxonomy document? Mark's proposal is not to change the Media Capture term, but possibly clarify the relation to taxonomy. Consider changing/clarifying other terms. He gave an example of mapping between CLUE terms and those in avt-ext Grouping taxonomy. This opened a long discussion, with a number of points made: - Need to be avoid same names having different meanings - Need to look at terms on a case by case basis - Do we need to refer to taxonomy document? When will it be issued? - Don't want document dependency Finally, Mary Barnes asked the question: Do we need to reference the taxonomy document in some form at all in CLUE? There was some consensus for not referencing at all. _______________________________________________________________________________________ Thursday Notes by Stephan Wenger _______________________________________________________________________________________ CLUE, 7/24/2014 13:04 Note Well Agenda Framework (Mark Duckworth, continuing from previous session) Slide 8 Christer: Global CSEList-> CSV: GlobalCSV list? N.N., "View" is bad because its not only video Slide agreed in full. Has to be reflected into data model and/or signaling 13:11 Slide 9 Long discussion about camera front/back/left/right 13:25 Mark: will propose specific text on email list 13:26 Synchronization ID People should comment on the sync ID solicited on list 13:32 media type for simultaneous transmission set ??? 13.34 treating audio captures (not recorded, Christer took notes of conclusion) Slide 10 Work continues 13:42 Paul K., Signaling draft Doc in good shape, need pre-WGLC review Cullen, CHrister were volunteered to review shortly (3 weeks or so). Slide 7 13:45 Tracker issues #28 close, #25 is protocol not signaling, #24, #30 close Stepped out 13:53 Back 14:21 Close 14:27 _______________________________________________________________________________________ Thursday Notes by Keith Drage _______________________________________________________________________________________ CLUE 2nd session Agenda bash Framework continued ------------------- Mark Duckworth presenting Slides: [Slide 8] Christer: Any reason why it cannot be called "global capture scene view list" Presenter: Maybe Chair: May work. Do not have a name for a single entry in a global capture scene entry list. Presenter: Could call it a global view Steve Botzco: Think it is important to have a name. Chair: View is used in many cases outside the visual. Presenter: Means changing a lot of references and updating in the data model. Chair: Off top of head such a change might result in renaming elements in the data model. Chair: Meeting agreed to everything else on the slide. This will go beyond the framework and need to work through all the documents. [Slide 9] CHair: Does not think we currently have a consistent view on front back etc. Want camera front / camara back etc, and scene front etc. Presenter: Need clarity that left and right are the same left and right in any scene irrespective of where the cameras are. Can then describe a location in respect of any camera system. Roni: Needs to be described in the framework. Chair: But this is the framework Roni: Believes is already clear in the framework. Roni: Camera position is defined based on the coordinate systems. Paul: Front and back is not described that way. Presenter: Assumes that there are cameras in one side of the room and not the other. Chair: Is the problem more with definition rather than left / right Jonathan: Coordinate system is defining the position of the camera in regard to the coordinate systems? Several people related to theatre that there needs to be a single coordinate system for the room. Keith: General case, decoupled from the camera. In specific cases where there is single camaera, then can choose to couple it to the camera. Mark will make proposal to list on how to resolve this. Paul: Sound level / round robin. Want to allow multiple captures that are synchronised in respect to that. Presenter: Think that this a different issue to the one I am talking about. What you are talking about is the index number to those. Presenter: Does not currently have an idea on how to clarify current description. Paul is only one who has a problem. [Media type of simulateous transmission set] Presenter to recheck. [example 12.1.1] Paul: ??? Presenter: Might be a type in the coordinate system, will recheck Paul: ??? Presenter: Example is based on a real world example which deployed and works. Paul: Then maybe it belongs elsewhere. Roni: Example matters, if want to describe then need to have a way to describe it. Currently decribed based on coordinate. Otherwise need some other mechanism. Roni says the example is correct based on what we have now. Coordinates to describe the audio is a different question. Presenter: Do have a mechanism of describing the audio. In this example the audio is described. Paul: Thought there was at least an error in the access of capture which seems to point towards the camera. Chair: Mark will check for an error in access of capture within example in 12.1.1. Others (including Roni) also asked to check the example for errors. [Slide 10] CLUE signalling status ----------------------- Presenter: Paul Slides: http://www.ietf.org/proceedings/90/slides/slides-90-clue-5.pptx [Slide 1] [Slide 2] [Slide 3] [Slide 4] [Slide 5] [Slide 6] Presenter: Paul indicated he has run out comments. Chair: Do a pre working last call to see that people have read the document. Presenter; Conceivably could be ready early than October timescale. Chair: Need reviewers. Cullen volunteered within next three weeks. Christer will do so after annual leave. [Slide 7] Presenter: Few issues open in tracker #28: Propose to close Agreed #25: Chair: Reassign to protocol but need more discussion on list Christer: Asked whether issue was size of message of something else. Jonathan: Is thinking in terms of size of message but also simplified processing with delta. #24,#30 To be closed. If material is brought in will deal with it at that point. [Slide 8] Chair: see reviewer list already identified. Christer: Does "fallback" belong to the protocol or does it belong elsewhere. Previously agreed not going to have implicit fallback but should have it described somewhere. Presenter; Will need proposals. Chair: Will open issue in tracker. CLUE Call flows ----------- Presenter: Roni Slides: http://www.ietf.org/proceedings/90/slides/slides-90-clue-2.ppt [Slide 1] [Slide 2] Matt: Would like an example of cameras from different viewpoints. Presenter: Question is whether this is a calldflow but will have different coordinates. Mark: That sort of example belongs in framework or data model. Mark: Call flows should focus on examples on something different going on at the signalling layer. ???: Maybe should show ICE. Mark: 1st two bullets are useful. 3rd bullet really only changes the description and we have examples elsewhere. Cullen: Do not think should show all ICE messages. Start with a simple example, and then show other examples with security DTLS SRTP turned on, or bundle, or ICE. Christer: In normative text will not talk about bundle, so why show in examples. SHould show the fallback. Paul: Is list of examples in draft: Presenter: WIll be in the document. Paul: Would be useful to discuss on mailing list about what other examples should be seen; what are the key things that this example will focus on and there leave out the remainder of the detail. Mary: Proposing to show very stripped down examples. CUllen: Think need most simple example complete. [Slide 3] Simon: If take examples from real world example will have lots of things. Difficulty is not to show security if take webRTC example. Some errors identified in slide. [Slide 4] [Slide 5] [Slide 6] Paul: Have been using informal representations for CLUE messages. Think should continue doing some of this. Simon: Have already started to provide these examples in a draft on a private website. Middle of september will be good deadline for first version of first example. Jonathan: Is there a call flow document in the past where we did this well. Mary: XCON or MEDIACTRL. Paul: Hisotry info Mary: Does not think this is a good representation of what needs to be done. Next steps ---------- Slide: http://www.ietf.org/proceedings/90/slides/slides-90-clue-6.pptx [Slide 4] Crhister indicated he will not be doing anything before end of the month. Mary: start back up with weekly calls on August 5th. No interim meeting planned. Matt Ryan: Are there any goals with Call flows before next meeting. Mary: Will need to work call flows into the schedule. ALso may be able to work the signalling through earlier. Paul: is feeling pretty good!! Meeting finished 14:29. _______________________________________________________________________________________ Thursday Notes by Christer Holmberg _______________________________________________________________________________________ Topic: CLUE Framework Draft: draft-ietf-clue-framework-16 Presenter: Mark Duckworth ISSUE: The following terminology renaming was suggested: Capture Scene Entry (CSE) -> Capture Scene View (CSV) Global CSE Lite -> Global View List OUTCOME: The suggested changes were agreed. ISSUE: Orientation of coordinate system - camera left/right, front/back OUTCOME: Mark will prepare a suggestion on how to describe the coordinate system without using left/right/front/back terminology. ISSUE: Synchronisation ID clarifications OUTCOME: People are requested to look at the e-mail thread associated with the issue ISSUE: Media type of a Simultaneous Transmission Set OUTCOME: It will be clarified that all media captures within a STS will have the same media type ISSUE: Example 12.1.1 treatment of audio captures OUTCOME: Mark is going to look at the example which has caused confusion. People are requested to check the example for errors. Topic: CLUE Signaling Draft: draft-ietf-clue-signaling-02 Presenter: Paul Kyzivat It was indicated that all of Paul K's significant concerns have been addressed in the latest version of the draft, and that a pre-WGLC could be called for in the end of October. Cullen Jennings and Christer Holmberg committed to review the document. ISSUES STATUS: #28: Resolved #25: Will be reassigned as a Protocol issue #24, #30: Resolved. BFCP usage will not be defined. NEW ISSUE: A new issue will be opened regarding fallback to normal session. Topic: CLUE protocol Call Flows Draft: draft-even-clue-call-flows-00 Presenter: Roni Even OUTCOME: - We will not add details regarding ICE messages (ICE candidates can be shown in SDP) and BUNDLE into the call flows - We will add an example showing the usage of secure media, using SRTP-DTLS - We will add an example on modifying a CLUE call to a "normal" call.