RTCWEB IETF91draft-ietf-rtcweb-video Chairs: Cullen Jennings, Ted Hardie, Sean Turner Notes: Tim Terriberry, Keith Drage, Steve Donovan, Brian Rosen Recording day 1: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_RTCWEB&chapter=chapter_0 Recording day 2: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_RTCWEB_II&chapter=chapter_0 Action items: Chairs to ask for comments on the list for the Gateway and RETURN draft before considering for adoption. Chairs to confirm adoption of draft-uberti-rtcweb-fec on the list. Data channel draft authors should update the draft and re-circulate -rto IESG. JSEP editors should update the draft after confirmation of decisions on the list. Harald should update terminology to reflect new term for “device”. Sean (as Chair) to confirm mandatory to implement video codec “sense of the room” on the list. Adam Roach to update draft-ietf-rtcweb-video with resolutions of open issues. Magnus should be disturbed on paternity leave to confirm the use of b=. Day 1 Agenda: Administrivia http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-1.pdf JSEP http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-5.pdf Data Channel issues http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-0.pdf Terminology http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-2.pdf Gateway http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-3.pdf Return http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-4.pdf Day 2 Admin/chair slides: http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-9.pdf Dependency review: draft-jennings-rtcweb-deps-05 FEC discussion: http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-6.pdf Consolidated codec slides: http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf The text following this is the raw notes the chairs received. This is not 100% complete due to the difficulty of transcribing everything but the the recordings are available for clarifications. --------------------------------------------------------------------------------------------------------------- Notes from Tim Terriberry === JSEP === - m= proto field * No objections to basic proposal: MUST [re-]offer correct thing, MUST accept RTP/[S]AVP[F] or (UDP|TCP)/TLS/RTP/SAVP[F], answer MUST match offer * Use UDP unless you know for certain that you're doing TCP (e.g., in a re-offer after ICE has completed) * If we're talking about SCTP/DTLS and we're not saying a=fingerprint is required, the JSEP draft needs to be updated. - Text about DTLS-SRTP exists also in the rtcweb overview. We should either say it once, or at least make sure they're consistent. juberti: We should say we have to use DTLS, and in the special case of media DTLS-SRTP. fluffy: We should say we have to use TLS, and I include DTLS in that. - Bundle/mux policy (#91) * Go with two variables: Peter's "I care a little bit" is the most care we can muster. - Value of {local,remote}Description when closed (#88) * Take this out of the spec and let the W3C deal with it. - a=ssrc for a=recvonly m-lines (#79) * This idea will go off and die and we'll come up with some other way of doing this. - Death of a one-way stream (#76) * Whatever insane stuff is in the document, there's no way to have continuous consent by m-lines. * Still needs to be addressed in MMUSIC, no volunteer found. - Multiple t=lines (#27) * Proposal accepted * abr volunteers to review specs for other places where we allow one or more doodads when we should require exactly one. - Changing b= (#9) * No one but Magnus understands b= * If the editors can get the document finished before Magnus returns from paternity leave, fluffy will buy Magnus enough bottles of scotch that he will do this while on paternity leave. === Data Channels === - DTLS 1.0 vs. 1.2 * Can reference both 4346 to 6347 (hum taken, none opposed) * Andre raised an objection to MUST 1.0, MUST 1.2 * Ted/Tuexen propose MUST 1.0, SHOULD do the most recent version as the appropriate choice. + We will need to adjust the crypto suites as well. - Use cases and requirements * fluffy's opinion as a chair is that we not move text from one boat to another. * Plan B: Put it in an appendix and mark it informational. - Normative language changes * Keith: the passive voice means it's not clear who has to comply with it. * abr to send comments about awkward text to the list. === WebRTC Terminology === - A mobile app that compiles in WebRTC support would be a device? Yes. - Node.js would be a browser? If it exposes the Javascript API, then yes. - A browser plugin that provides rtcweb functionality in a non-WebRTC capable browser? If it provides the rtcweb API, then the combination of plugin+browser is a User Agent. - A library that implements WebRTC: the library by itself doesn't do anything, but might be a Device or a User Agent when combined with other things (juberti dissents that things that are programmable should be User Agents). Poll for names in place of device: "Non-browser" had more hands than "Native Application". EKR: We have this phone that doesn't do video. juberti: Clearly if the device doesn't support video, then it doesn't need to do video. hta: The case of something that has an exposed API, even if it's not a JS API, needs to be mentioned somewhere. === RETURN === mt: You have two different "host" candidates. You want to prioritize them appropriately fluffy: This must guarantee that if the JS is trying to preserve privacy, the enterprise-provided configuration must not override that (juberti: that wouldn't happen because you'd still go through the application proxy). fluffy: As long as it's not hairpinning, I wouldn't want to have to go through the application proxy if I didn't have to (juberti: agreed). Of those who have read this, who thinks we should adopt it as a WG draft? "less than half" / "a very small number". Take it back to the list for comments. === WebRTC Gateways === - Ted: We want to see at least one comment on the list before we ask for WG adoption. --------------------------------------------------------------------------------- Raw notes from Steve Donovan for Day 2 FEC (see draft-uberti-rtcweb-fec and draft-singh-payload-rtp-1d2d-parity-scheme”) (20 min) Main issue is we need to decide what, if any, FEC is MTI for RTCWeb - Adapting draft-uberti-rtcweb-fec as a working group item - Will confirm on the list - Open issue 1 - no objections - Open issue 2 - should be solved somewhere else, not a rtcWEB specific issue - Open issue 3 - MUST send (default of right side up), SHOULD be able to receive, Need a header extension definition, other things in 5.2 of rtcweb usage document that should be MUST. - Open issue 4 - Request for someone to send a citation. - Open issue 5 - Should take to the list but answer may be yes, Bernard and others will generate list. - Open issue 6 - MTI (next topic) MTI Video Codec (time depending) Novel plan - Adam Roach - General feedback that more detail is needed on what would trigger removing one of the MTIs. - There is precedence for this method with crypto suites and expiration of RSA patents - Is trigger for the whole codec (encoder and decoder) being royalty free or only the encoder? Currently whole codec Jonathan Rosenberg - Let's make rtcweb successful together - please please please Harald Alvestrand - +1 - Google intends to implement the standard ---- "The Great Codec Compromise" - Direction from chair - Stand if you are participating in the decision - A lot of people stood (most of the room) New technical issues discussion - Type 3 declarations made against VP8 in ISO (Microsoft and Apple indicated this is a blocking issue for implementing VP8) - H.264 MTI document has some new information - GSMA report - Harald questioned some of the numbers in the report - Adam pushed back that the new information doesn't really impact the proposal being made - Question: If we accept this proposal today can we change it to another proposal that was recently put on the list later. Answer yes. - Question: Could this change within 24 months? Cullen, possible but can't predict. ---- The hums: Who does not want to take the sense of the room on whether to add the compromise text in the doc today? One hum from jabber room. Those in favor of adding the text into the doc? Those not in favor of adding the text into the doc? Rough consensus to put the text in the document. All other Business (matters returning from session 1, IESG resolution, etc.) Raw Notes from Keith Drage for day 2 RTC WEB SESSION 2 NOTES ========================== Agenda Bashing + Status update all drafts (5 min) Chairs -------------------------------------------------------- FEC ----------- draft-uberti-rtcweb-fec draft-singh-payload-rtp-1d2d-parity-scheme”) (20 min) Presenter: Justin Umberti Slides: http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-6.pdf Main issue is we need to decide what, if any, FEC is MTI for RTCWeb Bernard Aboba: Drop RED on audio Martin Thompson: If have less, then easier to add more later on. DECISION: WG will proceed to adopt draft-uberti-rtcweb-fec as WG item, subject to confirmation on the list. MTI Video Codec --------------- draft-ietf-rtcweb-video-02 Presenter: Adam Roach Slide 5 Martin Thompson: Not a rtcweb specific issue. Slide 6: Justin Umberti: Would prefer to be stronger, as in MUST. SHOULD on receiving. Jonathan Lennox: Reasons for not doing, like being right side up. SHOULD on receiving sounds weird. Justin Umberti: All modern stuff SHOULD try and negotiate it. Harald: If intending to use a header extension then add an reference to document. Mo Zanaty: An IANA registered header with reference to 3GPP document. Codec specific mechanism way of doing this. Harald: Will send some suggestions on doing this. Randall Jesup from Jabber: Must send if not non-rotated, orientation should persist without the extension. Retransmit orientation periodically to deal with packet loss. Stefan Wenger: Is header extension RFC generally required? Answer is Yes. Presenter: Currently in state where MUST use header extensions. Justin: Same as previous comments to apply to mixer header extension. Slide 8: Bernard Aboba: Think should take to list but think the answer is yes. Slide 14; Presenter statement: This is a statement of intent. If question is irrelevant at the time, then will not do this. Presenter statement: Can also reconsider at any other time. Andrew Allen: Is it both encoder and decoder? Stefan Wenger: In general standards do not define the encoder and therefore IPR statements are not made on the encoder. Jeremy Fuller: Is there anything here that declares a minimum time. Presenter Change at Slide 15 to Jonathan Rosenberg. Presenter change at Slide 20 to Harald Alvestrand. Slide: 25 Andrew Allen: What is being done about the type 3 declaration and will Google implement this. Harald: Am working from Assumption that VP8 is royalty free. What you think is up to you. Slide 26 Sean Turner asking questions from chair. Do you want to participate in this. Most room indicates assent. Adam Roach: Does questions capture. This is probably not literal text for the document. Andrew Allen: Various input material that does not seem to have been discussed. Also process issue in that new proposal is on table at short notice. Chair: If new technical input then please come to mic and discuss them. Bernard Aboba: Draws attention to litigation document and changes to MTI document. Particular interest is the type 3 declarations in ISO. These are things that require time. Situation may be clearer as time goes on but based on things that cannot be clarified here. H.264 has also proliferated since last discussion. Both hardware and software implementations. Situations where H.264 coverage does not exist has shrunk dramatically since last discussion. MTI issue if left alone will be solved by the industry and the IETF does not need to make a decision. Some products cannot afford to have multiple codecs because of space and energy consumption issues and therefore will ignore IETF decision. At moment H.264 is pretty far ahead at the moment on energy consumption issues. Chair statement: Any decision will be taken to list and therefore anyone not in the room will get chance to input to discussion. Andrew Allen: +1 to what Bernard is saying. Mobile industry will make the decision for us. Thinks that we only have this discussion because one browser vendor is insisting on having their codec. His company implements their own browser because VP8 still has too many risks of litigation. If make no decision H.264 becomes the default MTI codec. Adam Roach: Hallmark of a good compromise is that no one is happy. As regards new information about existing codecs, do not think it is relevant right now. Does not really change things. Mary Barnes for Randall Jesup via Jabber: Mobile devices H.264 implementations frequently (usually even) will not work for interactive video communication. Maybe they'll get there reliably, but even decode has been a huge problem on Android and Windows for Mozilla. and we have a huge number of desktop platforms that won't support it in the OS for quite some time. Something like 20% of Mac Firefox users are on 10.6.... and lots still in XP (yes, really) Ted Hardie from mic: Also LS from W3C on wanting royalty free. Also VP8 is developing at same time as H.264. Believes this compromise entirely in this spirit. ??? (Microsoft): Codec argument is technical decision by each device and browser vendor. Justin Uberti: Disagrees with Bernard’s comment that mobile is the future. Samsung, Qualcomm ... are shiping VP8 encode and decode in their hardware. Mo Zanaty: Hardware support is coming. Been difficult for real time support in past, but that is now disappearing. No one has yet mentioned the end users. Proposal guarantees interoperability for the end users so it is a win for them. Bernard Aboba: APIs in Windows and iOS both give hardware support and this is important for the mobile community. Every new mobile application is using the RTCWEB stack and compiling it into their application. Generally using another version of their own app for another usage. Webapps are the place where this does matter but [these are not the major issue]. Coverage of H.264 is most universal now. Andrew Allen: Presence of VP8 on many chipsets is evidence that we do not need to make a decision now. Chair: Do you agree with WG previous consensus to have an MTI codec. Andrew Allen: Previous decision was to have a single MTI codec. That is not what is on the table today. Eric Rescorla: Long standing consensus to have an MTI codec. Having two instead of one is well within the remit of the WG and consistent with that. Surprised that there is a space issue for packing two codecs into the same platform. Compared to browser size is not a material issue. Greg Mansell: Open source was an initial aim. World of open source is far wider than user agents and devices. Compatibility is also important. Proposal is good for vast majority of open source as well. Harald Alvestrand: The GSMA report was mentioned. Met guy who wrote report at W3C meeting, and asked questions about some of the values included. Could not get an answer to the questions. Justin Uberti: responding to Bernard. Samsung Chromebook no 1 selling laptop using Samsung SSC. ??? using Qualcomm. etc. VP8 prevalent across mobile ecosystem. Adam Roach: Responding to Bernard. Many trade shows people get up and describe lack of MTI codec as an important issue that needs to be resolved. Jonathan Rosenberg: Will unlock the ability for all those different apps to now have a webapp and bring real time communications to the web. Largest burden is on the browsers. Chuck ???: Want to see point 2 changed to be if royalties go up or down. Cullen Jennings: Wants to address question of whether there has been enough time or not. Six months ago made very clear discussion would be revisited here. Mary Barnes channelling Randall Jesup: To mo's comment, and Bernard: I agree HW support *can* and does work. And I hope we get to where all shipping (and most deployed) devices have reliable realtime HW codec support. That isn't today. That isn't next year. maybe in the years after that. All of that said... While I personally prefer VP8 as a sole choice, I can stomach the novel compromise. To Andrew's comment: I think decode both, encode one is as good as encode/decode both, IF and only if you demand all devices decode both, which may require more from devices than this proposal does. I do want to move forward and end this. We did discuss that idea before, I even was positive about it, but it didn't get much support. Monty Montgomery: Has clarifying question. After three years now have proposal for compromise and that another last minute proposal is not being discussed today. Is it impossible to consider other proposals in the future if IETF changes its minds. Krasimir Kolarov (Apple): Been following discussion. At this point technology that has type 3 declaration will not be shipped by Apple. Bernard Aboba: Clarified that type 3 declaration is by Nokia which is not the company that Microsoft acquired. Thinks "Must implement both" is too much of a burden. Xavier Marjou (Orange): Happy that some people will implement both codecs. Not happy that number 3 has disappeared from the list. Adam Roach: Number 3 is still in the list, just combined in. Mo Zanaty: Surprised that Microsoft does not have license. There will always be vendors who does not comply. Is this enough support to ensure this is useful. There are strong reasons to have 2) as well as 1). Andrew Allen: Not just a few small companies, Microsoft and Apple are a major part of the desktop market, Companies being forced to implement VP8 because one company is refusing to agree H.264 as mandatory to implement codec. Harald Alvestrand: One point about type 3 declaration from Nokia. Several months after Nokia claimed to have submitted still has not shown up at ISO MPEG. Does not name the patents. Stephan Wenger: ISO currently undergoing technical revamp of their database and that project hit certain roadblocks. ISO policy is that patent numbers are not required. Harald: Nokia filed two on same day. One made it, the other did not. Nokia behaviour is highly unusual and personally objectionable to me. Must clearly state what we have seen and not what we think we have seen. Mary Barnes channelling Peter St. Andre: I can't agree with JDR that web apps will proliferate once we solve this issue - the main blocker is that we don't have WebRTC support in IE or Safari, and Firefox is far enough behind in their implementation (no knock on the Mozilla team) that it is difficult to make interoperable applications right now Mary Barnes channelling Randall Jesup: Andrew's colleague's proposal was in the list of options we all surveyed many months ago. It did poorly. Dan York: Been going on long time with discussion. Agree with Peter's point that people are going out there and implementing. Need to have this decided. Justin Uberti: Unsympathetic to desire to have more discussion. Krasimir Kolarov (Apple): ISO database very slow to respond. Eric Rescorla: To be clear there are no protocol policy and if don't do this then just become one of the other terms. Having a terrible time understanding outside browser manufacturers as who is being inconvenienced. Andrew Allen: Referred to 3GPP IMS Webrtc work, and have to make statements of compliance to these. Mobile vendors could be forced to make a statement of compliance and if cannot ship product to sales channel. Matters to some companies. Monty Montgomery: Helps the vast majority of open source even if it leaves things difficult for some web browsers. Jeremy Fuller: If words of 2) do not trigger in next 24 months then will become irrelevant. Is anything likely to happen in this respect. Cullen Jennings: Thinks there are things that reduce uncertainty. Google considering invalidating IPR. W3C asked MPEG-LA asking to make H.264 royalty free. Ted Hardie: Important for us to make our best shot at making this as broad as possible. Bernard Aboba: Kind of like the slide but thinks that IETF proposal is a bit of a grand gesture that will not have any immediate effect. Will Google offer indemnity for VP8 law suits. Chair (Sean Turner): Question: Who does not want to take a sense of the room on whether to have the compromise text in the document today. No hums in room. In Jabber room one hummed. Chair: Lets take a sense of the room on whether we should add the text to the document. Hum now if you want to shove the text in the document. Most hums Hum now if you don't want to shove the text in the document. Fewer hums. Chair declared rough consensus to having text in the document - will be confirmed on the list. All other Business (matters returning from session 1, IESG resolution, etc.) ----------------------------------------------------------------------------- Chairs did not discuss any additional business --------------------------------------------------------------------------------------------------------------- WebRTC Thursday PM Minutes by Brian Rosen FEC - Justin Bernard: Doc okay, RED recommendation suspect Justin: don't mind dropping Martin: Less is good Chairs: Anyone object to adopting uberti-rtcweb-fec? Chairs: Will take to list to confirm draft-ietf-rtcweb-video - Adam Adam: 2 folks said "solve elsewhere" Orientation Indication Justin: SHOULD interpret, MUST send Jonathan: not sending means right side up, so MUST interpret, MUST be sent if not right side up Justin: Someone won’t implement. Harald: Add ref to header exten doc Adam: Is there an RFC to reference? Harald: If not an SAI message, must ??Moz: IANA registry for it Stephen: Is header extension generally required? I think yes Justin: make ?? a MUST is now a SHOULD Chairs: Send message to list H.264 SEI Do we need mandatory support Bernard: Take to list, but I think yes Adam: Need help with the list Bernard: Me and some others will help Adam: and Stephen MTI Codec - Adam Keith: At some point, patents expire, then what Adam: In 2026, someone else's problem Andrew: what is the process? Adam: wording to be negotiated Andrew: Need to avoid coming back Also worried about wording of licensing terms Stephen: Does a WG have the authority to bind the IETF to a future decision Chairs: Has happened before (RSA patents for example). Really a prompt for reconsideration rather than an actual commitment to do something Keith: When we discussed audio, how to use codecs and what the MTI codec was were in separate docs. May need same here. Also, no way out of this - if everyone is implementing H.269, don't want the H.264 vs VP8 at that time ?Shun?(microsoft)Has this been communicated to ISO? Chairs: No, this is just a trigger, ISO would not decide anything ?Shun?: Is the intention to make an MTI decision before standardization Chairs: We're talking about specific RFCs and other docs, not including ISO standardization Andrew: Is it the decoder or the whole thing that has to be royalty free? Adam: My position is no Stephen: Remind you that in video codec standardization, the only thing standardized on the bitstream and the decoder. Encoder stuff is encumbered differently Jeremy: As the 2nd condition is time related, do we have a minimum time in mind? Chairs: nothing that declares minimum yet Harald: Licensing terms for at least one of them cover both decoder and encoder, but up tp you and your lawyer if they are sufficient ?Apple guy?: Have you considered encode both, decode one? Chairs: Has been considered, not agreed to ??: Triggering condition re:browsers do we want to preclude something new that is wonderful. Adam: Has been discussed. By requiring browsers to always do both, we have interop with a wide variety of smaller devices Jonathan Harald Andrew: Are the goals achievable? Is it even doable, given a type 3 declaration? Will Google implement? Harald: Yes, we will, not sure when. Google is working from an assumption that VP8 is royalty free but may take time and lawyers to prove that Sean Turner (as sole remaining chair) Please stand if you will participate in the process Chair: Are there any new technical issues? Adam (from floor): Not literal words on the Novel Plan on the screen Chair: It's the trigger that needs the wordsmithing Andrew: Some mail list discussion issues, and liaison statement from GSMA, we ought to consider and discuss. Have a process question, some list discussion indicating it would not to be decided. Not the way to do it. Bernard: Are we opening the discussion now? Chair: Yes Bernard: Litigation on VP8, and licensing H.264 stuff. Just because we put it in a standard doesn't mean it will be implemented. The type 3 declaration is problematic for many companies. Requires time, situation may become clearer as ISO standardization continues. H.264 MTI doc says H.264 implementation has proliferated. Very wide H.264 deployment. Mobile devices are all H.264. So, industry will solve this. IETF doesn't need to solve this. Too much dead weight on this compromise. Small devices will only implement one. At least several browser vendors will not commit to this in any near time frame. The legal and business issues will still dominate Chair: Decision will be taken to the list Andrew: But we're discussing this now, smaller group than last time. Lots of +1 to Bernard. Mobile devices will do H.264. One browser vendor insisting on VP8, and the open source folks, but they can't implement (RF). We can't afford to implement VP8 with the current legal situation. We don't need to decide, H.264 will be the MTI codec. Adam: Thank Andrew and Bernard to note the hallmark of a good compromise is no one is happy. Don't think the H.264 MTI doc doesn't change the situation. Randal Jessup: Mobile H.264 is problematic. Ted: Liason statement from GSMA is nice, but we also have a liason from W3C that had a different view. Lots of chipsets doing both. Always expected multiple codecs, but need MTI to avoid negotiation failure. Need to make decision. ??Shun: Business and technical decision by vendors. Two codecs compromises us. Justin: Bernard says mobile is the future, we agree, all SOCs are shipping with both codecs. Risk: Google, Amazon, Qualcomm, Samsung are shipping, and they think its okay Moe: Hardware support is changing, very possible to get apps to get great performance on mobile. No one talking about end users. This is not a compromise for them, it's a big win. Bernard: We mostly deploy in mobile apps, being deployed, choosing a codec. Hardware will help them, but they are being compatible with their servers, etc. Web apps are the place where this does matter. Who is having to implement what? What is the missing portion? Coverage of H.264 is universal. Andrew: the fact that hardware is available means we don't need to decide Chair: Working group consensus is to agree on an MTI Andrew: Consensus was to agree on a single MTI. Very recent proposal. Different proposal on the list. Should consider others. Collegue suggested only decoder is MTI both. Two weeks ago it looked like there was going to be no discussion here. This proposal has ony been discussed for one week. EKR: Long standing consensus for MTI codec. Having two is not as good as one, but having an MTI decision is good. This is the first proposal that has a chance to resolve this. If you have a proposal that has a chance of being accepted, we can discuss. Don't want to worry about people who decided not to come. Having both in the platform is not hard. VP8 is 50K. This makes a substantial impact on interoperability. CraigM: Open source was an argument. This is a compromise, but the world of open source is far wider. Compatibility is important. Proposal is ugly, but it's good for most open source folks Harald: GSMA report has some questionable numbers. Doc says transcode at gateways is painful. Yes it is. Justin: To make an Android device, VP8 support is required. Great story for VP8 on moble. Adam: Question Bernard on whether this decision is an issue. Think that there are many folks hesitating because of this issue. Jonathan: No one really knows what the app guys have. But what they all need is a web browser app. We will then unlock these apps to have a web app. Largest burden is on the browser, for sure. The Type 3 issue is a big one, ask MS to help with that Type 3 declaration. ??: Like to see the wording talk about royalties go up or down. Cullen: 3 year discussion. It has been clear we would discuss at this meaning. "Both" proposals have been discussed and gotten wide support before. ??: Hardware does work, but its not today. Monty: Could we revisit another proposal tomorrow? Chair: Always possible ??Apple??: Can't support a decision with a type 3 declaration Bernard: Nokia is not related to MS, they made the Type 3 declaration. ??: Number 3 (WebRTC compatible endpoints can implement any) needs to be on the question Moe: Understand some vendors won't be able to comply. This still good for enough of the WebRTC community. Good technical reasons to have more than one. Andrew: MS can't remove the T3 declaration even if they have a license. We're being forced by one vendor to include VP8. If open source folks can live with this, they can live with H.264. Harald: Type 3 declaration has not turned up. No patent mentioned Stephen: ISO has a technical revamp of their database and that has held up the notice. ISO does not require patents Harald: Nokia filed two, one made it one didn't. Other declarations filed after have come out. Peter: Main blocker is browsers DanY: We have discussed this every which way. Need to decide. Compromise is a true compromise. Justin: Unsympathetic to postponing discussion. Kasimer: Two databases ISO + IEC, IEC has the declaration EKR: There are no protocol police. If you have a standalone closed app, choice of codec is don't care Andrew: RFCs, who cares about them? 3GPP cares. Vendors wouldn't be able to comply. This proposal is less than a week old. Should have more time. CraigM: In no way is this attractive to open source, it's a compromise. Jeremy: This is all time sensitive. If its 2-3 years, we won't care. Cullen: There are things that could reduce uncertainty for both codecs relatively soon. Ted: This is a compromise to get interoperability. Important to the user to make interoperability as broad as possible Bernard: This is a grand gesture, but won't really change anything. To Justin, will Google offer indemnification. Chair - 5 minute break Who does not want to take a sense of the room to add the compromise text to the doc today Andrew: Is this a question of support for the proposal? Chair: No Keith: Is this do you want to decide today? Chair: Yes Andrew: Don't want to decide today Martin: Large room. Won't get levels right unless you ask two sided questions Chair: Who does not want to take a sense of the room to add the compromise text to the doc today? Chair: The next question is: Those in favor of adding the text in the doc today humm now Andrew: Don't want to decide today AD: Not a final decision, will take to the list. Suggest striking "today" EKR: If we humm for this, we confirm on the list, and then we change the doc, right? Chair: Humm now if you want to shove the text in the document