RTCWEB Interim meeting March 10, 2016 Chairs: Cullen Jennings, Ted Hardie (regrets from Sean Turner) Attendees: Cullen Jennings Dan Romascanu Justin Uberti Taylor Brandsetter Peter Bernard Aboba Alex Gouaillard Magnus Westerlund Harald Alvestrand Ben Campbell Adam Roach Alan Johnston Randell Jesup Maire Reavy Roman Shpount Victor Pascual Ted Hardie Agenda: Review draft-ietf-rtcweb-jsep-13 and discuss changes (see changelog in Appendix A and github issues list). Action item: land PRs 215 and 219, emit new draft, and send message to the working highlighting changes. The transceiver issues are the largest pole left in the tent. Prior to starting the main JSEP discussion, the group clarified which SDP lines can be ignored: effort to identify which SDP lines have no meaning in this context (e.g. time of session start). Text on the list to follow. Raw notes: (Cullen presented JSEP in his role as a co-author) Clarified how to handle various received attributes (a= line elements). Magnus: the rtcp attribute must be ignored? Justin: remember that the same information is in the ICE information Cullen: also remember how this relates to the non-MUX (text in draft is o If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored. ) Magnus: it is not forbidden to support non-mux, but making this MUST ignore makes Roman: it’s completely redundant Magnus: that might be true, but it is coming across as forbidden Justin: intent is to say that you don’t need this, because ICE handles it. We can say “ignored” here because the information is somewhere else. It does not say “Must ignore”, but is ignored. Magnus: maybe clarifying that is enough. Cullen: maybe what we should say is “is not used” not MUST be ignored. Roman: splitting it into two sentence would be clearer about where the MUST is applied. Justin: I’ll file an issue now to make this part clearer. Magnus: Thank you. Cullen: Any other issue for that attribute line? Justin: I forgot to mention in the change log, is that we nailed down how the bandwidth is handled; we’ve talked about it at multiple meetings, but the document now has this nailed down. Nothing should be a surprise, as it reflects the meeting. Revised how attributes should be generated for bundled m= lines (No questions) Removed unused references (No questions) Remove text advocating use of unilateral PTs. Justin: This was a long standing issue, that came up in implementation. It was a pain to match up the PTs in the APT attribute. Magnus has given some guidance on giving RTP payload types; so we ended up removing this and being silent on this topic Trigger an ICE restart even if the ICE candidate policy is being made more strict. (No questions) Remove the 'public' ICE candidate policy. Cullen: as we started the IP handling draft, this policy statement was less and less salient, so it got removed. Move open issues/TODOs into GitHub issues (no longer in the draft, but still open issues that need PRs). Cullen: Text needed from the authors/contributors. If there is a chunk of work that needs to be done, we should have it in the issue tracker now. Split local/remote description accessors into current/pending. Cullen: This doesn’t really change how things work very much, but it is a bunch of text edits to make this clear. Clarify a=imageattr handling. Cullen There are some codecs that have specific of doing this, but this is a generic method, and we clarified how it should work. Add more detail on VoiceActivityDetection handling. Reference draft-shieh-rtcweb-ip-handling. Cullen: This is now a working group document, and it should be re-issued as such. Make it clear when an ICE restart should occur. Resolve reference TODOs. Remove MSID semantics. Peter has an almost complete PR for this, incorporating the RID and Simulcast work; this is layered on top of the transceiver work, so that PR has to land first. This will be done before the draft deadline for IETF 95 (PR 215 first, then 219 next) o ice-options are now at session level. (No questions) o Default RTCP mux policy is now 'require'. Cullen: this reflects the discussion and agreements on this. Are there new issues that were raised? Justin: What SDP you use to re-start a DTLS session; that’s currently being discussed in MMUSIC? Cullen: As we shifted this, it wasn’t clear that the language left in the full control surface in RTPSender (issue 206 is tracking this) Justin: Issue number 230: what’s the value for setup in a reoffer. The guidance we’ve given is that you should always using ack? path or with what you’re already using Roman: The issue might be that with 3rd party call control, you might be talking to a different effort Justin: we have in that past said that we use a subset when doing re-offer (e.g. just what was being used before) Roman: maybe just clarify how this works in 3rd party call control, saying that it only needs to be used in initial offer or 3rd party call control; in all others, re-use what was being used before. We can do that in the DTLS draft Justin: if you’re going to do that in the DTLS draft, we can just point to that. Cullen: which draft Roman: mmusic-dtls-sdp Justin: this biggest thing is when we get the transceiver landed, then the rid/simulcast stuff. Those will be landed early next week and we’ll emit a new draft Harald: and the other two PRs? One is waiting on the transceiver stuff to land, and 136 needs to be re-cast (adjusted title during the meeting).