IETF 88 RTCWEB Working Group Chairs: Cullen Jennings, Magnus Westerlund, Ted Hardie Day 1: November 4 2013, 14h50-17h20 Scribes: Ralph Giles, Eric McMurry Audio recording 2: http://www.ietf.org/audio/ietf88/ietf88-regencyc-20131107-1300-pm3.mp3 Meetecho : http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB Agenda Chairs JSEP (15m) Data channel Security RTP NB: Day one’s minutes record the summaries in-line, due to the larger number of issues raised; day two’s minutes record a single summary, followed by a record of the discussion. Chair Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-3.pdf The chairs presented the Note Well, the agenda for this and the next session. The milestones were quickly reviewed, primarily noting that we are late with everything. The WG was asked if they think it is a reasonable goal to finish all the core documents before the end of 2014. This will be a challenge and people need to help by actually reviewing the documents and send comments. The dependencies was also reviewed. Authors, consider if our normative references make sense. Are they really needed? Waiting on references slows down publication. WG please contribute to finish up these references also. The WG was also warned that we soon might have to make choice if our specifications can contain a specific feature and if it is really required. Improvements and optimizations might have to be pushed to a separate extension to the core specifications. === JSEP === Presenter: Justin Uberti Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-2.pdf Look at examples at least if you can do a minimal review of the draft. Mandatory-to-implement SDP features and things mandatory to use now documented. Q1: Re-offer handling --------------------- Proposal: Use a new peerconnection for full renegotiation, heavy-weight changes. MUST NOT re-offer e.g. codecs rejected by the other side. Don't make things harder for application developers by leaving this to implementators. Martin Thomson, this sounds reasonable, but like to get clarified if one MAY avoid re-offering or MUST NOT re-offer codecs that wasn't accepted. Justin stated that this is MUST level to get predictable results. Martin, commented that he understand the predictability, but don't see it as necessary. Christer Holmberg asked if you really meant the follow-up offer to be an delta, because that wouldn't work. Justin replied that this is a offer (not a delta) but only containing things the previous round of O/A indicated as supported and the specific things that has changed. Paul Kyzivat finds this proposal really disturbing. If one are really fine with the first rounds result, fine then no issue with doing as proposed. However, if one didn't get what one wanted, then one shall have the option asking for what one want in the hopes one gets it. Otherwise, I don't see how you every step up. Having to open a new PeerConnection appears silly. Justin asked, how does the application know that? Richar Ejzak, supports Paul's concern here, there need to be some mechanism to do more than was previously proposed. Justin replied that if there appears to be a need for something less than creating a new PeerConnection, then it should be considered. However, it appears less than clear how an application would know to use such a mechanism. Adam Roach, the issue is that to benefit from this one, one need to know that on reception of an offer. However, if talking to a non WebRTC device, then this assumption can't hold. Thus upon reception of a Offer one always have to process it in full. Justin replied, that there are two cases where senders benefits. First is HW codecs. Where you don't want to recommit them for a new offer. Adam replied, you don't have to. Justin commented that is back to the issue of predictability. Adam think the implementation should have discretion here. Justin followed up what the do you do with bundle. Adam's conclusion is that Codec is not a good entity for the list of things that must stay the same. Suhas, agrees with Adam, the last three in the list are system properties, but codecs are not. For example half way during the call a resource might have become free. Justin commented that he don't want to have undeterministic behavior and get a codec switch in the middle of a call. Suhas, don't see any harm in sticking with RFC 3264 behavior. EKR, asked for clarification from Justin if he thought it was undesirable to have the codec change during a session. Justin confirmed that he thinks it bad. EKR requested that people answers how they think the browser should behave rather than how SDP behaves. Jonathan Lennox think MUST NOT is strange. There are a lot of things that can be offered and have little effect, where one might go from not using them just now to add them later. Paul Kyzivat asked about bundle, is it not allowed to remove a stream from a bundle? Justin replied, no that is not possible in JSPE, thought that there was agreement to not unbundle things bundled. Paul, commented this is not really a question of the mapping to SDP, but rather a limitation to the API. That is a different question what is being raised here. - Conclusion: Complex matrix of options, difficult to judge the room. More discussion is needed. Think of more specifc proposals. Notetaker's summary of discussion: Some concern that there's no way to upgrade options. SDP could come from a non-webrtc endpoint, so we can't rely on the other side respecting this. MUST so applications behave uniformly. Available resources, like hardware codecs can change. Bundle less controversial, since it's constant for the implementation. Has specific language about initial and subsequent offers already. There's no way to tell the difference between unsupported and unsupported-right-now with this proposal. Q2: a=connection. ----------------- Should we add it? Is it useful to use connection=new to force DTLS renegotiation. - Conclusion: No, per existing specs. (no concensus call) Discussion summary: Makes sense of TCP, not the best interface for DTLS. Unless we can come up with a reason to swap roles mid-stream, don't mess with this. Just set it up and keep it up. MITM attacks are a use case! Q3: CNAMEs ---------- Is there a way to synchronize multiple MediaStreams from the W3C API so they can share a CNAME. - No proposal, just discussion. Discussion summary: Can we just map MediaStreams to CNAMEs? It should be the senders choice to use the same CNAME or different for two MediaStreams. There's no compelling reason to expose that to the application running on the browser on the other side. Shared CNAMEs don't _have_ to be synchronized at playback. Could use the absense of an attribute to indicate unsynced. Application could add a track to two different MediaStreams to indicate sync. This is a W3C problem, not an IETF problem. Q4: BUNDLE control ------------------ Try to bundle everything, add a BundleOnlyPolicy contraint to PeerConnection: all, none, or per-media type all audio bundled, all video bundled. Use per-media the default. Don't try to control things per-track. - Conclusion: General agreement from commenters. Discussion: Disagreement. Wrong forum? (withdrawn later) Bundle is strictly better, so this is good, and gives us the minimum set of controls. We can always add more later. Could be same-priority instead of same-media? This is reasonable if it just controls what legacy applications see. Q5: m= section recycling ------------------------ - Conclusion: Discussion directed to the list for reasons of time. = Chairs note: Security discussion moved to the end, with the understanding we may not have time for it. = Data Channels: Randell Jesup Remaining issues: DTLS Overhead: resolve by specifying IP Layer MTU? - Conclusion: (roughly) ask TSV working group to advance the ndata draft and try to get that solution implemented and spec'd in time for RFC. Discussion: What' is it specified to? PMTU up from some lower bound is easier to implement. max of all ciphersuite overheads, which changes with time, so we can't specify in advance. Doesn't max give you a number which could be too large? SCTP needs to know, but since it can change we shouldn't specify anything. Large message block other channels: tsv draft proposes to alleviate this In the meantime, support PPID-based fragmentation + length limit for unreliable, as discussed in drafts, implemented in Firefox How do we retire the PPID issue once SCTP interleaving works? SCTP implementaitons know what the other side supports, so it's negotiated, but you still have to implement forever? Could remove the fallback even before we finalize the draft, since implementations are ahead of the spec. Also easy to update a spec by just removing a section. Why not just do that now, and not doc the fallback or doc it as non-normative. Old, new, or both forever; which do we want? The ndata implementation is in an svn branch, needs testing before merge, so very close. Draft is still and individual submission. Expect it could be advanced if this WG asks TSV for it. Message size limitations: Propose a minimum supported maximum size of 100 MB Websocket has no spec limit, implementations pick one in practice. Maybe we should do that too? - Conclusion: write up the ack signaling as a new proposal. Discussion: What happens if you go over an implementation limit? In WebSockets, there's no way to stream things. This isn't any different Is there a way to query the limit? Get an error when it's exceeded? Not having that is bad. Imitating the mistakes of others is the best we could do. Let's make our own mistakes. We can't figure out what people want to use this for. It would be nice if there were a well known set of properties applications could assume so they would know e.g. when they need to do chunking. We've had enough discussion to decide whether we should have a deterministic limit. Could pass a limit in the handshake ack to the js api could handle it. Nagle algorithm usage: no longer an issue. Initial number of streams: Propose not to set the maximum number of streams to 64k streams. There's no complexity advantage. - Conclusion: Set it to maximum and be done with it. Hum: I approve of setting this to the maximum, vs. I still have an issue with this. Discussion: SDP shouldn't have to worry about these details. Like IP applications applications shouldn't have to preallocate ports. SCTP implementations all pre-allocate this state, so you need 128K per connection, and never use them. Rewriting them for lazy allocation or sparse array is "just" work. While protocol renegotiation will last forever. Servers are memory-limited devices, just like low-end mobile devices. Avoid encoding numbers on wire to save implementation complexity. Better to make implementations smarter. Out of Band Negotiation: Handling collisions between in-band and out-of-band negotiations. Discussion: Browser can detect and warn on these sorts of things. In the text just say it's wrong, and error. - IANA registration protocol question. Discuss on the list. = RTP issues: Colin Perkins Discussion: - Signalling the most number of ssrc values -- Not an issue This is the same as the number of m-lines. So we don't need to say anything. Confusion between max sources, max streams. Limits are based on resolution etc., not just the number of streams. Signalling RTP topologies -- - Should multiple cnames per session be mandated? Yes - Do we need to say anything about SDP signalling for gatewaying? No - Simulcast -- Maybe, but not in this forum. See AVTEXT. - Forwarding -- If you wish to forward media, treat the RTP as if you'd transcoded. Forwarding without transcoding sounds really complicated and we shouldn't worry about it. With transcoding already works in Chrome, it's just plumbing. We can do an RTP translator later if we decide it's important. Nutty to do a middlebox in the browser. Transcoding does add delay. We're talking about two different ways of implementing something that's already possible in the W3C api. The browser has a choice on how to do this, there are easy cases where it could switch behaviours as an implementation quality issue. - Differentiated services -- Make a draft outlining the issues; make no concrete recommendations. Work going on in other working groups on these issues. - Correlating Media Streams -- No, this isn't in jsep. It doesn't makes sense to put unified-plan in the RTP usage draft. Security: Eric Rescorla Hope to update the draft in Decemeber. On the screensharing issue, both Firefox and Chrome were planning to punt in the same way. End of session. Thursday November 7, 2013 13:00 to 15:00 Scribes: Alan Johnson and Alex Deacon Audio recording 1: http://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3 Meetecho : http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB Agenda: Video codec selection VP8 presentation H.264 presentation Microphone discussion of pros/cons Call the question Wrap up/Next steps Backup topic: draft-ietf-rtcweb-transports (Agenda item not reached) Summary: Presentation and questions were done for VP8 and H.264. VP8 presentation: http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-7.pdf H.264 presentation: http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-8.pptx Consensus call slides: http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-6.pptx The WG then tested for objections with following question. If you have a reason you cannot live with one of these codecs that has not already been discussed, can you explain it now? No new issues were raised. The room was then asked two consensus questions: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. You may raise your hand more than once and we encourage you to do so if you can live with either, even if you have a preference for one over the other. Richard Barnes called the consensus as a single "no consensus" Raw Notes For Day 2 Set One ------------------------------------------- VP8 Presentation Harald Alvestrand. - Google Presenting the same presentation as last time but with updates/modifications based on Cisco’s recent announcement. Issue is not about technology but who owns it but what we are allowed to do with it. We now know that the Baseline Profile has been proposed by proponents, but Harald states that payment terms are not yet known. H.264 Presentation Jonathan Rosenberg - Cisco Cisco open sourcing h.264 code under BSD license. Also providing code in a binary module for implementation and Cisco will pay MPEG-LA licensing costs. Use of binary module is NOT restricted to rtcweb. Source code will be available before end of year. Binary is not available until after Jan 1, 2014 Cisco hopes to make support for High Profile available in future. Asserts that IETF selection of VP8 as MTI in rtcweb increases risk that patent trolls will come knocking. Open Mic Harald A: Asked Cisco to publish the research on performance sited in the slides? ACTION: Cisco will. (Bo) Monty Montgomery: Question is about MTI codec. Suggests that Google do the same as Cisco for VP8. Justin Uberti: transcoding is cheap. Peter Thatcher: To early/not enough information to assess IP risk. MTI decisions stick with us for along time Randall Jessop: Disagrees that not having h.264 will cause rtcweb to not achieve critical mass in the market place. Jean-Marc B: Asked someone from Nokia to explain why IETF IPR site has declaration on VP8, but not H.264. (no answer) ?????: Beauty contest is over, need to make a decision. Its good that those that want to implement both can do so. This will go along way towards interop. Ralph Giles: States that Google has VP8 binaries already available on their web site. Martin Thompson: Cisco announcement is great news. Very programatic solution and that makes the choice easy. Adam Roach: Even though transcoding is cheap there is a huge usability cost. There is also a huge security cost in using a web based transcoding. Jonathan Rosenberg: License still valid even if h.264 is not made MTI. Debate does not just boil down to Nokia lawsuit and he again referenced the list of very pragmatic reasons in his presentation. Ted Hardie: (representing himself only) Cisco’s gift is appreciated, but rtcweb charter and requirements state the need/want to avoid proprietary plug in’s. Plugins are an encumbrance and paying license fee is also an encumbrance. H.264 is not the answer. Clarification that choosing H.264 doesn’t violate the charter but doesn’t meet the goal of the working group. Matt (google): Solution needs to work for big and little guys/companies. MTI i this case doesn’t implement but means mandatory to download a binary. Roberto: Implanting both exposes implementers to twice/double the IP risk. Any choice comes with unknown risks so we should choose neither. Gerald: Jon Peterson: Thinks argument to make H.264 MTI pretty compelling. Justin Uberti: Disputes anti-transcoding argument. Peter Thatcher: Transcoding was turned on for a large video system and no-one noticed. No MTI is better then H.264 as MTI - i.e. let the market decide. Rohan Mahy: Embedded platform support for both codec’s is most compelling arguments for this debate. Dean Willis: Would Google assert against H.264 as they are not a member of MPEG-LA? Feels no MTI is best solution. Jonathan Rosenberg: Clarifying that the user does not need to get plugin - its the browser on behalf of the user. We need to make the MTI decision as there are many more implementation other than the 4 browsers. Robin R: Feels H.264 prevalence guarantees that H.264 will be implemented anyway - Even if its not selected as MTI. Christopher Webber: (via jabber): FOSS is way more than just an interesting edge case. Randall Jessup: Need to think beyond browsers and think of server based apps. Gaelle Martin-Cocher (Blackberry): Bernard Aboba (Microsoft): Eric Rescorla (Mozilla): Only referencing main line firefox download version. 1) intend to support both codecs. 2) intend vp8 to be built in. 3) Intend to support h.264 via cisco binary on desktop. 4) On mobile - try to use HW codecs (Referenced some recent blog post from mozilla) UX is that this binary will be downloaded in the background - it will be hidden from the user. Harald A: Wants to see a future without encumbered codecs. Jean-Marc: Notes that he doesn’t see any indication that implementers sill change their code based on outcome of MTI hum. No MTI should be a hum option. ???? (Firs timer): Focus on the end users. Justin Ridge: 1) Risk - VP8 has not gone thru SDO process where there is an obligation to announce IPR. 2) Trust - Can you trust google lawyers? Is the spec complete? Tim T.: Brian Dixon: Are there any geo limitations for Cisco license? Cullen says no. Testing for (New) Objections None raised Consensus call 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 80-100 + 10 on Jabber 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 50-60 + 30 on jabber Can’t call this a consensus. Getting to a decision Will use the alternative consensus process using RFC3929. Propose the use of an external review team (Section 4.1) Raw Notes Set Two ------------------------------------------- Video Codec Selection Frame discussions, process, and agenda around MTI video codec (chairs) No agenda changes. VP8 presentation with clarify questions (Harald) - draft-alvestrand-rtcweb-vp8-02 No questions for Harald. H.264 presentation with clarify questions (Jonathan / Bo) - draft-burman-rtcweb-h264-proposal-03 Clarifying question on encode and decode chipset support. Clarifying question on real-time chipset support. Clarifying question on which profile was used in performance comparisons. Question about Nokia claims on VP8 and H.264. Microphone discussions of pro/cons - (all) Lots of comments. Call the question - (chairs) Some discussion about the hums. 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. Richard Barnes, Area Director: 50% H.264, 30% VP8, No consensus. Wrap up and next steps - (chairs) Chairs showed more slides. Alternative consensus approach proposed by chairs or remove milestone. Discussion about process at microphone in last few minutes.