IETF 85 RTCWEB Chairs: - Ted Hardie - Cullen Jennings - Magnus Westerlund Session 1 Minute takers: Roni Even, Jean Mahoney Jabber scribe: Peter St. Andre Meetecho Recording: http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions#IETF85_RTCWEB_SESSION_I Administrivia/reports slides:http://www.ietf.org/proceedings/85/slides/slides-85-rtcweb-0.pdf Note well presented. Blue sheets passed around. Report from WebRTC F2F slides: http://www.ietf.org/proceedings/85/slides/slides-85-rtcweb-1.pdf Presenter: Harald Alvestrand Info also presented to the list. Decision: Do not change the API hugely at this time. Microsoft has been working on the API and are going ahead. Actions needed: State diagram can be settled at the W3C. If you want to do Trickle-ICE, create an API. If the IETF thinks that the per-track resolution is a bad idea, that's ok. Otherwise specify the mechanism. What range of priority and what happens when you set it? Next steps: Implement the APIs. Chrome has incorporated rtcweb No questions or comments. Ted - NB: All the work of W3C WebRTC group takes place on public mailing list. Summary: slides presented, ted's comment. IETF IPR Rules slides: http://www.ietf.org/proceedings/85/slides/slides-85-rtcweb-3.ppt Presenter: Scott Bradner First and last bullets are irrelevant - everyone has to follow them. Do what it means, not what it says. In the IETF, we want to approve specifications with minimal or no encumbrances. There's no requirement, however, unlike the W3C. Rule sets for IPR - BCP79 and RFC6701 (sanctions if you don't follow the rules) Your IPR are patents and patents applications owned, assertable or licensable by you or your employer or sponsor and known by you. The employer can't keep you in the dark. James Polk - I"m unfamiliar with, "should be known" Scott - "reasonably known" James - If I work in this space, should I know what my company is doing? Scott - your company shouldn't keep you in the dark. You don't need to be a busybody. Note well defines a contribution - anything you say or write that is intended to affect deliberations. You agree by registering for the meeting or by joining the mailing list. Ted (as individual) - If the chairs ask for consensus and participants send email, that affects deliberations. If participants hum in a meeting, are they contributing? Scott - That's fuzzy in our process. But by registering for the meeting or joining mailing list you have agreed to the Note Well. Applies to all contributions independent of standards track because you don't know if it will be standards track. If you have your own IPR in your contribution - you must disclose. If it's your IPR contributed by a fellow employee - they must disclose it, you don't have to. If it's your IPR and you notice it in a contribution of someone else and you participate - you must disclose it. If you see your IPR in some other contribution, but you don't participant - we would like for you to disclose. If you point to another standards body work, and it has IPR (not yours) - you should disclose. Slide: Participate Situation - employer said to employees that they were not to disclose patent applications. We asked that they not participate. It has caused problems in court cases. The normal practice is that the companies disclose even if employees are not active. As a safety precaution - and the courts are split - just being on the mailing list is a need to disclose. Ted's question is good - it's in the gray area. The spirit of BCP79 is that disclosures are important to the standards process. Someone humming is participating. Wenger - For the record, I disagree with the statement. Scott - It's not consensus. The IETF lawyer has an ID ready to cover this issue. We will have to see. It's an open issue now. The rules say if you sit on your hands, you don't participate. Slide: Disclosure Details Patent - Patent number and the specific parts of the IETF contrib. Apps don't require the same details. Blanket disclosures are not permitted unless offering unconditional free license - e.g. no reciprocity. licensing info is not required - might want to change that at some point - but encouraged. Participant - The blanket disclosure - is that consensus? Scott - Blanket disclosure for free license is ok Harald - do we have IETF consensus that a free license means no reciprocity? Scott - yes Slide: Use of Disclosures Working groups make up their own minds. Cannot know about claims of IPRs not disclosed. The working group has to understand that not all IPR claims are accurate - some are wishful thinking. Until it gets to court, you don't know what the patents cover. Peter Saint-Andre - Change "all IPR may not…" to "might not" on the Use of Disclosures slide. We wrote an RFC on early IPR disclosures. Randall Stewart - What about former employeer ? Scott - If you have no stock, stock options with your former employer. No consensus. If you know about it, disclose. Anyone can make a 3rd party IPR disclosure. Keith - What about IPR in normative references? Scott - Has been discussed, no consensus. Unlike ITU which requires tracing. If you do know of something, tell the working group. It's a 3rd party disclosure, the working group needs to know. MPEG - theres a zillion patents on that. It's not mandatory - working group requires disclosure, but you are not required. Wenger - I'll push back on 3rd party disclosures - it's useful for wg to have as much info as they can get. Providing advice or encouraging 3rd party disclosures without telling folks that the there are risks. If the patent goes to court, you will get a call. If you change jobs, your contract doesn't allow you disclose confidential info. Scott - You are right on the 1st point. On the 2nd - if the patent is published, it's not confidential. You will be called if you file the disclosure. Wenger - I wasn't referring to patents, you using info while being on the job - if you wrote the application, and then made public statements to the detriment of your employer, then.. Scott - that's a warning for folks disclosing 3rd party. Spencer - we're optimizing in 2 dimensions - asking lots of details of Scott is good because it tunes the IETF policy. Scott - the IETF's role is to make good tech, not worry about courts. Spencer - If I end up in court by walking a fine line and they rule against it. Scott - Be better to follow the spirit. Ted - I'll push back on Wenger - we're dealing with published patents where the landscape is well known. Our proposals reference specifications that have well-known licenses. However, we have no disclosures. We have normative references to these specs. It would have been better if there had been 3rd party disclosures registered. 3rd party disc would be valuable. If no one else does, I will make the disclosures myself. If others have 3rd party IPR that you can explain why you can't disclose, come to me. Bernard - Some of the drafts reference other standards docs with IPR Scott - We have to be careful with putting lists into RFCs. We don't want a indication that it's a full listing. RFCs can't be changed. Better to capture the info earlier. Wenger - I wouldn't have issues on patents with licenses. It's not helpful that the absence of it means H. 264 is encumbered. If we put encumbrances on everything it doesn't make sense. Scott - The IPR in RTP payloads has come up in the past. The conclusion is the payload is an envelope, and it is not a problem. The question of using X is a separable issue. Using X as part of standard is different than transporting X. JSEP Document Update (non-SDP)slides: http://www.ietf.org/proceedings/85/slides/slides-85-rtcweb-2.pdf Presenter: Justin Uberti Slide: W3C Status getUserMedia timing - a proposal - get a media stream immediately but doesn't get data until user gives access to the camera. multiple streams/tracks - no way to describe. Need a way to control what gets sent. DTMF API - Martin Thomson - we've resolved this one. Harald has a draft. Cullen - wrong working group, we're expecting a proposal. DTMF is going forward. Slide: Changes to JSEP -02 Matthew Kaufman - It's a bad idea -you get a delayed hello. You have to be able to receive. Justin - you can get your SSRCs going before the hello. Slide: Document review notes Christer - are you going to show the state machine agreement? Justin - There is a proposal doc on the W3C list. ACTION: Justin to send a link. Slide: Proposal for SDP that MUST be implemented Matthew Kaufman - not an open issue - receive from other side no mline. For MSID Issue, comment 22 applies. Justin - agree Slide: Proposal for SDP that MAY be implemented Collin Perkins - Be careful with the MAY, if you are using this optional RTP feature, other items becomes MUST (Reduced size RTCP - you must implement the SDP). Justin - So we need to say, if you support this feature, then you MUST. Bernard - If you support, you must include it in the offer. Randell Jesup - you want 5506. Christer - RFC5888 is listed as MUST, is there a specific use? Justin - The grouping framework defines mid, which makes things less fragile. Lennox - SDP has both mid and label Justin - label is human readable. The mid references the mline. Lennox - comment not heard Justin - covered in ICE. Lennox - This needs to be explicit Paul Kyzivat - Is this exhaustive list for SDP? Justin - yes. Lennox - it implies AVPF, which is not listed here. ACTION: Add AVPF and its normative references. Kaufman - we need an exhaustive list of what MUST be implemented, otherwise it will hold up the W3C spec. Eckel - SDP signaling for BFCP for content sharing and SCTP is needed. Justin - BFCP will be an application issue. I don't want to provide a BFCP stack. Eckel - the draft is on the ppt Rescorla - Why is 6544 on the list? Justin – to do ICE where UDP does not work Rescorla - We'll take the discussion to the list. Harald - the spec doesn't need to mention every SDP spec. 6236 - should we be able to negotiate image resolution - need to resolve. Justin - To summarize the discussion, we need to add more RFCs to the MUST implement list. For SDP that MAY be implemented, other RFCs become mandatory to implement. *** Slide: Forking with PRANSWER Kaufman - Is this serial forking? Justin - yes Christer - looks good. Issue - When you receive pranswer from the PSTN and you offer on that leg, that's not covered in the state machine. Cullen said that it's a signaling issue. Kaufman - in the JSEP API, not only can you wait for the answer, you can generate a new offer before getting an answer. Justin - Does this happen enough in the real world? I'll talk about more in the next slide. Rescorla - I don't have issues with the slide - it's not enforced at JSEP layer, I'm good with it. Cullen (as individual) - the signaling can be serially or parallel forked. The cases where you have 1 or 2 streams of media at the same time. What are the use cases that we can't support with pranswer. Simultaneous 2 streams of media can't be dealt with. Christer - I'm taking about serial forking, 1 stream at the time. Richard Ezjak - In serial forking case, if you need to renegotiate, and you terminate and use original offer that had been forwarded, that case fails with pranswer. Justin - so A has an offer to B and C and B has pranswer and wants to renegotiate. A has to close to renegotiate. Anything comes from C is SOL. Justin - ACTION: need to describe the use use cases we can't support. Cloning - Details Kaplan - Go back to the Forking with PRANSWER slide - how often does the offer to PSTN, it sends a PRANSWER . It won't happen often. You would have to go through an intermediary anyway - they can handle it. Don't complicate world for the browser side. On cloning - on the browser csse - the forking case is useful - display 2 screens, can mix. SIP only picks one stream. If it's lot of code and bug introduction into the browser, I wouldn't do it for PSTN interoperability. The middleboxes just pick one stream and the clients don't see it. Justin - we agree that displaying multiple streams might be useful. However, how useful is it to hear US and Euro dial tones at the same time? Martin - do RFC (number not audible) Justin - agree Martin - if you are creative with SDP synthesis, PRANSWER is sufficient for cloning and the multiple streams. You don't affect browser state. You can mix or display in different tags. Don't need cloning. Can support parallel forking. Christer - PSTN isn't going to give new offer. The PSTN isn't the only remote end point. There are legacy SIP endpoints. Won't happen often. Forking with cloning - it doesn't mean that we're dealing with multimedia, only media with latest clone. Work in a serial manner. We need to document limitations. Lennox - other than demux, Justin - It's like another peer connection sharing Lennox - you have to know before installing answer 1 that answer 2 may be coming. If you clone, it as if an answer hadn't been received. Step 3 on the Forking with Cloning slide isn't necessary. Justin - you need a magic timeout. Richard - great if you've answered the parent. The timing of when to clone needs to be discussed. PRANSWER supports cloning, but if end points do multiple offers, it applies whether it's serial and parallel forking. Magnus (as chair) discussion is closed after this. Randell - real world situation: Telecom sends offer to the server. The server says the person could be at several places (tablet and phone, etc), multiple people pick up. You don't have to implement that. Parallel fork with multiple streams makes sense. google + - invite to a group - multiple answer and people expect a bridge conference. None telco case - don't have media streams associations, gaming cases. If you can do it with out cloning great. But it would work. Justin - The server is connecting you to someone. Cullen - use cases - one stream of media at a time. For bridge line appearance use cases, parallel forking didn't work as a general solution. A mixer sets up the conference and mixes the info. The gaming use case is setting up peer connections in a mesh. Leave cloning until later, until we know we need it. Rescorla - this is over engineering. The risk is low that we need this. Kaplan - It's a problem of signaling, a server can tell the browser to create a peer connection. What happens to the privileges? Justin - the privileges are on the media streams. Kaplan - I'd like to say forget cloning. Justin - need new candidates on new peer connection. The clone would keep. RjS - If you allow serial forking with SIP, you will get parallel forking for brief periods of time. Think through the use cases. Justin - summarizing - I wanted to hear support for cloning. I didn't hear that. Peer answer does what we need. If we need cloning later - we'll deal. Magnus - Hum to see if PRANSWER is sufficient? pranswer sufficient? stronger hum Pranswer is not sufficient? weaker hum Ted: Not strong consensus. ACTION: take to the list Quirks mode: what is actually sent versus what it meant. Justin - we should be strict. If we talk to legacy, though go to quirks mode. Thomson - agree Kaufman - since the browser is not talking to endpoints directly, the middlebox can fix it. What error should we raise? Justin - Why can't you talk to the SIP device? Kaufman - You can fix in the java script. Bernard - In creating the offer, you describe what you support. Strict in what you send and liberal with what you receive. Don't create a quirks mode - there will be no end to it. Create principles for what send and receive. Justin - Being strict will keep us sane. Kaplan - Quirks mode concept - if the javascript needs to intercept, that's where it should happen. The browser should remain clean. Harald - if specify quirks mode, then we have define it and implement and live with it forever. quirks have no place in create offer. quirks is responsibility of the javascript coder. Randell - I don't understand avoiding quirks mode. How do you know you are talking to it until you get the answer. Don't implement quirks mode. Push that onto the gateway - server or signaling gateway. Keep things clean. Cullen - javascript removes the F from the AVP to interoperate. It's common. I don't care if we do it or not. We need to be consistent on editing the SDP. Magnus - discussion closed. Justin - to summarize - we shouldn't generate quirky SDP, and leaves fixing quirky SDP to the application. MediaStream ID How do send and demux? Justin - is there an w2c ID now? Martin - yes. Justin - these slide are old. Stream selection O/A Proposing a 3way handshake Roni - Go back to Stream SDP slide. You assume that you have all the SSRCs that you can send. There is a topology when the mixer won't distribute. You can't put in the SDP, you don't know, it sources from someplace else. Non mixer case - if you have system with 3 cameras and you want to send 1 stream and it's switched? Which SSRC do you get? You change SSRC with each switch. Need to discuss. This topology was defined. Ted - ACTION: write up the topology and send to list. Martin - This is awesome - I'm being sarcastic. Comment 22 probably applies. You don't know what SSRC you will use. Having implemented this - it's difficult to get right. Legacy may want to send more than one stream. Justin - there's a case with a presentation and multiple mlines. I haven't heard that you need to handle lots of multiple SSRCs. Martin - you've heard it now. Kaplan - from legacy devices that don't support it. They need multiple mlines. Why recreate the wheel? You are recreating SDP. We'll have bundle. Justin - if the answer has more mlines than offer? clue said that they will multiplex mlines. Eckel - 1.5 rtt or simultaneous offers - could create glare. Justin - not simultaneous, back to back or serial offers Constraints registry _____________________________ 20 min draft-burnett-ritcweb-constraints-registry slides: slides-85-rtcweb-4 Presenter: Dan Burnett Discussing changing constraints but don't have a mechanism yet. Rescorla - question on the example. 1.333 can't be satisfied. Dan - I don't want to discuss specific constraints. The registry draft doesn't define minAspect ratio, the W3C draft does. Adam - as a user in the seat, I have multiple microphones, can we build up the constraints for the user to use? Dan - the browser may assist the user with what they want. It's about the app needs, not necessarily the user. The browser will ask for permission and let the user select the source. Open discussion Kaufman - process point - why has this been brought up? It's a registry for API not on the wire. W3C can make the request to IANA for the registry. Dan - I started with that. Chairs for both groups recommended that I do this work. Bernard (as individual) - talk to IANA reps here. My personal opinion is that you have to think about what value the ietf can bring to this. If say CLUE could use it, then we should do it. ACTION Ted - Chairs to talk to IANA and W3C chairs to discuss. Session 2 Minute takes: Richard Barnes, Paul Kyzivat Meetecho recording: http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions#IETF85_RTCWEB_SESSION_2 -- Chairs intro -- Note Well -- Agenda Bash: Serge proposes to bash the agenda -- Google commits to addressing IPR issues around VP8 by Orlando -- Google asks to postpone this decision to Orlando -- [See posting on RTCWEB mailing list] -- Ted: Any other agenda bashes [hearing none] -- ... Chairs would like to proceed with stats preso, then meet with ADs for a minute -- Kaufmann: When are you going to take input from the room on that agenda bash? -- Ted: If the ADs don't want to allow it, we'll strike it -- Kaufmann: I believe that there's much more important work for the WG to address than the codec selection issue -- ... However, given that the Google proposal suffers from serious IPR issues, I'd like to make the decision now -- David Benham (?): I'm concerned that the press is going to say "IETF can't make up its mind", so we need a reason -- ... What is it we're waiting for? -- Serge: Can't really say much more than what was in the email -- ... Need a little bit more time to make a full and clear statement -- Harald: Stats API -- This is an IETF issue because it touches IANA -- [[ Presentation ]] -- Concern that sufficiently detailed stats could raise security issues, e.g., enable reconstruction of encrypted voice -- Kaufmann: Feel the same way about this as the other one -- Ekr: Think this is fine work, but we shouldn't split things between W3C and IETF without reason -- ... Not sure what we're accepting here; is this a commitment to put things in the registry? -- Harald: Looking for consensus from RTCWEB that we don't want to block it, then we can take it back to W3C -- Ekr: We need a registry for stats, go forward -- Romascanu: Related to registry: PMOL might be relevant, you should check that out -- Harald: Please send a pointer -- Romascanu: The recommendation last week in Lyon about removing the remote part deserves some discussion -- ... Could you recap why that seemed good, and how you were convinced otherwise? -- Harald: The most important thing to talk about are these flows, and they have two ends -- ... I was convinced by Matthew that we could have two objects that point to each other; same thing with simpler model -- Romascanu: That's true about RTP connections, and remote parts of attributes are more natural there -- Harald: We have to measure other things than RTP, e.g., ICE -- Kaufmann: This is an API issue, should be resolved in W3C -- O'Callahan (Moz): We have a lot of experience with these sorts of APIs; better to have typed DOM objects -- ... Might want to consider re-casting this to use that design pattern -- Ekr: Using this for error recovery might impose a greater burden on this API than just diagnostic/forensic -- Bernard: Maybe we could meet with IANA to avoid the need to pass things like this through the IETF in the future -- Harald: There will be lots of stats that people want to add... -- Cullen: In a second, we're going to take a consensus call on whether people -- A couple of points came up in chairs' discussion with the ADs -- 1. People came here to do this -- 2. People are suggesting that we're going to have new information on an important topic -- 3. More than one person has made comments that we have more important thing to do -- Opening mics for comments on agenda bash -- Wenger: What is requested in this email is to postpone the decision, not the discussion; also postponing the discussion? -- Cullen: Yes, also postponing discussion -- Bernard: If Serge's concern is that the IETF will come to blinding consensus on this, I can allay your fears -- Cullen: Robert will judge the consensus -- Michael (Cisco): Some of the topics that you're deciding on have presentations already posted; contribution has already been made -- ... Is the decision on debating it moot? -- Cullen: Sure, drafts have been written, etc. Question is just about meeting time. -- HUM: In favor of the bash? [loud] -- HUM: Opposed? [none in room, one in jabber] -- Robert: Clear consensus -- Ekr: Micro-bash in addition; could we go back to the MSID slides? -- Justin: JSEP Update (The Sequel) -- [[ presentation ~ Media stream taxonomy ]] -- Jonathan Lennox is writing a -00 draft on terminology for media streams -- Ted: Is it implicit that this hierarchy [of media streams] isn't all present in a given isntance? -- Justin: You may have situations where there levels collapse -- Ted: Important to make sure that the relationship allows for these unities / gaps -- Drage: As AVTEXT chair, wanted to put some context around this draft -- ... Very provisional for now, need to have a discussion about what group this goes in -- Ted: Suggest doing this as just draft-lennox-* ...? -- Lennox: Or draft-lennox-rai-* ... -- Roni: Shows we still have a problem understanding the different terminologies -- Justin: That's why I wanted to write this down -- Kevin Gross: Actually two more levels of hierarchy above this: Clock source and inter-destination synchronization (IDMS) -- Harald: Need to be conscious of the borders we're drawing -- ... If I'm an RTCWEB application and I get a byte stream from somebody else -- ... Then I might have to mark the stream with a different CNAME -- ... Fine with that, just want to make it completely explicit -- Justin: If you're saying you've got two streams you want to composite, you would re-write the CNAMEs? -- ... Think local processing is "post-CNAME" layer -- Harald: If we agree that a media stream is only sent out with a single CNAME, that's fine, we just need to clarify -- Lennox: Just wanted to clarify that while I'm editor, all the other volunteers aren't off the hook -- ... There are things that are wrong on this slide, but it's good to have a slide -- ... It might be a more complicated graph than just a hierarchy -- ... You might divide things between the level at which RTCWEB needs to care and lower-layer things -- Ekr: Higher-level question. Is it required that the arrangement of JS object on side A matches the arrangement of JS objects on side B? -- Justin: Should be; why should we do anything different? -- Cullen: We need to have a way to correlate a track on one side with a track on the other side -- ... Then the question arises of whether you need all the other levels -- ... It would be very feasible to claim the only thing you need is to map the actual RTP constructs to an identifier -- ... Then applications could put those things together -- Justin: Hear you saying that you need to send a bunch of meta informaton that the app uses to patch together the media -- ... Don't hear you saying why the arrangement should be different -- Cullen: Might have a very generic video conferencing bridge that's just mixing video streams -- ... Endpoints might understand the different groupings in more detail -- ... Not obvious that we had a requirement that the grouping structures be perserved -- ... Rather that the items in the groupings had to be named so you could point to them -- Ekr: If I had a CNAME with 2 media streams, would that be OK? -- Justin: Yes, but API is not yet defined -- Spencer: Thank you for the work trying to unify these concepts -- ... Are there applications besides CLUE that you guys were planning on reaching out to? -- Justin: Mainly just trying to write a glossary -- Kaufmann: Comment 22 applies here (Comment 22 == "Microsoft just made a proposal that doesn't have this problem") -- ... Agree with Cullen that we don't necessarily have to map these things -- ... If you don't, then the end-to-end constraints stuff might not work completely -- ... You're adding some stuff to SDP to do the mapping, is it mandatory? -- Justin: Need to be liberal in what you accept -- Kaufmann: Concerned that the requirements are going to grow, make the SDP less compatible -- Lennox: The MediaStreamTrack is the lowest level at which JavaScript is likely to handle things -- ... Question of structure above that level is mostly an API question -- ... Everything below MediaStreamTrack sort of collapses -- Bernard: Are you planning to deal with layer coding as well -- Lennox: Yes -- Roni: We have two issues: (1) How to combine multiple SSRCs, and -- ... (2) Relationship at a higher layer between different types of streams -- Harald: Minimum thing that SDP needs to do for WebRTC is provide a handle for the MediaStreamTrack -- ... The nice thing about SDP is that it's this continuous flood of extensions -- ... We need to be able to communicate with applications that don't have another channel -- ... If all applications have a back-channel where they can say which tracks belong on which streams, we don't need it in SDP -- Thomson: Concerned that there's an implicit assumption that signaling will occur prior to playback -- ... There are situations where the signaling shows up after the media -- ... Have we made the decision to require explicit signaling of SSRCs? -- Justin: If we have a single M-line with multiple videos in it, then we need a single SSRC for it -- Kyzivat: This seems more about concepts than coding; such a mish-mash of terminology that we can't talk to each other -- ... Not sure that a lot of this shows up in signaling -- Justin: We can decide what to signal once we agree on the data model -- [[ presentation ~ mapping to m-lines ]] -- Kaufmann: My problem with this whole MSID thing is that if I offer three m-lines and you want to respond with 5 m-lines, you can't -- ... But if the same isn't true with MSIDs. Seems like a work-around. Discussion of bundle. Justin: offering and answering different numbers of sources within m-line is no problem. Christer Holmberg: what about legacy things that don’t do this signaling – just offer 10 m-lines? Justin: (explains a legacy use case.) -- Hadriel: The problem with this slide is that the default is *wrong*, the default should be what SDP does -- Justin: Question about what you want to do for the future -- Hadriel: The reason you want multiple m-lines is that their properties are going to change for properties other than Track ID -- Justin: Not all applications have to deal with that, can signal things like resolution in-band, in the codec -- Hadriel: This can cause problems with communicating with the PSTN world -- Harald: [ missed ] -- Roach: While nobody here has a great love for SDP, we chose it because you get some things with it, e.g., offer/answer -- ... This proposal throws that out, so you'll probably re-discover the problems that offer/answer solved -- Justin: SDP has some assumptions based on the technology of the time. The work in CLUE is in this direction. -- Ekr: Let me try to recap what the proposed benefits -- ... Answer can respond with more tracks than the offer; offer also doesn't have to pre-allocate ports -- Justin: Also, the sources your offering don't have to affect the other side -- Ekr: Do any current applications do anything sensible with this sort of thing? -- ... The alternative would be to offer bundle and use that for capability discovery -- Richard Ejzak: +1 to Hadriel, Adam. This is also an issue in CLUE. -- Justin: This direction came from the CLUE discussion at the previous IETF. -- Cullen: Let's back up and try to focus on what the benefits of the respective approaches are -- Magnus: Think this might mix up different use cases; stream selection vs. transport selection -- Roni: Think in CLUE we got to at least 2 different selections -- Hadriel: [ missed ] -- Charles Eckel: Concern about whether you need to know and signal SSRC values ahead of time -- ... If you need signaling to arrive before media, then that could be a problem -- Ted: These slides have been uploaded to the meeting materials site, also some slides from Randall Jessup -- [[ presentation ~ trickle ICE ]] -- [[ presentation ~ rehydration ]] -- [[ ... scribe stepped out for a moment ... ]] -- Ekr: What state does this put the PeerConnection in. It's not the ordinary Offer state -- Justin: Was thinking it would be something like SentOffer, and you could munge the SDP -- Ekr: So it would be as if I called setLocal() with the right password. Taking offline, but this needs to be worked out -- Thomson: Pretty sure we could work out something without this that would have pretty much the same user experience with no API service -- Ted: Is that Comment 22 or an offer to write a draft? -- Cullen: Could you write an email to the list explaining how? [Yes] -- Kaufmann: Who calls this? The side that last created an offer? answer? [either] -- ... So what happens when we both do this at the same time? [not well defined] -- Randall Jessup: Seems like there's an enourmous number of edge cases here -- ... Basically agree with Martin that you can do the same UX with existing APIs -- Justin: It would totally work for the application to treat the new call as a continuation of the old call -- Randall Jessup: Data Channel issues -- Contention with media streams -- Ideas: -- No control or simple rate caps -- Slave to media congestion control -- LEDBAT -- RMCAT -- Lennox: On giving this a % of the media congestion control, that could lead to interesting oscillations -- Randall: Would want the congestion control layer to know what the data channel tried to do -- Colin Perkins: Media channel will also going to be competing with TCP -- ... Perhaps we should be addressing the general problem of how to make the media stream robust -- Randall: Unlike generic traffic, we can actually control this one; the app might have priority preferences -- Michael Tuexen: We need to come up with an acceptable solution in the first version -- ... For me, the data channels don't kill the media channels on the same PeerConnection -- Randall Stewart: If you're going to do something like this, don't put a rate limiter, put in an API to the congestion window -- Kaufmann: Prioritization only exists if there's shared congestion state -- ... In order to get prioritization, we need shared congestion state -- ... Once you have shared congestion state, several of these options are no longer relevant -- ... E.g., "loss-based, can kill media" is not a problem -- Harald: At the moment, we have one piece of congestion state, namely the circuit breaker algorithm that Colin is shepherding through AVTCORE -- ... Suggest that the default is that sensible things happen when you have no API -- ... What should probably happen is that you watch the one piece of state you have, and back off -- Magnus: You can use quite a lot of the available bandwidth -- Lars Eggert: I think we fumbled when we chartered RMCAT. That needs to cover both data and media channel -- Piers O’Hanlan: The actual rate control, how you do this with SCTP, you might need more use analysis --Mike Ramhalo?: What the channels need to have is a shared congestion *measure* (not state) -- [[ presentation ~ initial creation ]] -- Kaufmann: Do you mean "creating the data channel" or "creating SCTP channels" -- Randall: I mean setting up the SCTP over DTLS at the beginning, then setting up createDataChannel later -- Include protocol field from websockets? For interop between applications -- Thomson: This seems useful -- Harald: Just clarify: these are not MIME types -- Ted: Chairs are discussing whether to have an interim, will come to the list for discussion (f2f / virtual) -- Wenger: Will the interim be a codec decision meeting? -- Ted: No