RTCWEB Minutes March 5, 2014 Chairs: Magnus Westerlund, Cullen Jennings, Ted Hardie Note takers: Dan Burnett, Matt Miller JSEP - Justin Uberti ------- Issue 1: MSID and direction interactions (Justin's slides say:) Two cases: 1. X offers video, Y wants to reject but add its own 2. video flowing in both directions, X wants to stop remote video Key is permanence of inactivity -- this is not a pause, but a termination that allows for the media stream resources (transports and candidate sets) to be recovered/collected and m-lines to be reused. Suggestion is to add new "a=msid-control: stop". In first case would be Y that includes, in second case would be X. Questions arose around name of this attribute (msid-control does not refer to local msid), effects on RTCP (none), semantic difference between restarting and newly creating a media stream, concerns with legacy behavior, question about whether this is really a W3C API issue Justin notes that actual proposal for msid-control attribute will come in MMUSIC but is being discussed here for completeness. Consensus call: * How many people understand the problem? (few hands) * How many to have MMUSIC solve this issue (some hums) * How many to not have MMUSIC solve this issue (none) Issue 2: ptime Cullen Jennings (CJ): We should put in a max ptime of whatever you are going to send. It will help with interoperability. I don't care if it's 60 or 3000, but you should put in the max ptime for whatever your browser supports. None of this applies to Opus. Martin Thomson (MT): I agree Justin Uberti (JU): This is what values should be used when sending audio. What you send should only be one of these 20, 30,or 60. Speaker: When we have a gateway, I don't want the requirement to srip out values. If the payload wants to specify something, let them. CJ: I want to receive anything, and FF and Chrome will. 0 is an invalid value. JL: The 20/30/60 should be in the codecs draft, not here. JU: So what I've heard is to send the browser's value for max ptime, and for ptime send one of the 20/30/60 frame sizes. CJ: The max is the critical thing there. I think we should be able to receive anything, but what the browser chooses to send is one of the three values. JL: It's not known what happens with ptime across BUNDLEs (but that is not for this group). MT: You probably want to say what ptime can be when it's Opus. It's mostly a case for PCMU, and what's the max in Opus (120). This means the m-line will indicate 120. It's the maximum-maximum. CJ: It's going to minimum-maximum of all the codecs. There are hardware-based codecs that only support 20 or 30. Speaker: Is this only for the MTI codecs, why haven't we analyzed all of the codecs? Chairs: I think we should start with the latest and try to include it. W3C: I think the codec question is a larger one. There is some discussion around HTML5..do you intend to liase over this? It would be good to be aligned. Chairs: That comment is outside the scope of this discussion. Speaker: I think we should deal with these things in payload. CJ: Let's say the payload said that the ptime is 20. This is about putting that in the SDP. maxptime is well defined, so we'd be violating various SDP. Tim P: Would these values be maleable between create and set? JU: It would depend on what the browser supports. TP: When we are adding things, we should think about how this go up in the app. Ronny: If the offer included both OPUS and PCMU, then it took away PCMU, you could just check the max ptime. Consensus call: * Do you support including a maxptime? (moderate hums) * Do you not support including? (very few hums) Chairs: I think someone needs to write the codec draft proposal, and the ptime/maxptime proposal and take it to the list. Issue 3: CNAMEs Proposal around synchronization is to use the same CNAME for all MediaStreamTracks (MSTs), even though behavior of non-WebRTC endpoints will be implementation dependent. Some remember a different decision from IETF-88, that we agreed to use lip sync groups. Justin will conform with RTP usage guidelines and will look into lip sync groups. Martin expresses concern about using the same CNAME in different Peer Connections. Justin agrees the question about linkability across Peer Connections is a good one to consider here, and he will take it to the list. Outcome: More list discussion needed. Issue 4: Same-Port Bundle Policy Proposal is to add new bundle policy value (such as "force-bundle") to allow initial offer to use the same (non-zero) ports when support for BUNDLE is known a priori, allowing the sender to skip having to send a revised offer to clean up the ports after BUNDLE is accepted. Questions arose concerning what happens if the a priori knowledge is wrong, whether this is an IETF issue at all (as opposed to a W3C issue), Justin splits this into two questions: should we allow rtcpmux-only, and is it helpful to have API support to skip fixup offer On first question Justin will make a proposal on the list. For the second, chair hum in favor: only one. Against, a few more. Very little support for this. EKR brought up a question about candidate pooling and trickle ICE. Question is whether you can force no trickle ICE. Justin answers that candidates will arrive asynchronously anyway. Eric will look at implications for Firefox and maybe submit a proposal. How it works today Justin will send to the list. Consensus call: * Anyone see the need for the fixup offer optimization? (few hums) * No need? (more hums) RMCAT update ------- Bernard, Justin, Harald agreed to review RMCAT CC requirements. Security / Security Architecture ------- Eric proposes preferring (i.e., SHOULD) PFS cipher suites over non-PFS cipher suites. Asks whether this should be MUST. Belief is that MTI ciphers for WebRTC will include PFS options, so they will offer. Consensus call: * For WebRTC implementations, they MUST offer/select PFS over non-PFS? (large hums) * opposed (none) Identity changes slides (Martin) --- No comments on Issue 1. Issue 2: EKR says this needs guidance to apps on what to do with it. Either rendered in a separate window or be treated as a click from the perspective of a popup blocker. Issue 3: EKR says this can occur in browsers. Martin proposes we do option 3, including multiple fingerprints. He also proposes to make a=identity a session-level attribute and have it cover all the fingerprints in use. Chairs ask if anyone wants to speak against option 3. No one does. Issue 4: No one stood up to object to his proposal, but it went by really fast. Issue 5: Proposes being able to validate via HTTP POST on servers rather than requiring browser validation. There were questions, so Martin will send this pull request to the list for review there. Issue 6: Question is about how to preserve identity-based stream isolation beyond the local browser and the peer connection and into the receiving browser so that it remains isolated there. This is about protecting against the javascript running on both ends. A reasonable number of questions came up in discussion. We all agree this needs more discussion. CHAIRS: Consensus seems to be option #3 (assertion includes multiple fingerprints) RTP usage ------- Open issue about encrypting all RTP header extensions rather than just client-to-mixer and mixer-to-client audio level information as defined in RFC 6094. Colin's proposal is SHOULD. Cullen wants control at the Javascript level of the existing audio level headers and then might consider others. Harald wants an ability to control which headers are *not* encrypted. CHAIRS: If anyone wants to change the recommendation, do so in WGLC.