IETF CLUE WG Interim meeting, May 21, 2013 Participants: ------------ Mary Barnes Paul Kyzivat Mark Duckworth Andy Pepperell Christer Holmberg Christian Groves Cullen Jennings Dan Romascanu Gonzalo Camarillo Jonathan Lennox Keith Drage Richard Ejzak Rob Hansen Roberta Presta Roni Even Scott Pennock Simon Romano Stephan Wenger Stephane Cazeaux Recording: ------------ https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=12686922&rKey=e4198e7067d82c36 Notes by: Mary, Roni, Andy, and Paul -------- Summary: --------- The objective of the meeting was to review the updates and open issues around the framework and focus on the signaling solution Framework: - Roles: Christian has an outstanding action to post a document evaluating the various options that were discussed on the mailing list. Action: Christian submit the document no later than May 28, 2013. Action: Chairs open an issue to track this one. - Switched Capture: Currently unclear in the framework. Folks are working on text around this in the form of drafts. Action: These drafts must be submitted no later than June 14, 2013 to ensure there is discussion prior to Berlin. Discussion on the principles can also be discussed on the mailing list, but would be most helpful in the context of the drafts. - Security: Needs to be based on what is outlined in requirements. Definitely need to address threats and potential security issues with regards to information sent over CLUE channel. Action: Mark with Mary (who is doing the security aspects based on the requirements) to put this together. - Issue #20 (Rejecting configure). This needs to be mentioned in the framework as a possibility, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. Action: chairs update the issue in the tracker. - Issue #22 (stale Advertisement). This appears to be around a race condition and it should be addressed in the solution. Action: Chairs to change the issue to the signaling doc. - Issue around partial advertisement (#25). General sense that this is a solution issue. However, Christian doesn't necessarily agree. Action: Christian/Roni figure out if and where this should be addressed in FW. Signaling/solution: - Action: Rob to fold the concepts (and feedback thereon) presented into draft-kyzivat-clue-signaling Way Forward: - Actions above to be addressed. - Schedule another virtual interim 4-5 weeks out. Roni's notes: ------------- Notewell Framework – Mark Duckworth Recent changes Switched Capture discussion. Paul – what is site switch. It is not specified enough in the framework. Mark – agree that it is not clear. Where does site switch defined CSE, MC. Christer – let people think about it and come with proposals in Berin Christian – we are working on this issues. Mary discuss site switch on the mailing list. Mark – there may be two draft (Mark, Christian) Roni: is site switch needed for consumer to select policy. Christer: provide a basic one (voice activated and other user defined) Jonathan : we need to have a definition what a site is. Christer: why call it site switch and not switch or scene switch. Mary: we cannot conclude and there will be drafts and mailing list discussion. It need resolution. Christer: please take into account that July people will be on vacation Mary will write the security consideration. Ticket #20 – is it in the framework? Mary. Ticket #22 – the configure reference an out of date advertisement. A solution thing Ticket #25 – is also a solution so for the signaling. SIP/CLUE call flow – Rob No specific order for CLUE and SIP CLUE reference SDP labels Jonathan – no SDP to CLUE reference – not even for which MC is controlled by SDP. Rob: the labels in SDP are just labels, no semantics. Rob : when you receive an SDP with n m-lines and you do not know yet if you use them you can either accept them since it CLUE or reject and do an O/A later. Rob: trying not to use any new SDP attributes Jonathan: if I accept this m-line will I get media now or only when I get config, reuire that this m-line will indicate if it is controlled by clue Jonathan: no reason to overload the semantics of “labe” to say that this m-line is controlled by CLUE Jonathan : whose side labels are used Rob: next step put the comments in an update version. Andy's Notes: ------------- Introduction from Mary. MarkD: Overview: Going to go over recent changes arising from Orlando Slides for 5 minutes then discussion Refactoring from Orlando: syntax-like notation moved out of the framework and left to the data model. Lots of questions about switched captures over the e-mail list over the last couple of years. Have been previous drafts but put on hold pending more important things - would now like to continue that discussion. Still open tickets on this. Paul: Roni, Christian and I have been having some discussions off line about switching. Reading the documents themselves meant they came to 3 different ideas about what was being explained - need more clarification about the scope and nature of the attributes being described / proposed. e.g. if the capture scene. Roni: if I have a presentation and I have a room view that's switched, the presentation shouldn't be switched - so can't be capture scene entry Christer: Roni, presentation and room should be in different CSEs Roni: depends where you put that attribute - is it a scene attribute or a call attribute? Christer: would it help to make it per capture - isn't that the most flexible? Mark: the idea of making the attribute on a CSE then it would apply to all the captures, so it was a way to enforce the same attribute consistently across all captures in the CSE Christer: if they're in different CSEs then that solves this Jonathan: this forces implementers to handle this case if they receive it. if you have a CSE and a capture in multiple CSEs, what attribute does it have - do the CSEs have to be consistent for captures that end up in multiple CSEs. MarkD: good question, and not currently in the framework MarkD: I've heard proposals to make it illegal for a capture to be in multiple CSEs Christer: need a proposal and see if it works for people - difficult to make this up on the fly Christian: language should be addressed - rather than site or segment switching but need to choose language that works in conjunction with the framework terms Mary: when do you anticipate this draft appearing? Christian: depends on Paul and Roni Roni: hopefully in the next couple of days to make some additions Paul: we're having difficulty agreeing with each other so don't want to inflict that on the rest of you at this stage! Roni: one of the issues is that in the use cases when it talks about site switches it describes an application scenario. I think we can try to narrow this - with site switch if we narrow the scope to the application - the objective should be to keep the "being there" experience when switching through the MCU by providing all the information needed to do it like in a P2P call. You want to show people in the correct size etc. Christer: if the 3 of you don't mind I'd like to be included in these discussions too Mary: if we could have the discussions on the mailing list that would be good Mark: sounds like everyone agrees we should spend more time on this in the group Christian: I think there are a few interaction issues here Mark: I was thinking I would do a "half-baked draft" in an e-mail discussion, and try to have a few revisions before the next meeting Mary: 7 / 8 weeks to the draft cut off - could you guys try to get those on the list in the next 3 weeks so they can be discussed before Berlin? Roni: a question of how much information we need to provide in order to allow full control by the consumer Christer: if the MCU supplies you a site switched view and provides you with information on who is the active speaker Christian: so we want to provide enough information Christer: what I'm saying that the MCU says I can give you site switched and tell you who's the active speaker, or you can tell me the speaker you want Roni: we kept site switching as a boolean to not decide any piolicy - up to the provider to decide this Christian: we should be talking about CSEs and captures rather than attributes. For now we assume the switched attribute is boolean. MarkD: my understanding of the switched attribute is that we made a firm decision within the group on that being a boolean, but that doesn't mean there aren't further attributes to be defined. As an example we later came up with the policy attribute - so you can have multiple attributes that work together Christer: I agree Roni: we're trying to figure out what we want to specify, in relation to the original source, the MCU and the final consumer Paul: Christer mentioned earlier that site switched only applied in the MCU case, not P2P. From the point of view if our protocol there's no visibility of that information. If I'm a room connected to a far end system I don't know what the other side is - there's no explicit indication of the far end being an endpoint or and MCU. [AP]: seems slightly wrong to me for us to try to read anything in to the far end site type - e.g. perhaps a plain "endpoint" would still be able to offer various switched options even though it wasn't an MCU? Roni: In SIP you can put "in focus" to indicate you're talking to an MCU Mark: I agree with Christer about it not applying to P2P - in CLUE that manifests itself as a provider not advertising having a site switched attribute in what it advertises Jonathan: once we have some semantics on what a "site" means then the rest may fall out Christer: why do we need "site" rather than just a switched attribute. The CSE is one way of representing a scene which is always represented; why do we need this at all? Christer: why can't we change the name and call it scene switched? [AP]: as I understand it, "site switched" means you see complete far end sites (or perhaps, complete far end sites' capture scenes) in a capture scene sent to you (as the consumer), whereas "segment switched" allows the provider to send a partial set of captures (e.g. the left most segment of a 3 camera view). "scene switched", if we decided to adopt this term, to me would have meaning mostly as a synonym for "site switched" Mark: Open issues: need to work on updating example section. Need to revisit video encode capability (currently H.264 focussed, but might want more controls over which streams can be provided at high frame rate and others not etc,). Maybe we can make more use of what's available in SDP already? Mary: no IANA considerations - security: need to work on requirements document for security Jonathan: do we think that Telepresence has security considerations above what videoconferencing has? Mary: not necessarily, but we need to describe requirements Paul: at the very least the CLUE channel is a new element that needs to have its own security considerations Mark: people's roles etc. spatial information might be sensitive, so need to think about a secure way of transporting this information Mark: Open Tickets... #20 rejecting configure - do we need this? (action for Andy) Mary to work on this #22 - out of data advertisements - what is an out of date advertisements Paul: an advertisement wouldn't be out of date per se, but the configure that references it might be #25 - is advertisement all or delta? Christian: for the signalling, need to understand more on when an advertisement would be sent Rob's presentation: Rob: this follows on from Orlando, and takes forward some of the design meeting decisions. Key points / ideas: - No ordering enforced between SIP and CLUE - CLUE refers to SDP (labels) but no reference in the other direction, i.e. nothing in the SDP needs to make references to what's transported in the CLUE channel - No new SDP syntax - BUNDLE not used here Jonathan: no SDP -> CLUE references - would you need something to indicate which m lines are controlled by CLUE? Rob: yes, but you don't need to parse the CLUE to understand the SDP. Labels already exist in SDP Paul: this needs a bit of a leap of faith - you could get an offer with a bunch of streams ("m line"s?) - you don't know what they're for yet and so you might reject them. When you get an advertisement that references the labels and only then do you know you want the, Depending on the ordering you might take the leap of faith and accept them all at the start, or you might reject and then try to get them back later. Other schemes have their complications too though, and this isn't necessarily any worse than those. Jonathan: I think that leap of faith is relatively safe if you know those m lines are controlled by CLUE Rob: I'm not suggesting that in the initial INVITE we put all the m lines in - this scheme needs rather a lot of reINVITEs Paul: none of these slides show any m lines for the CLUE channel Rob: The "Initial INVITE" should have the CLUE channel in it and the far end should zero it out if it doesn't understand it, as it would any other such m line (there is a feature tag though in the header) Paul: are you saying that the m lines in the initial INVITE should never be used for real audio and video? Rob: I think you should be able to start sending media using the initial m lines if you want to (e.g. to get audio up and running early in the call) Rob: slide 4 shows second Offer, with 4 video m lines including the original one (3 additional sendonly, each labelled with "clue:") Paul: why aren't they "sendrecv"? Rob: the problem is the labels are used, and the labels are easier to use with sendonly and recvonly I tried not to do anything too complicated with the SDP - I hope we'll end up with being able to use a single port eventually Christian: why use a label rather than a new attribute? Rob: I tried to do this without any new signalling (we may need some for multiplexing) but wanted to use something existing, rather than a CLUE specific media attribute. To use this in real life I think we'll need some amount of new SDP syntax Paul: hopefully what'll we'll need new will come out of the BUNDLE - if we need something new in the SDP we can propose it but if possible we should use what's there - e.g. labels, which are for this purpose Rob: labels were designed for this Jonathan: we would have information saying that "this m line is controlled by the CLUE channel" in the SDP Rob: we could try to group the m lines and have a "CLUE group". BFCP uses "mid" as well as a label. Rob: Slide 5: encoding groups should be in SDP, but couldn't figure out a good way to do this Roni: the advertisement you have for deciding the video codec are receive parameters Rob: there are implications for the video parameters depending on whether m lines are recvonly, sendonly or sendrecv Roni: yes, on the previous slide, "max-mbps" is not allowed in the sendonly case, for instance Rob: agreed Rob: Slide 6: Bob's advertisement to Alice: includes labels not yet included in his SDP - you need both SDP and CLUE to have complete meaningful information Rob: Slide 7: SDP answer includes recvonly Paul: why do you need to put a label on the recvonly in the answer that corresponds to the sendonly in the offer - they're already matched up? Rob: I take Paul's point - the labels should only be needed on the sendonly streams - but they have a use here to signal that these m lines are controlled by CLUE. You should be able to reference the sendonly labels here. Bob would then know which m lines were being referred to here. Paul: you mean for the labels to have meaning here rather than just "this is controlled by CLUE"? Rob: the grouping mechanism is maybe better here - label here is being used for 2 purposes, signalling that the m line is controlled by CLUE, and also identifying which encoding is to be used Paul: I think you could have multiple labels Jonathan: I think we shouldn't overload the label - we need to decide though whose labels go in the configure. I don't think we need to "save labels" as an optimization. Rob: it makes sense to use the same labels, with the consumer's configure always using the provider's labels Rob: Slide 10 / 11: Bob adds sendonly m lines in a third offer, which then gets answered. You could drop the initial sendrecv at this point, but I don't think you'd need to, and might give extra in-call options to keep it. Jonathan: could maybe make it "inactive" Roni: you have to keep RTCP alive for it too Paul: this does consume resources, so would be worth getting rid of if we can Rob: Summary slide: nothing in the negotiation about who does INVITEs first, so glare may happen a lot Paul: there's no issue resolving glare, but the issue is that it's time consuming Paul's Notes: ------------- Framework (Mark): I brought up question about the meaning of site-switching. My interpretation seems to be in the minority. Jonathan asked: if a capture is in more than one CSE, can it be site-switched on one and not on another. (This is a good question!) We want more discussion of this on the list. Mark proposes to make a new draft on the subject, and Christian also does. They want us Huawei people to more our discussions into the public. Roni brought up question about the switching policy. Need more discussion on this. Christer wants us to solve this before Berlin. Mary asked that any drafts be submitted no more the 4 weeks from now. Signaling (Rob): Jonathan asks about references from SDP to clue. Answer: only labels that are referenced from clue. Rob says assumes that the clue channel will be offered in the first offer. Jonathan wants something in the SDP that says “this m-line controlled by clue”. He wants it as a guarantee that nothing will be sent to it until it is configured. Rob explained one reason for using sendonly m-lines is that it means the attributes then describe what can be sent rather than what can be received.