CLUE Minutes, IETF89, March 2014 Date(s): Wednesday, March 5 (1300-1500, Park Suite) Friday, March 7 (0900-1130, Park Suite) Location: London, UK Chairs: Mary Barnes, Paul Kyzivat Notetakers: - Session 1: Mo Zanaty - Session 2: Rob Hansen, Christian Groves Meetecho recordings: - Session 1: http://ietf89.conf.meetecho.com/index.php/Recorded_Sessions#CLUE - Session 2: http://ietf89.conf.meetecho.com/index.php/Recorded_Sessions (scroll down to Friday - as of the date/time of these minutes, the Friday link doesn't work and CLUE II is not in the session name filters) Discussion Summary/Conclusions/Action Items: ============================================ General: --------- Action (authors, all docs): review documents for consistency with draft-ietf-avtext-rtp-grouping-taxonomy Signaling (draft-kyzivat-clue-signaling): ------------------------------------------- Action: (Rob) Clarify text around the non-CLUE m-lines Action: (Chairs) Open issue for "Changing CLUE status mid-call" Action: (Chairs) Make call for WG adoption of the draft after the meeting. Action: (Rob) Start a list discussion on use of BUNDLE with CLUE. Latent Configurations (draft-groves-clue-latent-config) ------------------------------------------------------ Summary: Needs further discussion Action: (Christian) Start a discussion on the mailing list to determine if there is interest in adding this. (Chairs) allow 2 weeks for discussion/closure. CLUE Channel (draft-holmberg-clue-datachannel): ------------------------------------------------ Consensus: Use DCEP to establish the clue channel. Decision: working assumption that there will be a single clue data channel between a pair of endpoints Decision: working assumption that the SDP offerer sends the DCEP message to create the clue channel. Action: (Christer) Update draft to reflect these decisions Action: (Chairs) Make call for WG adoption of the draft after the meeting. Framework (draft-ietf-clue-framework): -------------------------------------- Action: (Roberta & Christian) Lead a list discussion of relationship between max-captures and switched/composed. Consensus: No changes required for 'Active Capture' issue. Action: (Chairs) Tickets 10, 19, 26, 32, 33 to be closed Data Model (draft-ietf-clue-data-model-schema): ------------------------------------------------ Decision: Some agreement that the element in the data model should be in a separate field in the advertisement. Action: Needs further mailing list discussion. Issue: Open issue with regards to linking the participant information with the participant type. Action: (Chairs) Open a ticket. CLUE Protocol (draft-presta-clue-protocol): ----------------- Action: (Simon/Roberta) Update the document to match the latest version of the data model. Action: (chairs) Once document is updated, call for adoption as WG document. RTP impacts and news --------------------- Action: (Roni/Jonathan) change the document title to 'RTP usage' and update the text to address the RTP aspects for CLUE, including multiplexing of RTP streams. Action: (Roni/Jonathan) Simulcast - need to document how CLUE works (or not) with draft-westerlund-avtcore-rtp-simulcast Action: (chairs) Open issue in tracker with regards to the former. Way Forward: ----------- - Continue with regular design team meetings to progress the solution details. - Schedule an interim late May timeframe ========================= Wednesday, Mo Zanaty ========================== Chair slides (Mary Barnes, Paul Kyzivat): http://www.ietf.org/proceedings/89/slides/slides-89-clue-4.pptx Slide 5: Status of documents Mary: Requirements and use case docs are in the RFC editor’s queue. Framework almost done. Restarting weekly design team meetings after IETF. Tracking dependencies in other groups. Roni Even: RTP usage depends on App ID discussions tomorrow. Clue and SDP signaling (Rob Hansen): http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ http://www.ietf.org/proceedings/89/slides/slides-89-clue-3.pptx Slide 5: Non-CLUE data channels Christian Groves: Example shows clue can control m=video lines but not m=audio lines? Rob: Yes, but should not be limited to just different media types, need to clarify it is more general for any media lines. Keith Drage: MCU with non-clue inputs will have to make up clue info for them? Rob: Yes, mixer would need to make up clue info for non-clue participants. Slide 6: Changing CLUE status mid-call Christian: Sending a reset on a SCTP stream, is that the same as removing the data channel? Rob: No, the call is still clue if the SDP negotiates a data channel, even if something happens in-band on that channel. Christer: As long as SDP negotiates a clue channel, we are in clue mode. Mark Duckworth: If an SDP offer/answer cycle removes or shuts off the clue control channel, must that SDP also remove the clue controlled m lines? Rob: No, but the clue controlled m lines must stop media if the clue control channel is removed. Example scenario is a B2BUA doing call transfer via reinvites but hide the refer or replaces from one side so they go from talking to a clue peer to a non-clue one. Roni: Do you have to set the port to zero on all clue media lines? Rob: No need to mark inactive or zero the port, just can’t send clue-controlled media without the clue channel. Jonathan Lennox: Two cases. One case is If you send an updated offer removing the clue channel and group, that means the m lines are no longer clue controlled media. Another case is an answer which accepts all m lines but closes the clue channel, because it doesn’t understand clue or the group semantics, then the clue side stops media but the non-clue side sends and expects media. Rob: If you get a reinvite that stops doing clue, you must reinvite to close all your media channels. Roni: Can we close the clue channel but keep the media flowing without clue control? Rob: Dangerous since the peer may want to control the media via clue channel. Christer: Removing the clue channel moves back to normal non-clue mode. Paul: Both the clue channel and group indicate cluefulness. We should pick one not both to indicate cluefulness. The group seems like the important one. Rob: Having both the channel and group allows multiple clue groups with separate control channels. Not sure if that is a realistic case. Channel is the key thing which defines a clue call. Roni: Always need the group? Rob: Yes. Simon Romano: Not necessary to tear down media when no clue channel. Rob: You can still do what you want, since the recommendations are mostly SHOULD not MUST. Mary: Don’t like lots of SHOULDs, consider conditional MUSTs to make things more deterministic. Paul: Clue group with a lost channel should still be clue controlled media. The group is the key clue indicator. Rob: Don’t see any problem with making the group the clue indicator. Christian: Treat clue like a metadata protocol. Removing the metadata like groups or channels just stops making assertions about the media. Rob: Disagree, you are changing assertions about the media. Paul: Clue controlled media that has not been configured does not seem useful. Simon: Something in the SDP indicates clue. Media path can survive clue channel failure, since the channel has been mostly reduced to spatial metadata while SDP conveys most media configuration. Mary: All the SDP extensions can be used without doing clue. Rob: A new offer which removes clue indicators means new media. Keith: SDP conveys state at this instant, not relative to its previous state. Removing clue indicators means at this moment I don’t do clue. Mary: Would like to call for adopting the draft as a workgroup item after the meeting. Latent configurations (Christian Groves): http://datatracker.ietf.org/doc/draft-groves-clue-latent-config/ http://www.ietf.org/proceedings/89/slides/slides-89-clue-1.ppt Slide 8: Latent Configuration issues: behavior needs clarification Mary: Does mmusic document need changes? Or clarify in clue docs? Christian: Clarify in clue docs. Rob: The question is resource cost of port allocation. How many will deploy this without bundling? Presented as simpler but not really. Capneg is complex logic although SDP may appear simpler. Christian: Yes, you must support this extra framework to simplify the SDP. Roni: Tradeoff is between simplicity (and verbosity) of processing multiple m= lines versus simplicity (and brevity) of SDP body. Rob: Larger SDP is simpler than capneg. Christer: Intermediaries may not understand extensions when reserving resources. Roni: Like adding new m= lines later in the call. Suhas: Capneg is complex, especially with the impact of bundling/multiplexing. Mary: Continue investigating or is this a bad idea? Christer: Continue investigating, not a bad idea. Doubts bundling will be prevalent for telepresence. Paul: Even if interested in this, do we need it now or can we defer it? Roni: Capneg is nice but implementations have not caught up. Christer: Need to consider RTCWEB interop. Data channel (Christer Holmberg): http://datatracker.ietf.org/doc/draft-holmberg-clue-datachannel/ http://www.ietf.org/proceedings/89/slides/slides-89-clue-2.pptx Slide 8: Proposal: Adopt DCEP for CLUE Rob: Framework already says data channel required. Roni: Why do you need a data channel identifier? Christer: Good to know earlier in SDP that clue channel is supported. Keith: What do you mean by later? Clue phase 2? Christer: We can do clue without draft-ejzak dependency. At least use DCEP, maybe add draft-ejzak later. Paul: Even if we do draft-ejzak later, we still do DCEP now. Christian: Grouping indicator is just a grouping semantic, not for presence of a channel. Christer: We will have some indicator. Media feature tags or option tags are just examples. Other indicators are possible. Simon: Can you use latent configs? Christer: Many ways possible in SIP. Agree on core concept first. Mary: Consensus to use DCEP. Revisit if draft-ejzak is ready in our timeline. Christer: Based on decision to use DCEP, some more things need to be specified like who opens the channel (offerer, DTLS client, etc.). Framework (Mark Duckworth): http://datatracker.ietf.org/doc/draft-ietf-clue-framework/ http://www.ietf.org/proceedings/89/slides/slides-89-clue-0.pptx Slide 3: MCC attributes: max-captures Jonathan: What does “=“ mean? Rob: Max? Jonathan: What is the difference between “<=“ vs “=“? Christian: “=“ means exactly that number always. Jonathan: Makes sense for a room wide-angle view but not MCU. Paul: Draft text must be updated to clarify this. Slide 3: MCC attributes: switched and composed Jonathan: Distinction between static composed vs dynamic composed is useful. Not necessarily using switched/composed attributes, but in some way. Roberta Presta: Need to define precisely what switched vs composed means. There are MCCs which can be both switched and composed. Mark: Does max-captures>1 imply composed? Christian: Agree with Roberta. Interaction was not defined, but needs to be. Accepts action to propose text. Roberta: Max-captures>1 does not imply composed. Consumer can always request 1 capture within any MCC. Paul: One extreme is 1 MCC. Other extreme is defining the entire layout. Need to find the point that has enough between those extremes. Mary: Take this up on the list, led by Roberta and Christian. Slide 4: Global Capture Entry List Slide 11: Global Capture Entry List: Advertisement Rob: We need to be clear on what a global capture scene entry is, like we are explicit on capture scene entries. Mark: We’re not completely explicit on capture scene entries. It’s up to a provider to decide what a scene is. Christian: Are these all the same scene? Mark: No, 3 different scenes. Christian: Could you use CSE ids instead of individual captures? Mark: Should the global CSE reference CSEs rather than captures? Christian: Yes, that seems simpler. Mark: Consumer can choose any captures from a CSE. Jonathan: Seems strange to say "Here is a complete view of the conference, but not of this scene.” The global CSE should be a list of CSEs not captures. Paul: This is fundamentally subjective. Roberta: Discuss this later on Friday. Mark: The workgroup is interested in the global capture entry list, but it needs some clarity. Mary: We will revisit this on Friday, with Simon covering for Roberta. Slides 12-14: active capture proposal and open tickets deferred to Friday. Data model (Roberta Presta): http://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ http://www.ietf.org/proceedings/89/slides/slides-89-clue-5.pdf Slide 6: Participant info & type: proposal: 1. vcard, 2. type, 3. Christian: 1 is a good option. Is 2 worse? Is it a real issue? Jonathan: Do you put a participant field in a content capture? Seems strange to have the same thing mean this is a picture of me, and this is a picture of my slide deck. Mark: Is Jonathan asking for semantic rules about how capture attributes can be used together or not? Jonthan: Participant needs to be more clearly defined in the framework, beyond roles. Almost seems like roster which is not in charter. Mark: I thought the intent of participant in xml was just syntax to avoid repetition. But Jonathan implies higher level semantics. Jonathan: Once you have vcard, you have the person’s name not just roles. Mary: Defer discussion to Friday. ========================= Friday, Rob Hansen ========================== IETF89 London CLUE session 2014/03/07 09:00-11:30 Notes by Robert Hansen Session opened with an agenda bash - no objections were raised. Roni Evans presented on RTP usage and the RTP mapping work going on in other groups. He summarised some avtcore documents with guidance on multiplexing, and pointed out that CLUe document authors relevant to draft-ietf-avtcore-rtp-topologies-update and draft-ietf-avtext-rtp-grouping-taxonomy should review their documents and these documents to align terminology and assure the taxonomy includes all relevant scenarios. There was discussion of whether BUNDLE should be mandatory to support or mandatory to use. Jonathon Lennox pointed out that the disaggregated media cases mean that BUNDLE cannot be made mandatory to CLUE. He also pointed out that telepresence scenarios may pose particular challenges to BUNDLE (such as partial disaggregated systems with three aggregated devices). Mary Barnes suggested that concrete examples and evaluation of BUNDLE with CLUE scenarios are needed. Robert Hansen will start that effort and post to the list for people to analyse and correct. Roni also pointed to draft-ietf-mmusic-sdp-mux-attributes as something that needs to be analysed when BUNDLE is used. draft-even-mmusic-application-token was also brought up as a good candidate for the receive id needed as a stream correlator for BUNDLE, though Roni and Jonathon will make changes to the document to make clear which component can be used as this correlator. They also discussed how their items would be renamed. There was some discussion of simulcast, and the fact that simulcast can be done in CLUE 'over the top' (without the SDP or RTP knowing the encodings were of the same capture); until a way of doing simulcast in SDP and RTP in a generic way we will not make a determination of whether this should be forbidden. There was clarification of the terminology of various aspects, and the acknowledgement that the current terms are not always clear. Roni and Jonathon will change the document title to 'RTP usage' and update the text to address the RTP aspects for CLUE, including multiplexing of RTP streams. Simon Romano presented on the CLUE protocol and an initial CLUE implementation on the RTCweb data channel. Simon explained that they are working to ensure the protocol used matches the one currently defined - the current demo uses encodings in CLUE, but work is ongoing to move the encoding information to the SDP. However, changing the SDP using the webRTC api is currently difficult. Simon then went through some of the messages being sent - Christian Groves clarified that the code is doing all the messaging defined (such as versioning), but only the most relevant messages were being shown. There was some discussion about usage of the webRTC api, such as the practicalities of changing the resolution of cameras mid-call and the practicalities of manipulating the SDP. Mary and Paul raised the issue of how much of a challenge RTCweb would raise. Paul mentioned that there will later be a lower-level webRTC api that will be more suitable for this sort of manipulation, but until that is available there will continue to be challenges. Christer Holmberg presented on the data channel - on Wednesday the decision was made to use the DCEP in-band mechanism, but now decision are needed about whether CLUE should use one or two data channels, and if the former which client should make the connection. There was discussion of the single channel and double channel. There was no consensus on this issue - if H323 adopts H245 as the channel then the single channel approach is more suitable. The decision was made to adopt the single channel approach as the working assumption for the time being. On the decision on who sends the initiating message the DTLs options were rejected on the grounds that RTCweb devices do not have access to this information. Robert Hansen raised the issue with the SDP offerer approach that there are B2BUAs that establish offer-offer calls - nevertheless, for the time being the working assumption will be that the SDP offerer sends the DCEP message. Mark Duckworth next presented on the 'Active Capture' issue - when receiving three video streams and a mono audio streams associated with one of those streams it wants to know which video stream is currently associated with the audio stream. After some discussion, Mark's proposal that the MCU subscribes to both sets of views was agreed to be the correct approach, which means no extra action needs to be taken. Mark then raised some open tickets, most of which can now be closed. With the exception of ticket #35 (consistency with data model), all can now be closed. There was a discussion on how the MMUSIC work on simulcast will affect CLUE, and the fact that CLUE also implicitly supports simulcast. At present the hope is that the generic simulcast approach will mesh well with CLUE (and without needing CLUE to do anything extra). The plan is to keep an eye on that work as it progresses. CLUE design team calls will restart on the 25th March. There will be a face to face interim meeting planned for May 29th-30th, hosted by the University of Naples. ========================= Friday, Christian Groves========================= Roni presented AVT core and MMusic status. http://www.ietf.org/proceedings/89/slides/slides-89-clue-8.ppt Drafts : • draft-ietf-avtcore-multi-media-rtp-session • draft-ietf-avtcore-multiplex-guidelines • draft-ietf-avtcore-rtp-multi-streams • draft-ietf-avtcore-rtp-multi-stream-optimisation CLUE implementers would need to understand these drafts. • draft-ietf-avtext-rtp-grouping-taxonomy Should be reviewed by people working with CLUE. BUNDLE Status Presented. CLUE may want to use this. Chair: do we want to require the support of bundle? Jonathon: you don’t want to require the use of bundle. Christer: shouldn’t be required to implement. Jonathon: Does BUNDLE work in all cases? i.e. disaggregated media. General discussion on how BUNDLE should be documented in the CLUE signalling document. Agreed to look at different BUNDLE scenarios. draft-ietf-mmusic-sdp-mux-attributes. Needed for multiplexing characteristics. draft-even-mmusic-application-token. Some part necessary for bundle. CLUE RTP mapping: proposing to use AppId for CLUE encoding ID. Generally discussion around what is needed. Need to work towards CLUE->SDP->RTP mapping. Need to go through taxonomy to make sure this aligns. Agreed to change the title as proposed. Simon Presented CLUE implementation http://www.ietf.org/proceedings/89/slides/slides-89-clue-7.pdf CLUE protocol over Webrtc data channel: running code trials Presented a complete WebRTC call flow. Using a Webrtc datachannel to exchange CLUE messages. Showed a WEBRTC demo. Does contain some obsolete elements, i.e. encodings in CLUE instead of SDP. Currently trying to implement CLUE SDP encodings via the WebRTC aPI but tricky. Relies on the Chrome browsers as it implements user constraints. The demo includes all messages in the protocol document. Whenever the producer gets a configure message and needs to set up media the browser must ask for user interaction, i.e. getusermedia. Not ideal, needs to be discussed in W3C. Applications need to be able modify SDP after being received from the RTCWeb API, i.e. for appid, clue label, etc. Concerns that Webrtc is using bi-directional channels, however CLUE is single unidirectional channels. Christer Holmberg Episode 2 Opening of the data channel. http://www.ietf.org/proceedings/89/slides/slides-89-clue-6.pptx Proposal to have one channel? The main issue is whether there will be transport in the future that only needs a single channel. It was questioned whether only having a single data channel would cause congestion issues. People thought it wasn’t an issue due to SCTP Ndata handling head of line blocking. It was mentioned that we need to consider that the decision will have an impact for carrying CLUE in H.323. Nobody had strong objections to either of the proposals on slide 8. The working assumption is a single data channel (Alt.2). On slide 9 the working assumption is that the SDP Offerer sends DARA_CHANNEL_OPEN (Alt1). It was put forward to accept draft-holmberg-clue-datachannel-03 as a working group document. Mark Duckworth 2nd part framework open issues (starting slide 12) http://www.ietf.org/proceedings/89/slides/slides-89-clue-0.pptx Issue need “active capture” info. Slide 12 – Comment: Preference not to have it in CLUE channel as it brings real time requirements to CLUE. Could be RTP and MCC. Question: is there a need a method to request active speaker information? People didn’t thing so. Slide 13 – optimisations will be dependent on how the media correlator is defined (i.e. AppID). Could potentially have multiple AppIDs per packet in the example. Optimization would be a “may” rather than must. General support for the approach in the slide. An example will be added to the draft. The optimization is a separate topic and is broader. Any other business -------------------- How does RTP simulcast and CLUE go together? This needs to be looked at further. A ticket will be opened on the issue.