Minutes for RTCWEB IETF 84 Ted Hardie, Cullen Jennings, Magnus Westerlund Chairs Agenda: http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb Presentations: https://datatracker.ietf.org/meeting/84/materials.html#RTCWEB Jabber logs: http://www.ietf.org/jabber/logs/rtcweb/ Recordings: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_RTCWEB_I http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_RTCWEB_2 Note takers: Christer Holmberg, Brian Rosen Day 1: Topic: Codec control Presenter: Magnus Westerlund Related draft: draft-westerlund-avtext-codec-operation-point-00 Nutshell: use SDP to negotiate upper boundaries (bandwidth etc) for media, and then use media plane signaling, using the COP (draft-westerlund-avtext-codec-operation-point-00) protocol. Operations are done per SSRC. Presenter: Harald Alvestrand Related draft: draft-alvestrand-rtcweb-resolution Nutshell: A solution based on the RFC 6236 (SDP “imageattr” attribute) and draft-lennox-mmusic-sdp-source-selection specifications. The scope of the solution is more narrow than COP, and only talks about video resolution. The chairs asked how many have read the drafts, and whether people understand the difference in the proposed mechanisms. It was concluded that enough people have read the drafts, and understand the difference, in order to perform a straw poll on which way to move forward. POLL: 1. Base further work on Magnus’s proposal (COP): 6,5 2. Base further work on Harald’s proposal (SDP “imageattr” attribute): 26,5 Outcome: Clear support for Harald’s proposal. After the poll, the chairs indicated that they will discuss with the area directors about where the mechanism work would take place, as it might be done in another WG then RTCWEB. Topic: Mandatory to implement audio codec selection Presenter: Tim Terriberry Related draft: draft-cbran-rtcweb-codec Nutshell: Make a decision, using a set of criteria, about MTI (Mandatory To Implement) audio codec(s). There will be no recommendations of other codecs, neither will people be requested to not implement certain codecs. The presenter listed the criteria used in the codec evaluation by the CODEC working group, then presented his evaluation of the codecs against the criteria. He then proposed both Opus and G.711 codecs as MTI for RTCWEB. It was claimed that Opus handles all use-cases, while G.711 handles basic legacy interoperability. It was questioned why two codecs are picked, as only one would be needed to achieve interoperability. It was indicated that we need a mandatory codec, or a set of mandatory codecs, to achieve interoperability in all cases. It was indicated that a legacy gateway, eventhough seen as an RTCWEB endpoint from a browser perspective, might not implement the Opus codec. It was indicated that, eventhough something is mandatory to implement, it is not mandatory to use, if not needed for certain use-cases, or in certain entities. POLL: 1. Opus & G.711 "Entire room, except the 5 that wants Opus only" 2. Opus: 5 3. G.711 only: 0 Outcome: Move forward with Opus and G.711 as MTI (mandatory-to-implement) audio codecs. ----- Topic: Video codec info Presenter: Cullen Jennings Related draft: draft-cbran-rtcweb-codec Nutshell: Rather than trying to select a MTI video codec, a suggested way forward in order to reach a point where such selection can be done. The assumption was that the candidate codecs are VP8 and H.264, and that there is consensus that we need to choose a MTI video codec. The presenter suggested different topics and areas, for which we should get information, and asked whether people know how we can get such information, and whether there are volunteers to provide such information. After the presentation, people were asked to send information to the mailing list by October 15th, to indicate what type of information they think is needed in order to select a video codec. The plan is to try to reach consensus on a MTI video codec at the IETF 85 meeting. If that fails, an alternative process might be needed. The plan is to, before the IETF 85 meeting, try to reach consensus on what alternative process should be used, if needed. ----- Topic: Consent freshness Presenter: Dan Wing Related draft: draft-muthu-behave-consent-freshness Nutshell: Avoid DoS by using regular authenticated consent requests, using STUN, to refresh permission to continue sending traffic. Traffic sender requests consent of the receiver. It was indicated that consensus had been reached on a number of the topics at the RTCWEB interim meeting in Stockholm, and that the latest version of the associated draft should reflect the agreements. It was indicated that ICE lite endpoints, and legacy full ICE endpoints, will not send the consent freshness messages, and that it should be clarified in the document. It was indicated that we need a more clear definition, and security implications, of “consent”. Day 2 Topic: QoS Marking Presenter: Cullen Jennings Related draft: draft-jennings-rtcweb-qos Nutshell: The draft suggests RFC4594 marking with API requests for relative priorities of media, as well as a way to find out what markings were used; discussion of how it should be set. Magnus and Ted as chairs asked for indications of interest, which seemed to be generally positive. The chairs will discuss whether to pursue as an individual for now or not, but eventual adoption seems likely. Topic: Usages and constraints Presenter: Marcus Isomaki Related draft: draft-isomaki-rtcweb-mobile Nutshell: The presenter went through how wireless networks behave in the presence of keepalives, and the impact on UDP times. These should inform some of the design decisions being made by the group, but there were no specific action items. The author will continue to keep this up-to-date as an informational document. Topic: Usages and constraints Presenter: Bernard Aboba Related draft: draft-aboba-rtcweb-ecrit Nutshell: The presenter discussed the requirements which fall on RTCWEB apps which choose to or which will be required to support emergency calls. The chairs request that feedback on this go to the authors, but noted that it does not seem appropriate to adopt as a working group draft in RTCWEB. Topic: Firewall traversal: Presenter: Tiru Reddy Related draft: draft-reddy-rtcweb-stun-auth-fw-traversal Nutshell: The group discussed how the token is obtained and why a more general solution wouldn’t work better. Cullen suggested that enterprises sometimes allow TCP but not UDP, so that may be an avenue worth pursuing. The chairs agreed that this seems to be interesting, but not appropriate for RTCWEB to be the locus of work. Gonzalo will work with other ADs and will advise. Topic: Security architecrture: Presenter: Eric Rescorla Related draft: draft-ietf-rtcweb-security-arch Nutshell: Much of the discussion focused on consent and liveness checks and whether or not these could be combined. Additional work was suggested on shortening STUN timers, and the ADs agree to help connect these proposals to other work. Topic: RTP usage Presenter: Colin Perkins Related draft: draft-ietf-rtcweb-rtp-usage Nutshell: The group agreed to moving the RTP topologies work to a separate draft, as well as moving the work in Section 12 (implementation considerations) to a separate draft. The authors will update the draft with the selected MTI audio codecs once confirmed on the list. The group needs to drive use cases relevant for RTCP XR before support for them will be required.