CLUE WG @ IETF 85 ============================================ Date(s): Monday, Nov 5, 2012, 9:00-11:30, Tuesday, Nov 6, 2012, 13:00-15:00 Location: Atlanta, GA, USA Chairs: Mary Barnes, Paul Kyzivat Note Takers: - Session 1: Andrew Hutton, Jean Mahoney - Session 2: Jean Mahoney, Charles Eckel Meetecho recording: - Session 1: http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions#IETF85_CLUE_PARTI - Session 2: http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions#IETF85_CLUE_SESSION_II Summary ======= Discussion Summary/Conclusions: -------------------------------- - Framework: Document will be re-factored to provide an overview of the solution and split solution details into relevant documents - Data model: Consensus that the data model isn't a representation of a message instance. It is the information needed by the telepresence application but elements in the data model would be signaled in different messages as appropriate - e.g., CLUE specific signaling and SDP. - RTP Mapping: Overlap with work in RTCWEB highlighted. Details remain to be worked out - should be worked with RTCWEB and AVT folks to ensure consistent/common solutions. - CLUE & SDP: draft-even-clue-sdp-clue-relation is a good starting point for describing the signaling solution. Agreement that CLUE signaling must be consistent with initial O/A. Needs more detail based on WG consensus (TBD) for basic signaling model. - Call Flows: Gets to the crux of the CLUE signaling issues in terms of how much is in SDP in first O/A exchange. This discussion highlighted the overlap between some of what RTCWEB is doing. - draft-groves-clue-capture-attr: More comments are required for this draft/topic. (note: relates to Issue #10). Action Items: ------------- - Update milestones (chairs) - Team to work out RTP/SDP usage for multi-stream considering RTCWEB, AVT and MMUSIC work items. (Jonathan, Roni, Justin, Colin, ) - Updated/new documents for new WG deliverables (1st name is prime for small design team): -- Re-factor Framework document (Stephan - with Andy and Mark) -- CLUE & SDP signaling document: Rob Hansen, Roni Even, Simon Pietro-Romano, Roberta Presta, Christer Holmberg (using material from draft-even-sdp-clue-relation & draft-romanow-clue-call-flow) -- RTP mapping and usage: Roni, Jonathan Lennox (based on draft-even-clue-rtp-mapping and pulling reqs, etc. from draft-lennox-clue-rtp-usage) -- Data model: Roberta, Simon, Christian Hoene (based on draft-presta-clue-data-model-schema incorporating textual descriptions from draft-romanow-clue-data-model + relevant material from FW) -- Call flows: Lorenzo Miniero, Simon, Rob, Roni Detailed minutes ================= [[ Andrew Hutton notes for Monday Nov 5 ]] Chairs Presentation =================== Status - Objectives- Agenda - Bernard Aboba - RTP Usage - would be a good idea to have something to talk about with RTCWEB people much earlier than March 2013 which seems a bit late., Gonzallo - RTP Usage should be a top priority to enable co-ordination with RTCWEB Roni - Assume that everybody is going to use the results of the AVTCORE work. Framework - Andy Pepperal's slides ==================================== Capture Encoding - No comments Simulcast concerns - No comments Maximum capture encodings - Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean. Rob Hanson - Not so convinced that this is a problem we need to solve in clue (sorry some missing). Roni - Can agree with the previous speaker that does not need to be solved in clue. Rob Hanson - !!Missed some stuff J.Lennox - Depends on association of SSRC's to mappings. Sorry missed some stuff Mary - Seems that this has been discussed previously. Point on Line of Capture - No comments Draft-presta-clue-data-model-schema-02 ======================================== Overview - No comments Capture Scene Type Roni - scene entry is from 1 not zero. Scene Entry Type No comments Media capture type & spatial info type. No comments Audio Capture Type Example. No comments A simple video capture No comments A simple video capture example No comments A more complex capture No comments PiP Video Example - #1 #2 #3 Martin Thomson - Don't use xsi:type as it is not well supported and not obvious what is meant. Roni - Nothing to tell you that this is PiP tells it is composed from number of captures but does not say anything on layout. Paul K - Point is that more discussion is needed there is not enough so far. Now is the time to argue about the details. Chris - look to state of the art in the computer aided design ??? Roni - Not maybe in scope to define layout (CHECK WHAT HE SAID). DRAFT-EVEN-CLUE-SDP-CLUE-RELATION-01 ===================================== Introduction - No comments Capture Attributes Paul Kyzivat - Confused when we talk about SDP are we talking about encompassing everything that the advertisement describes. Roni - Not necessarily. Paul K - Still have problem don't say how we map to m-lines. If sending offer we are picking some m-lines but which ones and how they are multiplexed may depend on config so how does this work??? Sorry missing some stuff. Paul K - Makes more sense in the initial offer/answer before it is even known that the remote party supports clue. Roni - If have content attribute in initial offer answer that is what you need to put in to clue. Mary - What is being said is that SDP and Clue have to be consistent. Paul K - Needs to be taken offline to detailed to discuss at the Mike. Christer - When sending a configuration it has to be consistent with the previous offer/answer so a new offer/answer needs to be sent before a new configuration. Encoding Parameter Christer - Assume bandwidth for each individual stream is indicated clue. Multiple m-lines per stream is not clue specific so may want to put bandwidth in SDP. Roni - SDP reflects what the bandwidth that the receiver can receiver clue is about what can send. Christer - Not really we have other drafts which talk about both send and recv. It is not as simple as saying SDP is what you receive. Thinks there is a need outside clue to specify this type of stuff. Rob Hanson - Didn't consider the configure message ... ----------- Missed some discussion here but appears that Rob agreed with Roni. J.Lennox - Cannot map everything to SSRC's anymore. C.Eckel - In SDP bandwidth is a max not a problem is you use less. Clue should stay within the limits of what is negotiated by SDP. Clue should not do more than is negotiated by SDP and then try to update SDP later. J.Lennox - ... second offer is required to update middlebox??? Observations Paul K - Did not see how CLUE and SDP is related with regard to m-lines. J.Lennox - Don't confuse multiple m-lines and multiplexing. DRAFT-EVEN-CLUE-RTP-MAPPING-04 =============================== C.Perkins - Are the sources being told by the mixer what SSRC's are going to be used or is there mapping taking place C.Eckel - it is the later. C.Perkins - Not sure the mapping of SSRC's is correct he is not clear what is going on. What appears to being discussed is the mapping behaviour of the middle box but the terminology being used is not very clear. J.Lennox - If you are sending something you make your own SSRC. Agrees the terminology is not great. J.Uberti - ??? Missed his point but seemed to be just clarification. Mapping options - SDP Overview Rob Hanson - There is a webrtc draft (msid) which has very similar syntax. B.Aboba - Given this what is the distinction. J.Uberti - This sounds like two ways of doing the same thing there could be value of trying to merge the clue and rtcweb mechanisms here which would help sync. M.Thomson - Concern that media stream in rtcweb covers both audio and video is this the same here. - There is some mismatch that needs to be sorted out. B.Aboba - Trying to relate all this. H.Alvestrand - Did but a tag in his draft so it could be expended. Not clear if the captureid's are unique per SSRC's. Roni - MediaCapture can have more than one captureID. H.Alvestrand - Seems it is a analogous to a media stream track. SDP Examples - Static mappings. J.Uberti - Is is correct is that captureid is 1:1 with SSRC. Roni - yes. ************* Missed some of this too confusing ***** Magnus, S.Romano, J.Lennox, Discussion to fast to capture. C.Perkins - RTP must be able to process the packet if the extension header is not received as it is specified for optional things which optimise but are not required. If this does not fit with CLUE then need to convince AVTCORE. Capture Attribues ================= Sorry well behind on this discussion regarding using clue in RTCWEB environment so noted abandoned. P.Kyzivat (Chair) We need help to make sure the CLUE and RTCWEB stuff matches up. CLUE needs to use SDP to establish CLUE when not in an RTCWEB environment and hopes that the same SDP can be used when the CLUE client is using RTCWEB. J.Uberti - We need a call flow of how a clue client in JavaScript using RTCWEB would work he is willing to help on this. P.Kyzivat - We don't have the clue only without RTCWEB sorted out yet. J.Uberti - Mary - We can probably get agreement that the spatial information is something that would go in CLUE and not in SDP. R.Hanson - Will volunteer to do some work in this area (i.e. what is in SDP, CLUE XML etc.). B.Aboba - Issue of captureIDs and msids is urgent and needs sorting out quickly maybe has to be in mmusic. P.Kyzivat. J.Lennox - Design constraints in SIP world might be different to the RTCWEB world with regard to SDP usage. Christer - We need a starting point. ============================================================================================================ [[ Jean Mahoney's notes for Monday Nov 5 ]] CLUE session 1: Monday, November 5th, 2012, 0900-1130 Length: 2.5 hours WG Chairs: Mary Barnes and Paul Kyzivat Agenda and WG update: ======================== 10 min Presenters: - Mary Barnes, Chair - Paul Kyzivat, Chair Note takers: - ?? Hunter - Jean Mahoney - Martin Thomson - jabber scribe Blue sheets passed out. Note well presented. Working group status slides were presented. Objectives and agendas for the meetings were presented. Current and proposed WG deliverables were presented. - current milestones are out of date - delaying updating the milestones because documents may change. Proposed Revised WG deliverables: May 2013 Use Case document (Informational) May 2013 Requirements document (Informational) May 2013 Framework (Standards Track) Oct 2013 Data Model document (Standards Track) Oct 2013 CLUE and SDP Signaling (Standards Track) Oct 2013 RTP Mapping (Standards Track) Oct 2013 Call Flows (Informational) Benard commented that the May 2013 dates seem late since the rtcweb working group is waiting on CLUE. Mary explained that the dates are IESG dates, and it would be difficult to have anything before then given the momemtum of the group. Gonzalo said the RTP mapping (?) should be top 1 or 2 priority in order to coordinate with rtcweb. Mary - this doc is the most mature of the wg documents. Framework: =================================== 20 min draft-ietf-clue-framework-07 Presenter: Andy Pepperell (remote) Slide 4 - Maximum captures encodings Roni Even wasn't sure if the "Max capture encodings" attribute was enough since it doesn't say which one is advertised and which is simulcast. Rob Hanson is not convinced that the CLUE working group should solve simulcast. Roni agreed and pointed out that there are problems with dynamic mapping, and simulcast and encodings have problems. That simulcast could not be described with SDP dynamically. Jonathan Lennox pointed out that getting rid of groups makes declaring SSRCs becomes easier. Dynamic mapping becomes easier. Paul (as chair) pointed out that the change was not in front of the working group. Mary said that the removal of encoding groups had been brought up before. Data Model: ================================== 40 min draft-presta-clue-data-model-schema-01 Presenter: Simon Pietro (for Roberta Presta) Slide - PiP video example 3 Martin Thomson recommended that XSI type not be used since it is not well supported, and it's not clear what sort of capture it is when parsing the documents. Simon said that it depends on the parser but could be discussed later. Roni wanted to know how one determines that the example was showing a picture-in-picture. Simon said that picture-in-picture couldn't be represented, and that the draft captured only what was in other CLUE documents without proposing anything new yet. Roni like the structure and the example otherwise. Chris (?) suggested that Simon look at computer graphics/CAD for ways to describe camera angles. Simon agreed and had suggested similar earlier. Mary asked if people were ok with the approach? Parts will be in the message but more of an instance. Roni said that he was ok with it. Mary - it may represent an advertisement but it is not a direct mapping to a message. Simon - an advertisement would be a wrapper around this. Mary said that there was consensus. CLUE and SDP Signaling: ====================== 40 min draft-even-clue-sdp-clue-relation-01 Presenter: Roni Even Slide - Capture Attributes Mary - I want people to understand that we agreed that we couldn't do everything in SDP. This shows what can't be carried in SDP. Roni - This shows when we need a second offer/answer. We don't want conflict between info carried between SDP and CLUE. Paul (as individual) wanted clarification about advertisement and configuration. Roni - If there's a content attribute, there should be the same as the advertisement. If content was exchanged during media capture, advertisement and configuration. Doesn't need SDP to put stuff in the stream. There's nothing similar in SDP for spatial info, though, so that doesn't need offer/answer. We need offer/answer if not mutliplexing RTP. Paul - to put my question a different way - My advertisement adds lots of captures. We don't say how we map to mlines. I pick some mlines to put in the offer/answer, and I plan to multiplex captures. But which ones will depend on configuration. How do I know which mline to put attribute on. If I'm going to multiplex, do I do multiple captures [??]. It seems speculative until you do the configuration. Roni - content in the initial SDP to provide content for cases where you don't do CLUE - these cases are limited. There is main and out, and main and presentation. In CLUE protocol, you need media capture main and media capture presentation. Paul - I understand it better in context is offer/answer, when we don't know yet if we doing CLUE. If the receiver does CLUE, then my offer/answer uses defaults. The argument about hypothetical offer/answer and config aught to line up with defaults. Roni - If you have content attribute in the offer/answer, you need it in CLUE. If don't, you don't need another offer/answer. Paul - If I find out that the other person does CLUE. Am I constrained to what I put the offer/answer? Mary - You're asking if what you send in SDP has to be consistent with CLUE. Roni - You have to advertise also in CLUE. This is a mapping issue, it doesn't have to do with CLUE itself. Paul - will take offline. Slide - Encoding Parameters 2 Christer - You assume that the bandwidth for the stream is CLUE bandwidth. Roni - yes Christer - It applies to multiple streams for inlines - bandwidth per stream. Do we want to put it in SDP? Multiple streams per mline is not CLUE specific. Roni - There's max group and max per media capture. Can distinguish [??] In SDP you have media level and [??] needs to be specified anyway. The SDP reflects what the receiver can receive. Clue is what the provider can provide. Christer - We have a proposed mechanism to advertise both receiving and sending capabilities. The ssrc attributes specify your sending capabilities. There will be a need outside CLUE to specify bandwidth. Roni - it reflects capabilities of endpoint to send info. In SDP, I'm not sure we have anything. Rob - You need to consider configuration message to select/limit encodings. Roni - This is bandwidth. You pick one encoding. Do you pick from Offer/Answer, or do you change values in encoding when you configure? You don't change values inside the encoding. Rob - what if they can do 1080p and you can't? Roni - SDP provides the limits on what you can receive. Lennox - on Christer's point, in CLUE there's a level of indirection, and you want to specify for dynamic sources. Change ssrc, but keep same constraints. May want to think in a broader context. You can't map straight to ssrcs anymore. Charles Eckel - comment on the first bullet - I don't think it would require a second offer/answer. You are saying it's a max, you can use less. CLUE should always honor the limits placed by SDP. If you learn new info for increase bandwidth - negotiate SDP first. Christer - That's what I mean. Roni - This SDP is being used by bandwidth management by network intermediaries. Charles - This is a separate problem, but that's not what SDP bandwidth parameters should be used for. Roni - some systems in the middle will use bandwidth parameters. Lennox - it doesn't require it, but it's good hygiene to let the box know to release resources. Slide - ecoding parameters 3 Roni - Rob made the point that the value may be changed by the consumer, but I'm not sure about that. Both maxwidth and maxHeight can be used – do we need to recommend using one and not the other? We have a duplication in this functionality. Slide - Observations Using RFC6236 may not work when dynamic mapping between RTP stream and Media captures is used. Problem with image attributes. Paul (as individual) How do we relate CLUE and SDP in terms of mlines? Either the sender or receiver would care about separate lines or multiplexing. Roni - I wanted to highlight the attributes and the protocols is addressing both … [??] Lennox - it's perfectly reasonable to have multiple lines that are multiplexed. Mary - this is a good starting point. RTP Mapping: ================================ 30 min draft-even-clue-rtp-mapping-03 draft-lennox-clue-rtp-usage-04 Presenter: Roni Even Slide - SSRC Behavior A commenter had questions about whether a static SSRC remapped resources and whether the sources are being told by the mixer what to use. Charles explained that the MCU isn't dictating which SSRC to use, it's a remapping. The commenter found the term static confusing since it dynamically remaps the SSRCs. Roni explained that, for a media capture, one would see the same ssrc for static and different ssrcs for dynamic. Charles provided the example of 100 participants and the MCU uses 3 streams and multiple ssrcs. 3 ssrcs will remain fixed. The dynamic one will send 100 ssrcs. Lennox clarified that it's from the receiver's viewpoint. Is the capture a single or multiple ssrc? If you send something, you make up your own ssrc. Justin verdi - What the receiver gets from middle box isn't what the sender sent. Receiver says I want capture x, and it comes in on y. Both concepts exist in all topologies. roni - in point-2-point case, you see both. from 3 camera to one monitor system can have both behavior - switch stream or different ssrc each time sent ofr this stream. Slide - Mapping Options - SDP overview Christer said that the westerlund drafts were now wg drafts. Slide - SDP examples - static mapping ?? - what' the distinction? Roni - what's the mapping? 1-1, 1-many Rob pointed out that rtcweb has remarkably similar syntax. Justin said the rtcweb media stream sounds just like a capture id. There's a generic form in rtcweb, we could fold them together. Roni - I'm ok with that. But you can't declare SSRC inside SDP, applicable to point-2-point. Justin - dynamic things need to be [??] Martin - the stream encompasses video and audio? Roni - yes, but different media capture. ?? - The source name is a string. It identifies a device like a camera. There's multiple source names for 1 cname. You didn't use source name, only capture. Roni - it was the original way we looked at it. We could use ssrc name instead of a number. ???? - Are the capture ids unique per ssrc or do they associate multiple ssrcs together? Roni clarified that there can be more than one capture id to a media capture. Slide - SDP examples - static mapping - simulcast Roni pointed out that the example doesn't match magnus's doc. Justin - there's three levels of hierarchy. Roni - for simulcast. different ssrcs but same source name. Justin - capture id is different? roni - the capture id is the whole stream. capture id is 1-1 to ssrc, but there can be more than 1 ssrc to a capture id. Justin - here they are unique. roni - a media capture can have more than one capture encoding. Justin - If I have higher or lower bandwidth, do I ask for capture id, or what do I ask for? roni - The encoding group provides max limit for encoding. When you ask for something that fits within the group and individual encoding and what you can receive. Justin - how do I ask for a capture? Roni - when you configure in CLUE as a receiver, you tell the sender the media capture and these encoding(s). You know if you can get it, because it has recognized values. The encodings have limitations. Have to choose one encoding. This is complicated. When you want to select something you have to take into account the limitations of sender. Justin - I need a visual. Slide - SDP examples - static mapping - using srcname for mapping Roni pointed out that these were separate media captures and not out of the same camera. Magnus - this is the source of the camera - can use hierarchal way of describing this - camera source, encoding variant. Simon - to answer Justin - inside we have a send entry with a number of media captures with an encoding group. A single encoding is a ssrc. 1-1 encoding identifier in CLUE to SDP. Roni - correct, but Justin asked how to specify capture. Lennox - the capture encoding is the mapping between the capture and encoding that is configured and isn't in the advertisement. The ssrc doesn't exist in the advertisement. This ssrc corresponds to capture A and encoding 1. It's not the same as the encoding. Its a cross product. Paul (as individual) - the value of the ssrc name is a name for a label for a capture encoding. Roni - yes Paul - you embedded a reference to an image addr. Roni - that's what it's used for. specified in the ssrc spec. using a separate mline, maybe we should use a bundle to be consistent with magnus docs. haven't had time. Paul - adapt the use of ssrc in context in CLUE to specify capture encoding. Slide - Proposal Collin - just a reminder that the rtp extensions - you have to deal with the case of the header extension being stripped. The spec says that you must be able to process the,m but you can't depend on it - the header extensions are only for optional optimizations. Mary - lot of details to work out. Tuesday Plans: =============================== 10 min Presenters: Chairs Mary - would be helpful to go through a call flow. Many issues in the issue tracker. Justin - there are certain things that can't be expressed in SDP. Why? We're running into the same thing in rtcweb. How do we pass info into rtcweb? Mary - not a simple answer and not decided. This is Roni's presentation. Roni - what we agreed on - the CLUE info will use a data channel. It doesn't prevent rtcweb from using SDP. Justin - rtcweb isn't going to inspect the data channel. Some is in SDP, some in XML. Has implications on rtcweb. Christer - Roni and I suggested that we could assume that we would send only spatial info in CLUE. It's a starting point. I want a decision. Mary - I don't' think we have enough detail. Christer - we can agree on a working assumption. Mary - we need contributions that have details on that assumption. Not sure it's going to work. Bernard - I have a computer with 3 screens and 3 monitor and a browser. Everything that I need to specify for the browser in SDP. In my app I can adjust the number of screens. How do I tell the browsers. Lennox - from rtcweb point of view to generate this info. How you build the camera API, not SDP. On the receiver side, it tells you where the screens are - doesn't need to hit SDP. I could encode these subsets. Doesn't make sense to put in SDP, not sure what it would it look like in rtcweb context. paul (as individual) - what we're calling capture encoding needs to map onto an browser API, I hope there is one. (As chair) We need help. Do I hear volunteers? We're talking about SDPp (?) to work with rtcweb. Justin - to put together a call flow, api flow. What would look like as a javascript rtcweb endpoint? If we implement in javascript, we could see this. I haven't seen how do I ask for sources, which are on/off? We need to answer this in rtcweb. Mary - we don't have the answer. Justin - I can work on the call flow. Paul to Justin - we don't have the callflows sorted out without rtcweb yet. Justin - we're implementing things. We're going to invent SDP things. We're shipping things. Can provide input on what didn't work. Mary - can agree that the spatial info would be carried in CLUE. Rob - Christer's proposal is good. I'll volunteer on the config(?) Bernard - Justin's issue is urgent - it needs to be sorted out. Maybe in mmusic. Mary - we need CLUE folks participating in mmusic. Paul (individual) - in my own understanding. It's not just spatial stuff, what we take out of the SDP is the menu not the order. If you have a hold bunch of things to send - don't do that in SDP. Lennox - in SIP, having huge and changing SDP is problematic. In rtcweb, it's fine, it's synthesized. there's some design constraints for SIP that don't apply to rtcweb. Christer - we have a requirement to interop with legacy SIP devices. What service or experience will they provide? What makes CLUE? Spatial info. Mary - I think we're done. [[ Charles Eckel notes for Tuesday Nov 6 ]] Roni Even FW: Media capture/content attribute (Issue #10) draft-groves-clue-capture-attr-00 Is there sufficient info in CLUE for a consumer to choose from captures in advertisement? Claim is that existing SDP content attribute value set alone is not sufficient for usage within the CLUE message. Proposal is to: 1) extend set of values and 2) add concept of a hierarchy (eg. presentation.slides) 3) add attributes for role, dynamic, embedded text, supplemental description, telepresence, etc. Jonathan Lennox - ok with concept, but not too sure about this set of example attributes Rob Hansen questioned embedded text. Stephen Botzko agrees with Jonathan and Rob. Roni summarized by saying that idea and approach seems okay. More comments on draft needed to refine. Paul Kyzivat presenting Proposed FW reorganization, including new work items & milestones http://www.ietf.org/mail-archive/web/clue/current/msg02073.html CLUE Telemedical Use Case Callflow (draft-kyzivat-clue-telemedical-callflow-01) There is an interaction between CLUE advertisement/configure and SDP offer/answer. Discussed call flow at interim, revised and discussed at next day or interim. Still needs more discussion. There were differences in the set of assumptions. This time, Paul is working with assumption that media you are sending at any given time MUST satisfy both the existing offer/answer and CLUE advertisement/configure. Can change with sending another offer/answer and/or advertisement/configure depending on what one is trying to change. Somehow the advertisement needs to convey the sender constraints (i.e. need for 1, 2, n, m-lines in SDP). Initial INVITE is special case, but even then, may assume some default. Simon Romano: seem to always start with offer/answer to establish CLUE channel, then use CLUE messages within that channel for advertisement and configure, then new offer/answer that is appropriate for the configure. There is some mix-up in terms of the version of the draft and some missing call flows, perhaps an -02 version exists somewhere. Roni Even: the initial offer/answer is still open to discussion, we may put very little or a lot in there, and additional offer/exchange after CLUE exchange may not be necessary. Paul Kyzivat: may need to restrict what is put in initial offer to avoid breaking non-CLUE implementations. Paul Kyzivat: main concern is interdependencies between offer/answer and CLUE advertisement/configure Roni Even presented thoughts along these lines Monday (draft-even-clue-sdp-clue-relation-01) Simon proposed initial offer/answer not have anything clue specific other than negotiation of clue channel. Rob Hansen proposed goal that SDP contains enough info to offer and choose from all the streams, you just do not know what they mean, and CLUE messages are needed to get more details like spatial information. This is essentially what rtcweb wants as well. Paul Kyzivat, good goal, but may not be realistic. Roni Even, there are advertisement/configure exchanges in both directions. Could use max-ssrc in offer/answer to state how many streams you can send/recv, then build advertisement accordingly. Lorenzo Minero?, cautions against being too ambitious in terms of how much information is put in initial offer/answer exchange. Justin Uberti, in rtcweb want to be able to setup all you want to do from offer/answer in each direction. Okay with more than one m-line, but want to avoid having one m-line per source. Paul Kyzivat confirmed CLUE has same need and desire. Simon Romano, can establish data channel and let RTCWEB or CLUE messages flow on that. Data channel is expected to be an SCTP data channel. Ted Hardy asked for clarification that channel is between endpoints. Agreed. How CLUE interacts with RTCWEB needs to be considered. Agreement in group that goal is for 4 messages, a single offer/answer and a single advertisement/configure exchange, but realistically another offer/answer may be needed in many cases due to backward compatibility. Mary summarized that the building blocks being discussed in CLUE provide this model. Rob Hansen Call Flows Objective is to work through an updated call flow based on *any* agreements from Monday. Note, at this time, these are the only call flow docs (slightly out of date): draft-romanow-clue-call-flow-02 draft-kyzivat-clue-telemedical-callflow-01 [Note: we can decided whether this is even reasonable to consider given progress and Monday and previous discussions] Skipped or merged into previous call flow discussion. Chairs Issue Review This meeting & issue tracker: http://tools.ietf.org/wg/clue/trac/report/1 Skipped. Mary Wrap-Up and Way Forward Mary shows slide on roadmap for deliverables Suggestions have been made to split the framework document up and add some highly level material. Looking for volunteer(s) to do the work. Ted Hardy pointed out that for reviewers it would be better to pare down framework asap. Merge existing rtp-mapping and rtp-usage drafts (even and lennox) Merge existing data mode drafts (romanow and presta) Framework, if change to standards track, need to clarify which sections are normative. Signaling, pull information from draft-even-clue-sdp-clue-realtion-01 and draft-romanow-clue-call-flow-02. Call flows draft to leverage existing drafts where useful Volunteers: Framework: Stephan with existing authors Data model: Simon, Roberta, Christian Signaling: - CLUE &SDP: Roni, Rob, Simon, Roberta, Christer - RTP mapping and usage: Roni, Jonathan, Charles (maybe) Call Flows: Simon, Roberta, Rob, Roni Milestones and Dates: Mary shared, agreed that they are too optimistic but leaving as is. Mary proposed switching from weekly design team meetings to virtual interims [[ Jean Mahoney notes for Tuesday Nov 6 ]] CLUE session 2: Tuesday, November 6th, 2012, 1300-1500 Length: 2.0 hours WG Chairs: Mary Barnes and Paul Kyzivat Agenda and WG update: ======================== 10 min Presenters: - Mary Barnes, Chair - Paul Kyzivat, Chair Note takers: - Charles Charles - Jean Mahoney - ?? - jabber scribe Blue sheets passed out. Note well presented. FW: Media capture/content attribute ========== 20 min draft-groves-clue-capture-attr-00.txt Presenter: Roni Even Slide: Issue content attribute has limited stream support (doesn't scale to multi-stream environment), insufficient info for making informed decisions, multiple functions (capture source, participant roll, content). Charles Eckel: are you discussing SDP content attribute or CLUE attribute? Roni: CLUE content attribute values are from SDP content attribute, and only a subset. Multi-stream wasn't foreseen as an application, the functions (main and alt) depend on application. The app was supposed to describe the meaning of the attributes. The attributes are ok, but are lacking values. Slide: Proposed Initial Attributes #1 Presentation - capture associated with presentation View - capture area Language - associate a lang with a capture, values likely same as SDP language attribute Rob Hanson - don't object to the idea; however the view attribute should be human-readable free text. Roni - it's machine readable, but not tied to the description. Add a qualifier to describe and a hierarchal order. Mary - are you talking about 2 things? A keyword and text description? Roni - the description is the keyword. Slide: Proposed Initial Attributes #2 Role - keyword for auto selection Dynamic - will the spatial info change (cameras not fixed) Embedded Text - indicates capture includes it, consumer can choose a video with/w/o translation Rob - I'm ok with this if they can be optional. The Embedded Text attribute needs to be clearer. Roni - I'm not sure about it either. Christian wrote the text. Jonathan Lennox - I like the idea of an open set of definitions. Caveat - I don't agree with this here. If we can get consensus on what the attributes mean, then it's OK. Rather have nothing than poorly defined attributes. Stephen (Botzko?) - In general, concept is good, I want to talk through the individual attributes. Not sure about Embedded Text attribute either - you need to know language too. Roni - Subtitles are not necessarily embedded. Rob - [??] Roni - It has to do with the multiple functions. Have something that describes the role of the participant and the source. Rob - the SDP one [??] Roni - [??] Paul (as individual) - I worked with Christian on this, too. I support this. This was a swag. It's a fair starting point, it needs to be refined. We can work on the details. Slide: Proposed Initial Attributes #3 Roni - Please read draft-groves-clue-capture-attr and comment. Mary - Send feedback to the mailing list. Call Flow: using ladder diagram in ========== 30 min draft-kyzivat-clue-telemedical-callflow-01 Presenter: Paul Kyzivat Paul - not sure if we have agreement on this. The ordering of offer/answer versus other messages. I had created a call flow and changed it based on feedback from the interim meeting. The call flow only shows messages, not the contents. You have to make assumptions about the SDP. For the call flow, the worst case was assumed: any time you sent an advertisement or configuration, it would require another offer/answer. Assumptions - the media satisfies both offer/answer and configuration. You may have to configure more stuff than you're allowed to convey. (assumptions are covered in section 3 of the draft). Roni - The advertisement doesn't say how many transport connections are used, just # of media captures. Paul - Yes, There's something missing. We haven't written it down. The receiver can be constrained - different equipment needs different mlines. The advertisement has to capture constraints of how the encodings relate to mlines. I need to put enough mlines in my offer. Charles - I'm lost - the advertisement needs to come before the SDP offer? Paul - It can't at the beginning so you make some minimal assumptions. You don't know what the other side is going to do. For a proper offer, you need to know what's been advertised. Mary - Matching the number - if the numbers don't match, you don't have the latest. Paul - If you send an advertisement against the latest configuration it should work. I'm assuming that here. Simon - Go to the ladder diagram. After CLUE channel set up, you send an advertisement, a configuration, then send offer/answer. That how I interpreted the basic steps. Paul - the -00 draft was complicated. For -01, I stripped it down - 2 participants and no MCU. Mary - it's not in the draft. Simon - never mind. What about setting up the CLUE channel? Paul - To set up the CLUE channel you need an offer/answer. We don't have to be proscriptive. You can put what you want in the offer/answer. You won't know if the receiver can support them. You can exchange some media based on what's there - an implied advertisement and configuration that you derived from the original offer/answer. Once the CLUE channel is up - you can decide what you need. Then send an offer/answer. Mary - I think that's agreed. Simon - negotiate a CLUE channel, then on CLUE channel send advertisement and configuration, then new offer/answer. Roni - The initial offer/answer is open - you can send a simple or a complex offer. You may not need another offer/answer. It depends on the initial offer/answer. Mary - Do you have a use case? Roni - 3 camera room system - I send an SDP that says I can send 3 streams and accepts 6. If the other side doesn't do CLUE or 4 streams, it still works. Paul - leave it up to implementations to do what they want. They may need to restrict to prevent breaking things. Roni - The initial offer is based on your capabilities. It's open. You may need to tune it after you receive an advertisement. Paul - My concern - are there dependencies on offer/answer and particular configurations or advertisements? Roni - I tried to look at that in my SDP CLUE mappings draft. In some cases, there are no relations, sometimes yes. Paul - if you need an SDP line, and I'm not sure it's true anymore, for each capture encoding in the advertisement. Every time you change the encoding, you may need to send an offer/answer. Maybe all configurations against the advertisement would work without a offer/answer. Roni - You can provide an initial advertisement indicating that you multiplex. It won't break, you're not doing anything wrong in SDP. the other side can decide what to accept. Paul - but if I send an other advertisement, do I need another offer/answer? Roni - If you add media captures, yes. It all depends. Mary - You can pre-populate SDP because you know what you are going to advertise. Simon - we need to decide whether we need CLUE channel at all. There are many cases where you don't need the CLUE channel. You can start an invite. Mary - but you won't get CLUEy stuff. Simon - it would be cleaner if we had a first offer/answer not related to CLUE advertisements, then send the advertisement, then new offer/answer to enforce the advertisement. If you you send final offer/answer with right SDP. Rob - there should be enough info in SDP to pick channels. The CLUE channel contains the info about what those captures are. Paul - the 2 sides can have different ideas about which mlines they need. One offer/answer won't guarantee to get it right. Does the other side want to accept or refuse? Roni - When we send an initial invite with one video mline and one audio mline. If I don't provide enough info the advertisement, neither side may line up. Both sides can send simultaneously. Paul - How can build an advertisement, how do I know? Roni - in the SDP. Paul - In SDP you can only tell me how many you can handle up to how many I've offered. Mary - your overloading the advertisement with the offer/answer. They are not configuration. Roni - [??] Merino - My understanding of the callflow is that there's a negotiation to come up with a basic landing. After advertisement process, then you can set up the configuration. Paul - that's how I view it. Merino - it would work better. Too much in the SDP, may cause it to fail. Paul - Other folks want to optimize. Mary - Rob and Roni want that. But it would be possible with their model. Merino - do we have to restrict to make sure things go fine? Justin - from rtcweb standpoint, I want to do everything in 2 offer/answers. The caller will send SDP with all sources. The receiver says what they want to get. Then if you want to change, another offer/answer. We need to nail it down. Paul - rtcweb wants only one mline, one 5tuple. That's the design goal. Justin - I'm not holding my breath. Paul - It's a design goal, but rtcweb should be capable of supporting more. Justin - I don't want to support N, don't want an mline for each source. Paul - we are talking 2-3-4. Justin - that's ok, I don't want 100 or 1000. Simon - You might negotiate through javascript or bidirectional http channel. On http, let the CLUE channel flow. A metachannel for CLUE not transported through SDP. It would be compliant with the rtcweb spec. Ted Hardy - is it a data channel? Does the information move through a triangle or go straight across? Paul - it's a CLUE data channel, the path isn't settled. Simon - with MCU, it's a big issue. A conference scenario, the http channel is between the client and MCU. Paul - how do we want to fit rtcweb into this architecture? Simon - I would be glad to discuss. Paul - we need to work on that and CLUE itself in parallel. Simon - work on CLUE first. Justin - I think there only needs to be 4 msgs. I don't care about the details. Mary - we had a draft that tried to do everything in SDP, and that's why we have CLUE channel. Roni - one problem - you can open the media channel but can't render. Need to render in the right order, and the info is not in SDP. Lennox - at a high level you have 4 messages. The 3rd offer/answer is needed because the SDP envelope doesn't line up with the advertisement/configuration. It's a clean up. Paul - if you negotiated the max possible configuration, then you can get by without another. You need to reserve a lot of resources for it. Bandwidth reservation in the network. If the other side can't handle it, it may fail. Rob - I think you can do it in 4 but may need clean up. Merino - have you considered using multipart? We did that in media control. Paul - we did it in siprec too. It was considered in this group and discarded. Mary - the original [??] doc has the reasons. Lennox - in the CLUE world, have backward compatibility with guy can't access rc [??] then you have middle boxes that change the offer without your knowing, or the call fails. rtcweb doesn't have these issues. Paul - Until they roll out the rtcweb SBC. Christer - Why are we afraid of an initial offer/answer? Mary - others want to optimize. Roni - I'm not worried about the second offer/answer, but the second advertisement - the advertisement may not be optimal. Offer what you think is best for the receiver. Paul - that's like the restaurant that won't print the menu until they know what you want to eat. Justin - I get it now Roni - my restaurant has a chinese menu and a french …. Mary - the food in your restaurant defines your scope. Your analogy isn't good. We've eaten into our time. Keith - both sides are right. Simon - Is anyone implementing CLUE? Paul - there's not any specific enough. Mary - once we have something, implementors will do it. Will you do it? Simon - no, maybe Cisco. Way Forward: ================================ 10 min slides: slides-85-clue-11.pdf Presenters: Chairs draft-ietf-clue-framework-07 Ted Hardy - refactor it now, it will help the reviewers. RTP mapping and usage: Combine even-clue-rtp-mapping and draft-lennox-clue-rtp-usage. Data model: Roni - if we want new attributes, put in framework first and then into data model. Paul - reduce detail level in the framework, and add detail to the data model. The data model is normative. Mary - framework should be standards track. Paul - [??] Keith - if it's going to be normative, please express what the normative requirements are. Chairs - ACTION: Ensure that the framework document specifies the scope of the normative text and the scope of the informational text. Signaling Roni has a start of doc. draft-even-clue-sdp-clue-relation Roni - what's the expected content? Mary - will talk later. Call flows Paul - call flows should be examples, not normative. Assignments Framework - need another editor ACTION Stephan Wenger volunteered as author/editor Data model - Simon, Roberta - ACTION Christian Hoene volunteered as author/editor Signaling - CLUE and SDP ACTION add Christer Holmberg as author/editor RTP Mapping - Mary - Charles, are you interested? Charles - I would have to get back to you Call FLows - ACTION Lorenzo Merino volunteered as author/editor Plans going forward: weekly design teams Paul - would rather review progress on deliverables in the mtg. Switch to the virtual interim in mid-December ACTION: Must have more engagement on the mailing list.