RTCWEB Meeting Minutes IETF 81, Quebec City, Quebec, Canada Chairs: Magnus Westerlund, Cullen Jennings, Ted Hardie Jabber: Jabber Logs Materials: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki Meetecho: http://www.ietf.org/meeting/81/remote-participation.html#Meetecho The original agenda is recorded below for reference, but the actual order was adjusted to deal with topic shifts brought up during the meeting: Agenda - Posted version Agenda Bash Status report (Chairs) - 10 min Liaison Report from W3C WebRTC -(WebRTC Chairs) - 10 min Implementation Experience - 20 min Use Cases ( 20 min Architecture and System Overview ( 20 min) Security ( 20 min ) NAT ( 20 min) Negotiation & signaling (25 min) Media (other than multiplexing) (20 min) Datagram transports (20 min) Multiplexing (30 min) Media processing & codec (20 min) Agenda Bash & Status Report (Chairs) - update milestones - adopted documents - planning interim meeting, late Sept/early Oct -- virtual or physical? Virtual agreed later in the meeting. Liaison Report from W3C WebRTC -(WebRTC Chairs) - much overlap with this meeting: architecture, use cases, implementations - extracting API requirements into W3C doc; four editors appointed - use-cases doc will stay in IETF; W3C will refer to it Implementation Experience (Tim, Cary, Harald, Stefan) - webrtc API in Chrome -- reference implementation -- key components released as open source code.webrtc.org -- API very unstable now - Mozilla implementation -- new audio backend for low-latency output (FFx 8 or 9) -- MediaStream API for splitting, mixing, sync -- webrtc based on Google GIPS, target to FFx add-on - Cisco implementation -- browser-to-browser and browser-to-phone voice & video calling -- Cisco SIP stack in Chromium and Firefox - Ericsson implementation -- WhatWG APIs Use Cases (Stefan) - same as from Saturday's webrtc meeting * use-case document should be informational * additional use cases should be proposed on the list * use cases need to drive new requirements * use cases that drive non-audio/video requirements needed comment: alternative use cases are useful; not everyone connects with existing cases comment: health use cases add privacy/security requirements; should include comment: lawful intercept needs to be covered Architecture and System Overview (Harald) - 20 min draft-ietf-rtcweb-overview - Goal: enable realtime communication between browsers -- no plug-ins, no relays required (but possible), 100ms timescale, audio/video/etc -- drive design by use cases: "at least this should be possible," but general functions - Layered architecture - Security: assume each component can be evil; keep trust to a minimum; UI issues important - Reuse: congestion mgmt, RTP, etc - Prefer to get out in the field, rather than over-research * Document status (Info vs Stds Track) will be determined later Security (Eric) - - User consent needed for access to mic/camera - HTTPS should be enforced by sites comment: making requirements on sites is out of scope comment: this is part of the threat model that needs to be addressed; security considerations - User consent: most likely needs to happen in advance; but this is difficult/scary comment: establish a baseline of what current systems do, and take requirements from there comment: there is a use case for in-flow one-time access - When calling service is the attacker... -- Secure endpoint-to-endpoint -- Harder to address during-call attack -- Defend against MitM attacks - Need to support RTP for interop - Choice: limited interop vs security all the time comment: browser must support RTP; value in ICE+RTP comment: deployments exist where they *don't want* encryption comment: could have UI requirement to alert if insecure [Between the WG meetings there was a side meeting ton the different proposals for RTP multiplexing. It was not an official meeting and no decisions were taken except as proposals to bring to the working group] Thursday: RTP Multiplexing (Jonathan Rosenberg) Reviewed the set of slides uploaded mid-week. -Defines the problem -Proposes to use SSRC for demux -Reviews implications, some of which will require significant additional work. Payload types problematic; paramters tied the m line may have signficant changes in expectations. Media negotiation (Cullen Jennings) --Basic issue is how close the negotation model here follows that within SIP contexts: Could be direct adoption, mapping, or different model. --Backward compatibility one primary issue --Gateway complexity will be an issue. --”Those who do not SIP are condemned to repeat it”.(Richard Barnes) --Review of high, mid, and low path proposals. --Continued discussion of whether SDP’s multicast heritage is interfering with Web-based communication actual semantics. Media other than multiplexing (Colin) --RTP features and optimizations --Review of set of extensions, eg. conferencing extensions --Comments that TMMBR would be valuable for point to point as well conferencing. --Rate control discussion RTC-web NAT traversal (Cary) --Comments on DTLS-SRTP usage in this context --Issues with non-media data --Bandwidth allocation issues --Fundamentally ICE-focused discussion Layered Codecs (Stephan) --Error resilience --Video Error resilience --Comments that we’re discussing solutions prior to requirements --Comment that a fast feedback channel may allow for p-frame reference recovery.