Minutes for CLUE WG @ IETF 87 ============================================ Date(s): Monday, July 29, 2013, 9:00-11:30, Tiergarten 1/2 Wednesday, July 31, 2013, 15:10-17:20 Location: Berlin, Germany Chairs: Mary Barnes, Paul Kyzivat Note Takers: - Session 1: Rob Hansen, Richard Ejzak, Stephen Botzko, Mary Barnes, Christer Holmberg - Session 2: Bo Burman, Christer Holmberg Summary: prepared by Mary Barnes Meetecho recordings: http://ietf87.conf.meetecho.com/index.php/ Discussion Summary/Conclusions/Action Items: ============================================ Framework: ----------- - Reviewed open issues with Framework. -- Issues to be closed: #34 Update Examples -- Issues requiring further action: # Remove contradiction about responding to Advertisement with Configure contradiction: http://www.ietf.org/mail-archive/web/clue/current/msg02684.html Mark to post proposal (to mailing list) to remove the details from the framework. Action: Chairs to open new ticket for signaling document. #35 Framework and data model consistency. This is an ongoing item. #36 Computational Complexity parameter. Action: Mark to send a proposal to the list. #33 Security: Mary to send text to Mark by August 12th. # Attributes with Consumer choices. Currently, provider can Advertise multiple values for scene-switch-policy, and Consumer can choose in the Configure message. Proposal is to not allow consumer to chose the value. Provider can advertise different captures with different values. This also impacts Data Model. Action: Chairs open a ticket. -- Issues to be re-assigned to the signaling solution: #20 Rejecting Configure # Advertisement/Configuration contradiction. - Framework (switching): Started the switching discussion (issues #19 and #26) on Monday, but decided to defer that discussion until Wednesday afternoon. We continued the discussion on Wednesday around the issues with no clear conclusions. It was also noted that Christian Groves is working on a draft on this topic. More discussion is needed. [Note: since the meeting, Christian has submitted draft-groves-clue-multi-content.] Framework - Roles: ------------------ The one clear conclusion is that there needs to be a clear distinction between roles that are human readable (meeting roles) versus those that are intended only for a conferencing system (machine readable). Simon pointed out that there is already an XML based standard defining roles. We need more discussion on the mailing list (and folks should closely read this document). Data Model: ------------ The document was updated to align with the current FW (and removing unused attributes). A number of proposed changes were discussed, including - Moving into the spatial information - A proposal for settings - Adding "view" as a videoCaptureType attribute - Proposal to resolve issues around Action: Chairs open issues in tracker for each of the issues in the presentation. Conclusion: A new version of the draft to be submitted soon and more discussion is required on the mailing list. CLUE Protocol: --------------- This is a first draft proposal for a state machine and messaging model to carry the information on the CLUE data channel. Clarified that the CLUE protocol messages are independent from the mechanism used to transport them. A new Configure Response message is proposed. There are some error and race conditions that need to be addressed. Conclusion: General agreement that this is a good start. For now, this work will continue a separate document, and later we'll see whether we should fold it into the CLUE Signaling document. CLUE Signaling: -------------- Each of the key topics in the document were discussed. - Relationship between CLUE messages & SDP. This is a critical work item. Decisions need to be made as to whether or not SDP and CLUE are negotiated independently, and use separate state machines. In either case the media needs to be consistent between the two. The relation of the CLUE solution to MMUSIC WG items was discussed. Conclusion: At this time, CLUE should proceed without being tied to any decisions made in MMUSIC WG for RTCWEB (e.g., BUNDLE & Unified Plan). If necessary, CLUE can bring additional proposals to MMUSIC WG. - Representation of Encodings: SDP or ADV. This topic was discussed in more detail in the CLUE SDP Interaction topic. - Approach to message responses (ack/nak/error). Conclusion: this issue is related to draft-presta-clue-protocol-00, and will be dealt with in that document. - Elaboration of message sequencing. The details for this will fall out of decisions with regards to relationship between CLUE messages & SDP, along with the representation of encodings and message responses. - Interoperation with Legacy SIP Devices. Discussion on how much (if any) normative text we need on this topic, and how much/what CLUE information should be in the first SDP Offer. Action: Christer will send suggested text. - CLUE Channel. Conclusion: Agreement to go ahead with SCTP/DTLS/UDP for the CLUE channel. - CLUE channel lifetime & error handling. Discussed whether the same SCTP channel will be used for other signaling. Discussion also around how RTCWEB is dealing with issues such as negotiating sub-protocols on the data channel, Action: Christer will talk to Salvatore, to verify whether RTCWEB intend to specify anything related to the format of data sent on the RTCWEB data channel. - Message Syntax Details. Conclusion: Agreed to use XML for the CLUE data format. - Approach to versioning/options/extensions. Agree that we need versioning and extensibility in the solution. However, the details depend upon the protocols used in the solution. Action: Ensure there is a requirement that future versions of CLUE need to be backward compatible. - Approach to message encoding - stand-alone or deltas. Conclusion: For now, use stand-alone. - Examples & call flows. This will we be done as the solution is developed. CLUE SDP Interaction: -------------------- A number of issues were discussed (details below) with no specific conclusions. Right now this proposal puts some stakes in the ground for a solution - e.g., using the SDP grouping framework to indicate which m- lines belong to a CLUE session. We need a lot more discussion and feedback on the mailing list to stabilize and complete this work. Application Token: ------------------ An overview of draft-even-mmusic-application-token in the context of CLUE was provided. Folks in the CLUE WG should participate in discussions on the MMUSIC WG mailing list. Way Forward: ----------- - Schedule regular design team meetings to progress the solution details. - Schedule an interim in mid-Sept. timeframe Detailed minutes ================= =============================================== Rob Hansen's Notes for Monday, July 29 ================================================ Mary provided a status update, giving a quick update on the various documents and the fact that many open issues have been reviewed recently. She also pointed out how important work being done in groups like MMUSIC, AVTCore and AVTEXT to CLUE. Mark presented a summary of the changes to the framework document (now on rev #11). The description attribute has been added to both Media Captures and Capture Scene Entries (previously was only part of Capture Scenes). A contradiction has been removed relating to whether a Configure must be sent in response to an Advertisment, though the framework has no answer as to which. A point was raised that this should not be in the framework document and be left to the signalling document; this proposal was well liked and will be proposed on the mailing list. A similar plan was to remove the detailed discussion of rejecting configuration from the framework, and reassign the issue to the signaling category. Two issues, #19 and #26, go together and relate to site switching. Mark questioned whether the issues were still relevant and needed seperate discussion or whether they are covered by the seperate document on switching. Christian is apparently working on a draft on this issue, but otherwise considerable work on this topic still remains. Mary will submit draft text on the security section in the Framework by August 12th. The examples have been updated to make them consistent: Mark proposed that we close ticket #34 (related to updating examples) as the task is complete. The ticket will be closed. The data model and framework have both been updated to make them more consistent (related to ticket #35). However, since this will be an ongoing process the ticket will be kept open. Encoding parameters have been changed to make them less encoding-specific (macroblocks per second changed to pixels per second). There was a question about how much detail should be in the framework (should it define specific limits). One issue is that how the encodings are defined is still under active discussion, and whether encoder limits are codec-dependent or codec-independent. Currently encodings in the signalling document are encoding-dependent. There was also discussion of how sensible it is to express encoding groups constraints to any level of detail - there was no clear consensus on this, so Mark will post a proposal to the list. One attribute (scene-switch-policy) has special properties, that the provider can advertise multiple valuesand the consumer can pick one. There was a proposal that this is over-complicated, and since this is the only attribute that works this way it is best to remove it and just have the sender advertise multiple captures with different properties (and have the far end choose). General agreement was that if this is the only attribute of this type people want then it is over-complicated, but that if the behaviour is removed and later users want to start using more consumer-selecting attributes this will cause an explosion of captures. There will need to be further discussion on the list on this issue. Mark then started providing information on the complexities of switching, adding the complexity that the receiver may want to select specific sources. He provided an example of how a sender that can send up to N captures can do this: by listing N capture scene entries with different numbers of captures (from 1 to N). At this stage it was clear that there was significant interest in this topic, and the chairs decided that they would request an additional hour on Wednesday and return to the topic then. Roni presented Christian Groves' draft clarifying and expanding the 'roles' section of the framework. There was discussion at the beginning about the level of detail for roles, and the risk of overlap with XCON. Roni clarified that the purpose of the roles were to help differentiate between which captures to subscribe to. Simon proposed the use of an existing standard and will post a link to the list. The draft does have support for using the existing vCard standard. Keith pointed out that interactions with existing standards such as BFCP which also have roles may overlap, and the precise meaning of these roles may differ. Simon presented the data model draft, which has just become a working group document, and hence work has been done to align it with other working group documents along with other documents (such as the switching draft). Simon summarised a number of deleted elements. One removed element is 'micPattern'; John has a proposal on the list for how to add audio information, and the hope is that this can be used. The element has been replaced with , defining that a capture may move (static, dynamic or highly dynamic). Simon proposed moving the mobility information within the spatial information. For settings, the proposal was to define priority as unsigned ints (lowest value is highest priority), with the element not being present meaning the lowest priority. New media capture attribute are proposed: presentation and view. These are taken from the framework. The proposal was that they are not mutually exclusive, and that they are not media-specific. The proposal for view was to add it to the videoCaptureType as an enumerated string; this *is* media-specific. Others agreed that mediaCapture was a better place for it (and based on that the term 'view' is not particular suitable). The discussion moved into a general discussion of the overlap of 'view' with role, which originally came from a draft by Christian. Simon expressed some of the issues with expressing capture encodings as currently defined. Part of the proposal he presented was to make switching policy part of the capture definition (as previously discussed during Mark's definition). The encoding parameters are also problematic; if we do end up using SDP for expressing encodings then these too should be removable as they can be expressed in SDP. Roberts and Simon will make a number of changes and issue a 01 version of the document Simon then presented the new draft on the protocol (draft-presta-clue-protocol) providing state machines for the sender ('media provider' in the draft) and receiver ('media consumer' in the draft) - lots of feedback has been provided on the list since then, but the draft provides an initial discussion point. There was some question of the basic requirements and whether these messages could be run over SIP. General feeling was that the messages themselves should be transport-independent, but that the signalling discussion will provide the need for the DTLS/SCTP channel. The draft proposes a READV message that acts as a combined NACK and state refresh - it contains a request field that defines the motivation (refresh, not supported option/extension/version). Needs to cope with contuinally getting invalid ADVERTISE messages. Can have a timeout or error count to deal with this. Simon then summarised the state machines, which included some discussion. The conclusion was that work on this will continue based on both previous feedback and discussion which will occur on this list; for the time being this will be a seperate document, though in the long term it may well be merged into a seperate document. Roni rapidly summarised the MMUSIC application token draft, showing how it can be applied to CLUE. An appID is associated with an RTP stream, which can be sent in a number of formats (SDP, RTCP SDES message, RTP header extension). Can be new, or replace an existing. Can be used with an m-line or with a specific SSRC. A page in the presentation showed how this can be used in CLUE. The receiver defines the appID, the appID identifies an SDP m-line (which is in turn mapped to a CLUE encoding ID). Roni made the point that encoding IDs will need to be unique between encoding groups to provide a unique ID to map the appID to. For switched captures, appIDs are assigned to the appropriate source. Roni and Jonathon will be presenting this in more detail in MMUSIC, where additional detail will be provided and clarified. Paul started presenting a draft on signalling, though with limited time it will be continued on Wednesday, summarising the major issues. SDP/CLUE interaction is taken from Rob's draft with the negotiations independent Whether encodings are in SDP or CLUE is an open issue - current draft has work from Rob on encodings in SDP. This is an open issue and does lead to additional offer/answers. More discussion is required here; this impacts other sections, so it is important this discussion is had. ACK/NACK/RE-ADV is another open issue - ADVERTISEMENT and CONFIGURE need explicit responses. CONFIGURE messages can be used as an ACK; if not, does a CONFIGURE need to be sent for every ADVERTISMENT? Message sequencing also needs to be worked out, with state machines for provider and consumer, and the coupling between them. Legacy is another issue. Another is the CLUE channel - SCTP over DTLS over UDP is the current proposal that was decided on last year. All of this needs work. Many of these can be explored in parallel. It will be important to identify one or more people for each area so that work can be done. This presentation will be continued on Wednesday, where we will hopefully have two hours. The presentations are all online, for those who wish to read them ahead of time. ============================================== Richard Ejzak's Notes for Monday, July 29 ============================================== Framework document updated. Mark Duckworth presented the update. Changes listed in presentation with proposals adopted unless stated otherwise. The identified protocol contradiction is removed and will be addressed in protocol development. #20 resolution accepted. Site switching needs further discussion. Mary will provide text for security section by August 12. Closing #34 with updated examples. Closing #36 deferring details to protocol? Steve and Rob Hanson agree. Roni thinks it's a general issue that belongs in framework with no natural home in a detailed spec. Roni asks if encoding parameters are codec dependent. Steve indicates there are both codec independent and codec dependent parameters that clue needs to handle. Pixels/sec is codec dependent. Cullen agrees. Jonathan asks how much detail needs to be captured in framework. Jonathan doesn't think we need to solve all parameter issues in clue. Issue remains open regarding encoding parameters. Remove consumer choices for scene switch policy? Rob concerned with explosion of options in the future and thinks it could be useful to keep. Jonathan doesn't want this new mechanism without more confidence that users will demand this. Christer thinks other mechanisms can be used. Mary will open an issue in the tracker and it will go to the list. Switching examples. Christer asks what terminology to use - mixer or switcher, since example does not show any media translation? "Composer" is the agreed term for translation. Christer asks why we can't just list all the capture scenes in one list without describing all combinations? Do capture scenes need to be supported simultaneously? Jonathan disagrees as there should be a complete description of each supportable scene. The WG is interested in pursuing further discussion of switched captures and will continue the discussion later in the week. The issue remains open. Clue "roles" by Roni Even. Exchanging information about meeting participants. Christer asks about dynamic role info (e.g., last speaker). Roni thinks this is out of scope for the implied scope of this particular work. Jonathan thinks xcon might be a better place to deal with dynamic info and out of scope. Rob thinks role information is needed to help user to select capture scenes. Roni says role information not needed if you know everyone in the room. Dan Druta concurs with role classification. Simon points to a hierarchical XACL standard for describing roles that can be used. He should send reference to list. Christer asks if dynamic role information should be used to automatically control which scenes to display? Keith concerned about interaction between different levels of conference system control. Relationship to BFCP? Draft should discuss this relationship. Roni agrees. Rob likes split between conf system roles and business relationships. Need more discussion. Simon presents on clue data model. Christer doesn't see distinction between role and view. Simon agrees there is potential overlap. Need further discussion. Roni thinks view should be generalized for media and not specific to video. Jonathan asks for use case for "view" and what actions are taken. Is this needed? Simon points out that the framework has some examples where this is needed. Need to allow enumeration of other values. Mark agrees with Roni that view should be generalized. Simon wonders if the term "view" should be changed. "view" should apply to audio and text as well. Mark suggests to refer to Christian's draft for additional motivation. Rob agrees on advantages of separating capture encodings from capture scenes. Roni reminds É (didn't catch detail). Some further changes to the data model draft will come based on the conclusions captured in the presentation. Simon presents clue protocol changes. Ekr wants to know why protocol is limited to data channel? Simon indicates that other transport options are not precluded. Paul and Rob ask about applicability of error codes to message types and how to signal success. Simon indicates that this is clearer in the draft. The response codes listed are just examples. Christer thinks race conditions are missing from state machines, particularly if you are both a consumer and provider. Mark thinks this is a great start. Nacks need to be better integrated into state machines. Do we need a specific ack for advertisements? Timeout for user interaction needs to be identified. Rob concerned that no difference between lack of receipt of advertisement and periodic retransmission waiting for configure. Roni introduces need for application token. Proposal to be discussed in mmusic. Cullen not sure what appID represents when it is dynamically reassigned. Cullen concerned that this level of abstraction will cause a lot of unnecessary complication. Colin doesn't see how this is related to work in mmusic. Mark asks if clue usage goes in to the mapping document? Yes. Rob likes this approach. Why can't the provider specify IDs? Colin points out that there seems to be confusion between the identification of the contents of the stream and how it is displayed. Aren't these separate functions? Richard: +1. Paul talks about clue signaling. Brief presentation with no time for discussion. ============================================ Stephen Botzko's Notes for Monday, July 29 ============================================= 23-07-29 Clue Meeting Meeting starts 9:04 9:08 Framework - Mark Duckworth Review of changes References to signaling (responding to advertisement, also if messages are complete or deltas) are notes. ÊProposal (for the list) it to move to signaling protocol. #20: Rejecting Configure: leave framework silent, and move issue to signaling protocol #19, #26: site switching #33 security. ÊMary to provide input by 12 August 2013 #34, ticket will be closed #35 ticket complete for now, but will be left open since it is an ongoing task. #36 codec dependent - general assessment that this is problematic. ÊMore discussion needed on encoding parameters Remove ability to select scene-switch-policy apart from captures? Take to the list. Switched Capture - WG is interested in pursuing. ÊPlan to come back to switching in the next session. 9:55 Roles - Roni Even One challenge is making sure we stay within scope. ÊRoles in general may be too broad, though providing some information is important to choose what captures to configure. There is an existing access control XML schema which could be re-used. vCard (RFC6350) is also relevant. Roles is used in multiple senses (conference control roles seem different from titles). 10:05 Data Model - Simon Romano Most issues here are really about the framework (the data model being based on the framework). View/roles should be in mediacapture, not limited to video. 10:37 Clue Protocol - Simon Romano ekr commented that transport question is distinct from message content. ÊGeneral agreement. Readvertisement Message - could be useful to distinguish readvertisement (and the reason for the refresh) from a usual advertisement. 11:02 Application Token - Roni Even Overview of mmusic draft, focusing on clue. 11:20 Clue Signaling - Paul Kvzivat Summerization of status and issues. ÊDetailed review in next session. ============================================ Mary Barnes' Notes for Monday, July 29 ============================================ Framework Remove contradiction about responding to Advertisement with Configure still open issue for the protocol. Decision: this is a solution issue. #20: Rejecting Configure. Decision: this is also a solution issue. Switching Roni: needs to be clear how you achieve switching (there is a use case). Christian is writing a draft. Christer: in general we need more time to discuss switching. Security: Action: Mary to provide text. Ticket #34: Close. Ticket #35: Ongoing. Ticket #36: Computational complexity parameter - How much encoding params do we need in FW? Steve: this is a mess. Maybe leave out of FW. Mark: should we wait more for encoding group work to complete Rob: FW needs to say we need encoding parameters, but details may not need to be in FW. Roni: Need to state this in FW. Rob: Once you define encoding, it will be in a more specific format. FW needs to stay that there are encoder constraints that must be specifiable. Right now it is codec dependent. Steve: there will be other codecs. Ideally, FW can support both codec dependent & independent prams. Thus, don't need specific details. Roni: we should make a decision. Jonathan: is this encoding paramas or "encoding groups" Mark: the latter has some codec independent prams. We have in encoding groups pixel/sec param. Jonathan: there's no reason why different encodings need to use same codec. Paul: thought issue was that when you put encoding group, you imply the "cross" thing. How do you say that? Mark: Remove ability to define different codecs with dependency between them. Can keep bit-rate. Rob: this was probably Andy. Without a way to express arbitrarily complicated systems, you have to go whole hog or you just go to basics - i.e, I have this much BW. Steve suggests pixels/sec isn't enough. Maybe should just stick with BW. Steve:Ê...can reject if can't handle.. Jonathan: if we've gone down this path. CLUE doesn't need to specify things that can be solved in other WGs. Conclusion: needs more discussion. Mark will post something on the list - WG needs to provide feedback (set deadline). Remove idea of attributes with Consumer Choices - has unintended complications: - Proposal: do not allow Consumer to choose the value. Provider can advertise different captures with different values, just like any other attribute. Rob: only issue with removing is that if this is behavior we want with switch policy, this would have to advertise multiple ones. This increases the size of captures available. If we later want consumers to have this functionality, then you'd have to re-advertise capture. Mark: This seems to solve more problems than it solves now. Rob: can see implementations later wanting to add this. Jonathan: do people have extensions that they envision to twiddle params? If not, then we shouldn't add this. Rob: this is the only one I can think of - i.e., Provider can advertise multiple values for switch-policy and consumer can choose in the configure message. Christer: may be able to do this (configure) with another mechanism Jonathan: if we get this wrong, it will be ugly later. Conclusion: needs more discussion. Open an Issue in the tracker. Switched Capture. Christer: we discussed terminology in interim. This isn't mixing in that we are creating something new. Mark: RTP topologies document uses that term. Mark: we have been calling that (what Christer calls mixing) composing Christer: we can do this (Advertisement Scene 1). ... Defer discussion until Wed. pm Roles Christer: conference System roles - for active speaker(s) Roni: these are dynamic. They don't have same context Christer: you can update info during session. Roni: these are pre-assigned roles Jonathan: thinks info is useful. why does it need to be in CLUE? More suited for XCON. Unless there is something with regards to how we would choose what's in advertisement. Rob: important bit is for roles - how it effects what captures to configure. Need enough info for that. Dan: thinks categorization needs to be restructured between those needed by systems versus participants (user visible). Simon: this discussion is interesting. WE had this discussion multiple times in the past. In the end, we arrived at nothing. Especially here with XMl schemas, there is a standard that is a hierarchical approach. Action: send a note to the list with a pointer. Christer: roles can change during session. Keith: concerned about interactions at different levels. Eg., need to look at BFCP. Rob: Like the split between meeting roles and conference roles - need to be very clear which is which (machine versus human readable) Conclusion: Agreement that there needs to be clear split. Needs more discussion. Data Model - Open issues in Tracker for proposals in the presentation - View attribute (from FW): -- Are they mutually exclusive? -- Are they media specific? If so then "view" isn't right term for audio. -- Might have same issues as we had with content attribute - Proposal for "view" in data model Christer: comments in the FW. What's the distinction between "view" and "role". There is potential overlap Roni: You are putting in video capture type (and not media capture type)? Simon: at the moment. Based on current def of view attribute. Roni: think this should be more general - media capture Jonathan: in this room, we have 3 separate audio captures - that would be a view. Simon: not sure if "view" is okay for audio captures. Jonathan: taking a step back - what is use case where this is needed? How is this populated and what actions taken based on it? Seems infinitely extensible set. Simon: maybe useful as an attribute that's a side definition of a capture scene. With this representation, just useful for video captures. Audio is much more complicated (ala John Leslie's proposal). Jonathan: doctor's surgery example - none of these roles are applicable Mark: agree with Roni about the view attribute should be part of more general media capture. There may be possible uses with audio. simon: do you want to keep current semantic? Mark: folks have been interested in other media types (e.g., text). Use cases and values came from an individual draft by Christian. suggest to revisit Christian's draft. Conclusion: Will move view to the media capture level. needs additional discussion. Capture encoding: Slide 14 - conclusions??? - ... ..A possible solution (slide 15) Rob: can do in SDP. Roni: same discussion as FW. You have in encoding type, media capture id. Simon: yes, need to check. CLUE Protocol (Simon) Proposal for Configure RESPONSE message. Additional proposal for a re-ADVERTISEMENT Ekr: without taking a position on this protocol. Why if you are defining new protocol are you limiting to a p2p data channel? Why not over SIP? Paul: next presentation will cover this. Jonathan: the idea that we could use DTLS/SCTP was an earlier decision. Paul: when I read this - saw this list and didn't see success responses. This is to report errors only. In effect Configure is ack of advertisement Simon: Yes, you have 200 OK semantics Rob: there was this table and another table of others. Dealing with ADVERTISEMENT errors: Jonathan: be cautious about getting new ADV because something is wrong and not re-requesting yet again. Simon: Yes, need a timer. Christer: need to deal with race conditions. when you send a configure and receive that before 200ok. Simon: some have been identified. The use of timeouts, retries and sequence numbers can help to manage that. Christer: i.e., in trying state, need reconf Simon: that's other state machine Mark: think these state machines and protocol is a good start Agree that there is some discussion of responses, etc. that need to added. Using Configure as an Ack for advertisement. think we want an explicit ack. Configure can have a really long timeout. some attributes meant to be interpreted by a human user. Conclusion: folks think this is a good start. Needs revision and more discussion. Application Token Roni provided overview of work to be discussed in MMUSIC. Mark: is the idea to specify the CLUE specific usages of APPID in CLUE RTP mapping document. Jonathan: this is CLUE's requirements. Mark: don't we need to include this in CLUE docs Rob: like this. Why couldn't APPID be defined by the server? Roni: wrote initially by sender, but if you read MMUISC unified plan, want it to be the receiver. CLUE is more flexible. Colin: still unclear how this relates to SSRC? Almost seems like a replacement to SSRC. Maybe this is a label for an SSRC. Need to be clear to keep distinction between layers of de-multiplexing. Jonathan: probably not well explained in draft. Signaling Paul went through quickly the signaling document slides. We will discuss in detail during the Wednesday WG session. ============================================ Christer Holmberg's Notes for Monday, July 29 ============================================ Topic: CLUE Framework Presenter: Mark Duckworth Draft: draft-ietf-clue-framework-11, draft-duckworth-clue-switching-example-01 Issue: Remove Advertisement/Configuration contradiction issue from the framework. When presenting the changes from the previous version (-10) of the draft, but was suggested to remove the issue related to the Adv/Conf contradiction from the framework document, and deal with it as part of the signaling work. Outcome: The proposal to remove the details regarding Advertisement/Configuration contradiction from the framework document will be sent to the list. Issue: Rejecting Configure (#20) It was indicated that detailed description does not belong to the framework, and shall instead be moved to the signaling document. Outcome: Propose to remove configure rejection details from the framework. Issue: Site switching (#19 and #26) Indicated that Christian G is working on a draft. Outcome: More discussions are needed. Issue: Security (#33) Outcome: Mary Barnes will provide text for the security section, by August 12th. Issue: Update examples (#34) Outcome: Examples are updated, and ticket will be closed. Issue: Framework and data model consistency (#35) Outcome: The ticket will be kept open for now, as it might be affected by other decisions Ticket: Computational complexity parameter (#36) There was much discussion, but it was not possible to find common ground. Outcome: Mark will send a proposal to the list on how to solve the ticket Issue: Remove idea of attributes with Consumer choices (new ticket) Provider can Advertise multiple values for scene-switch-policy, and Consumer can choose in the Configure message. It was proposed to not allow consumer to choose the value. Provider can Advertise different Captures with different values, just like all the other attributes. Outcome: Mary will open an issue on the tracker, and the topic will be taken to the list Issue: Switched Capture Example Outcome: More discussion is needed. Topic: Roles Presenter: Roni Even Draft: draft-groves-clue-role-clarifications-00 Indicated that people have different opinions/interpretations of the meaning of a role. The different role types need to be clarified. Suggested to define different types of role categories. Indicated that roles can be dynamic. For example, the "active speaker" role can change. Indicated that static roles can be indicated in an advertisement, but discussion about whether one would send a new advertisement every time a dynamic role changes. Question whether roles belong to CLUE, or whether some parts belong to e.g. XCON. Indicated that roles should only be used to choose captures from an advertisement. Suggested that roles should be categorized based on roles that need to be understood by the system, and roles which are meant for informational purpose. Outcome: More discussions are needed. Topic: Data model Presenter: Simon Pietro Romano Draft:draft-ietf-clue-data-model-schema-00 The draft has previously been adopted as a WG document. XML objects: Deleted, modified and new XML objects. Priority: Indicated that if, for a given capture, priority is not explicitly indicated, the lowest priority will be assumed. Media capture attributes: Are attributes mutually exclusive? Are attributes media specific? Indicated that it is difficult to distinguish between role and view, and that there might be an overlap between roles and views. Outcome: A new version of the draft is expected in the near future. Topic: CLUE Protocol Presenter: Simon Pietro Romano Draft: draft-presta-clue-protocol-00 Clarified that the CLUE protocol messages are independent from the mechanism used to transport them. Outcome: For now, the work is done in a separate document, and later we'll see. Topic: Application ID Presenter: Roni Even Draft: draft-even-mmusic-application-token-00 There were a number of detailed questions on the proposed mechanism. Indicated that the details will be discussed in MMUSIC, and that the purpose of the presentation was to give a picture on how the mechanism could use used within a CLUE context. Outcome: People interested in the mechanism are encouraged to participate in the MMUSIC session, there it will be discussed more in detail. Topic: CLUE Signaling Presenter: Paul Kyzivat Draft: draft-kyzivat-clue-signaling-04 Indicated that work is needed for all issues. Suggested that, for each issue, someone should take the role of driving the issues. Teams of people interested in specific topics can be created. The signaling discussions will continue during session 2. ============================================ Bo Burman's Notes for Wednesday, July 31 ============================================ CLUE and SDP signaling; Paul ============================= Relationship between CLUE messages & SDP ---------------------------------------- Mark: Is this still related to the MMUSIC appID, does it fit in? Paul: Don't think so. Rob: we have changes in sip/sdp we have in clue signaling, we have no shared state machine so there are times when we have to change both. Jonathan: There isn't any further work in that MMUSIC defined for RTCWEB that we need to do. Roni: We need to make a similar document in CLUE to specify how we do it here, for example how we use BUNDLE. Mary: We don't want to how to make documents now. Keith: MMUSIC will give us further decisions on how handling of multiple streams will read in general on further work, CLUE will have to take that into account. Christer: We have not discussed how to use BUNDLE in CLUE. Paul: We have for the moment a decision to not use BUNDLE. Jonathan: Broadly speaking, the thing that was specified in MMUSIC for RTCWEB will work for CLUE. I can make up a short document on that. Representation of Encodings: SDP or ADV --------------------------------------- Rob: Think there is a bigger issue than o/a, in the detail you can specify an encoding in SDP compared to what is possible in ADV. Christer: Anything needed by an intermediary needs to be in the SDP Paul: Even if we put encoding in ADV, some things still has to be in SDP. Christer: Then we have two use cases; what needs to be in ADV/CFG and what needs to be in O/A. Paul: If in SDP, it will not be in ADV, and then you cannot make a CFG. Taking decision to have it in SDP will have implications. Approach to message responses ------------------------------ Paul: we have something as a reasonable starting point, but need continued work Elaboration of message sequencing --------------------------------- Rob: They in some sense share the same transport but should there be coupling between state machines? Paul: The coupling is pretty loose. Mark: Is the usage of o/a part of the coupling between provider and consumer? Paul: yes. Christer: I don't necessarily agree, we can use sendonly and recvonly streams. Paul: we could do the same in multiple o/a. Mary: we need more input. Paul: I'd rather see the encoding in the ADV. Legacy Mode ----------- Christer: Think we should specify how the initial offer should look like. Jonathan: Make distinction between someone who doesn't want to make so much else, and someone that don't want to break a non-clue device. Rob: This is not a CLUE specific issue. For example BUNDLE as discussed before; if we know in what context we are we can be more free. Hadriel: RTCWEB is greenfield, we want to have a decision now and define how we interwork with legacy to reduce your interoperability issues. Paul: Want someone to put a stake in the ground in the document. Jonathan: If you worry about boxes that cannot negotiate away m-lines that it cannot handle. Prefer that things blow up early if they're going to blow up and be very careful in the initial SDP is not going to help there. Christer: I sent a proposal long ago about the initial offer. Rob: I think there is text in there. If we're paranoid about middle boxes then maybe we can specify what is going to work. Hadriel: If it is going to fail we want it to fail early. We should also decide if we are happy with the fallback. People really hate to have failed calls and have to re-attempt. We have to work offline. Media feature tags does not always really go through. Clue channel ------------ Agreed to use SCTP over DTLS over UDP, as was proposed already for some time CLUE channel lifetime & error handling --------------------------------------- Christer: We also need to make decision if SCTP channel and CLUE channel goes hand-in-hand; do you want to close CLUE channel but keep SCTP open? Paul: Good question. Need to be worked out. Christer: is willing to work on this Message Syntax Details ---------------------- Paul: Propose to re-use whatever is in the CLUE framework Hadriel: Don't you want to re-use what rtcweb use, like JSON and so on. Christer: I'm not sure that they use anything specific. Keith: My understanding is that the only document about rtcweb data channel that exists is now in dispatch. It is just a raw message. Paul: They pair the SCTP directions, but other than that they don't do anything. Richard Eizak: rtcweb will not create sdp that negotiates specific applications for their SCTP; it only sets up the associations. If you want to more than that, like setup a CLUE channel, then you need something else. I think we have a way to be interoperable rtcweb. I will send a link to a document that specifies, in SDP, what application to use. Mary: Agreement to use XML? Yes. Approach to versioning/options/extensions ------------------------------------------ Christer: Assuming that there will be a registry on what goes on the SCTP channel, this will have some impact. Paul: I just want it done. Jonathan: You want to discover things that aren't going to work early, you don't want to discover it late. Hadriel: Any token in SDP specifying the CLUE channel is a versioning in itself. A non-backwards compatible new version can always define a new token. Christer: The only thing we need now is that future version must be backwards compatible. We don't have to decide here and now. We will also need help from MMUSIC in detailing this for SDP. Approach to message encoding stand-alone or deltas Paul: Propose stand-alone for now, revisit later if needed. Christer: Strong support. Examples & call flows ==================== SDP syntax and ... ; Rob ----------------------------------------- CLUE encodings via SDP ---------------------- Mark: Sendonly maps to ADV, recvonly to CFG? Yes. Paul: do you foresee that we can re-cycle the sendrecv lines that were used for initial as encodings for captures? In general no, for example I was for example assuming that if clue channel goes down, you would fallback to the legacy m-lines. Christer: If we re-use we would have to change the directionality, for now we could for example set the legacy m-lines to inactive when they are not used. Rob: Receive constraints are expressed in SDP only; that is probably something we need to discuss. Establishing which audio/video m-lines that are CLUE controlled Mark: example might be a content:slides that is controlled by bfcp and not by clue? Yes. Rob: Use grouping framework (no opposition). 'mid' and 'label' Jonathan: The mid is traditionally only for grouping and label for anything else - don't know why. Look at what rtcweb does on msid. Signaling CLUE support ---------------------- Christer: we could media feature tags also, but Hadriel said we should not rely on it. We still need it in SDP. Rob: Paul talked about this Implications of independence ---------------------------- Christer: Depends on how the signaling flows is going to look like. Is it an error case? No, it is not an error case. Recommended operation ---------------------- Christer: What does "do not act on it" mean? Reject the m-lines. CLUE Framework; Mark Duckworth ------------------------------ Advertisement - 1 scene Advertisement - Multiple Scenes Christer: Isn't the definition of a scene that it has a spatial relationship? Not necessarily. Switching Example Issues - Single Scene -------------------------------------- Jonathan: In general prefer multiple scenes. There's a problem in how you should construct your scenes for example if you have both 3-screen and 4-screen systems participants. Rob: Also switching strategy constraints, like switching in groups of three, is a problem. Switching Example Issues - Audio Switching Example Issues - Roster -------------------------------- ... Switched Captures - next steps ------------------------------ Mary: We will need the promised draft from Christian Aug 19 at the latest. Way Forward ============= Design team meetings was and will likely be held Tuesdays at 9.00 Central. If we have design team meetings. Simon, Rob, Christer, Roberto, Jonathan, Roni. Virtual interim, maybe two, will be announced by doodle. ============================================ Christer Holmberg's Notes for Wednesday, July 31 ============================================ Indicated that one aim is to get people to commit to work on different parts needed to progress the signaling work. Topic: CLUE and SDP Signaling Presenter: Paul Kyzivat Draft: draft-kyzivat-clue-signaling-04 Ê Ê Issue: Relationship between CLUE messages & SDP (slide 3) It was suggested that SDP and CLUE should be negotiated independently, and use separate state machines, and that the media must be consistent with both. It was suggested that the signaling specification also needs to cover BUNDLE usage for CLUE. It was pointed out that usage of BUNDLE has never been discussed in CLUE, and that there is no decision that CLUE would use BUNDLE. Rather, there is a decision to not use BUNDLE for the time being. Such decision may of course be changed in future. There were some discussions on the SDP decision made in MMUSIC for RTCWEB, that CLUE shall not be bound of such decisions, and that CLUE can bring (if needed) if needed their own requirements to MMUSIC. Issue: Representation of Encodings: SDP or ADV (slide 4) Indicated that the document currently assumes that (as also suggested by Rob H) encoding representation is only carried in SDP, not in the CLUE Advertisement message. However, there is no agreement on such approach. Indicated that an approach with encoding representation carried only in SDP may require more SDP Offer/Answer transactions. Indicated that if information that affects the SDP is put in the Advertisement, it still needs to be put in the SDP, which means it will be carried in two places. It was indicated that, if information is not carried in the Advertisement, a consumer may not have enough information to send Configure until it has received, and retried the information from, SDP. Indicated that it would be good to avoid having the same information in two places, but that there might be use-cases which require that, and we need to figure out what information that is. Outcome: No decision, but indication that the topic will also be part of Rob's presentation. Issue: Approach to message responses (ack/nak/error) (slide 5) Indication that there has been very little work on this issue. Indication that this issue is related to draft-presta-clue-protocol-00, and will be dealt with in that document. Issue: Elaboration of message sequencing (slide 7) Issue: Legacy Mode (slide 8) Indicated that this issue can be worked with in parallel, as it should not have so much impact on the other work. Discussion on how much (if any) normative text we need on this topic, and how much information the first SDP Offer should be. Indicated that CLUE shall specify how the initial SDP Offer looks that, one reason being that it will be easier to add CLUE to existing network, as the operator knows how the messages coming from CLUE entities look like. Indicated that, for telepresence systems, call establishment time is not critical. Indicated that we do not design a system for entities that do not behave correctly. Outcome: Christer will send suggested text. Issue: CLUE Channel (slide 9) Outcome: Agreement to go ahead with SCTP/DTLS/UDP, as described in slide 9, for the CLUE channel. Issue: CLUE channel lifetime & error handling (slide 10) Discussion about the relationship between the CLUE channel and the SCTP channel, and whether we need procedures for cases where the channel is closed. Is there a fallback to legacy? Who is responsible for re-establishing the channel (including sending the needed SDP Offer)? Question whether we shall be able to close the CLUE application layer channel, even though we keep the SCTP channel open. Indicated that the SCTP channel might be used also for other protocols. Unclear how different usages will be negotiated. Indicated that this topic can be progressed independently from other issues. Discussion on whether RTCWEB intend to specify anything related to the format of data sent on the RTCWEB data channel, and whether CLUE should follow the same approach. Indicated that there is proposed work in DISPATCH on how to negotiate a sub-protocol for MSRP, and that such mechanism could also be used to negotiate a sub-protocol for CLUE. Outcome: Christer will talk to Salvatore, to verify whether RTCWEB intend to specify anything related to the format of data sent on the RTCWEB data channel. Issue: Message Syntax Details (slide 11) Outcome: Agreed to use XML for the CLUE data format. Issue: Approach to versioning/options/extensions (slide 12) Indication that a protocol indicator, depending on how it is implemented, and whether it is general or CLUE specific, may be specified in another WG (e.g. MMUSIC), and that CLUE for now should focus on the requirement. Outcome: We need to write a requirement about future versions of CLUE have to be backward compatible. Issue: Approach to message encoding stand-alone or deltas (slide 13) Outcome: For now we are not going to support deltas. Issue: Examples & call flows (slide 14) Topic: CLUE and SDP Signaling Presenter: Rob Hansen Draft: draft-hansen-clue-sdp-interaction-01 Issue: CLUE encodings via SDP (slide 2) Current assumption is that separate m- lines are used per direction (sendonly and recvonly). Discussion on whether m- lines used to indicate legacy capabilities can be "re-used" in case both endpoints will end up establishing a CLUE session. Suggested that we shall not "re-use" legacy m- lines. There are very few of them, and one may disable them e.g. by setting them to inactive mode. Issue: Establishing which audio/video m-lines are CLUE controlled (slide 3) Suggestion to use the SDP grouping framework to indicate which m- lines belong to a CLUE session (are CLUE controlled). Issue: 'mid' and 'label' (slide 4) Outcome: Need to check what work is done in RTCWEB regarding referencing m- lines from applications. Issue: Signalling CLUE support (slide 5) Indicated that the mechanism should not rely on feature tags being passed end-to-end. However, they can be used in order to help routing towards CLUE terminal. Then, if removed, the mechanism will not break. Issue: SDP and CLUE independence (slide 6) Issue: Implications of independence (slide 7) Issue: Recommended operation (slide 8) Topic: Switched Captures Presenter: Mark Duckworth Draft: draft-duckworth-clue-switching-example-01 Question whether everything in a scene needs to have a spatial relationship? Answer that spatial information is optional, and that it is not possible to indicate spatial relationship between different scenes. Outcome: More work is needed. NEXT STEPS: --------------- One or two virtual interim meetings planned before the Vancouver IETF meeting. Design team phone calls will continue. Will focus on solution, rather than the framework. The following people indicated willingness to participate in design team meetings on signaling: Simon, Christer H, Paul K, Roberta, Jonathan L, Rob H, Roni E