AVTCORE WG ========== Note Taker: Marc Petit-Huguenin Chairs: Roni Even Magnus Westerlund Chairs Slide: ------------- Roni Even Magnus Westerlund https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-0.pdf Colin Perkins noted regarding draft-ietf-avtcore-rtp-multi-stream-optimisation that it may require update for the format of the Reporting group ID. The reason is that it is unnecessary verbose, as it will be included in regular reports. The RMTCAT WG's work on congestion control feedback has unearthed this issue. A Proposal for the change needs to be sent to the WG mailing list and should achieve consensus before decision is made to pull the document from the RFC-editor queue. ACTION ITEM: Send proposals to the mailing list before pulling it. Roni Even informed that for draft-ietf-avtcore-aria-srtp the writeup was updated before the meeting. draft-ietf-avtcore-aria-sdes ready for last call. Ben Campbell asked if the shepherd want to synchronize these? Roni responded that it is not needed. ACTION ITEM: Magnus to update draft-ietf-avtcore-multiplex-guidelines Multi-Parth RTP --------------- Varun Singh https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-6.pdf Taxonomy has been updated. ACTION ITEM: New taxonomy needs reviews, especially from the taxonomy authors. ACTION ITEM: The draft needs some more reviews. ACTION ITEM: People could think about possible solutions about the interface advertisement in RTCP. Emil Ivov commented that the WG should revise its timeline for publishing this. The reason is that multipath path establishmenthas has not yet seen any work in ICE WG. The solution should not perform interface advertisments in RTCP. It's not only about about interfaces, it's also about candidate pairs. Varun stated We can do it in RTCP until there is a point where people know how to do it. If people find a better to do it, we'll just update the draft. Bernard Adoba commented that we do all these things in ICE to allow passive/aggressive nomination. We need to think carefully what happen when these paths shift. Varun responded the congestion control has the responsibility to figure out bottleneck. So perhaps it is the congestion control responsibility to choose to use them or not. Cullen Jennings responded that the document should be published as it is stand-alone. Peter Thatcher commented that Multipath ICE is not really (?) yet. Several in the room supported it going forward as it targets experimental status. Magnus Westerlund to send text on security text on the issues of potential two time pad. Packets are sent on different paths are different, even if duplication of payload and meta data. Need to check that the IV used on these packets are unique. ACTION ITEM: Security consideration is lacking. Magnus Westerlund to contribute. RFC5285bis ---------- Roni Even https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-1.pdf Jonathan Lennox commented that document need to be sure it is clear with the difference between SDES header extension which change occasionally, and things like timecode that are sent all the time. We need guidance on things that never change, change occasionally or that change all the time. Ronie responded that the question was more on how many times to send it to have reliability. Jonathan responded that if it changes all the time, the reliability considerations is not relevant. ACTION ITEM: Authors need clarify differene. Circuit Breaker --------------- Colin Perkins https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-2.pdf Bernard Aboba remarked that Varun Singh has raised WebRTC API (W3C) issue. What does the app developer need to know. Do you get an API, or can they restart it? Does this document need to make more clear recommendations. Cullen Jennings noted that the existing spec says that this is the browser must enforce, not the Javascript. Inventing a notification is for WebRTC WG (W3C). Needs clarification for WebRTC who is responsible to notice this. ACTION ITEM: Log a bug in WebRTC saying that we need an event when the circuit breaker blows. Bernard commented that he from a WebRTC application could make the circuit breaker triggering go away using a ICE Restart. Colin asked how this relates to this draft. The issue is that it is not clear. Colin pointed to the "should not be restarted unless..." text. Varun Singh remarked that it could be that audio and video are on the same transport and the circuit breaker kicks for the video and audio is still going. The app may want to look and see that the audio is fine and in the future the app may reenable the video. The notification is useful in that case. In the case that ICE goes away and circuit breaker triggers, you get two events, and the app can just ignore the second one. Colin responded that from the point of view of this draft, it does not matter. It matters for WebRTC. Jonathan Lennox commented that one thing that is clearly count as a path change, is when ICE restart has found a new working connectivy pair. Cullen Jennings responded that the current text is sufficient. Circuit breaker is working on stream level. So if you change interface you have a new 5-tuple the RTP Stream goes over. Thus different state. Martin Thomson noted that this discussion would be valuable to have explicit in the draft. Please ensure to check in the text. Peter Thatcher noted that with that rule, if after an ICE restart only the port changes, would that retrigger the circuit breaker? Colin noted what it says is that if you have a reasonable expectation that you are on a different path and different congestion conditions then you restart. We can't give precise guidance in each case. ACTION ITEM: Someone to suggest text Regarding the ECN issue. Jonathan Lennox noted that a future memo may possible never be published, ensure correct formulation. There was consensus in the room to go with the proposed text for the ECN issue. ACTION ITEM: Add the text. PAYLOAD WG ========== 19.7.2016 Note takers: Marc Petit-Huguenin, Magnus Westerlund Jabber relay: Jonathan Lennox Payload Status Update --------------------- Status of VP9 payload in draft-ietf-payload-vp9-02. Jonathan Lennox: The payload itself is done. The document need the offer/answer section and more explanatory text. Draft-ietf-payload-melpe – will start WGLC after the meeting – please review New WG document draft-ietf-payload-rtp-vc2hq need reviewers RTP Payload Format for Non-Interleaved and Interleaved Parity FEC ----------------------------------------------------------------- Varun Singh draft-ietf-payload-flexible-fec-scheme-02 There is an IPR statement ACTION ITEM: Send comments about CISCO IPR declaration, if any, to the list. Some comments about the IPR: Jonathan Lennox(JL): It is easy to use it in a mode that does not protect multiple source. Varun Singh(VS): If you remove that feature, yes. Bernard Adoba (BA): It is not even clear how this can be used. VS: No, because there is multiple SSRC in the packet. Payload header Varun Singh: There are bits that can be removed, for rtx the SSRC count is 1 and can be redundant if the R-bit is 1 (retransmission) which provides even lower number of bytes in the payload header see slides 4 and 5 in the presentation (slides-96-avtcore-4.pdf) Mo Zanaty(MZ): We can eliminate length recovery too. BA: It is desirable to have retransmission as well, but to do that you really have to kill RTX. VS: If we want to save more bits we should do a different format. JL: I would push back on moving the TS recovery field. VS: Probably need to redefine it MZ: Exactly what Jonathan said. ACTION ITEM: Send to the list ACTION ITEM: Check the decision about reed-solomon/raptor in Yokohama. Chair comment for minutes: reviewed the meeting notes could not see any text about the topic After discussion: ACTION ITEM: Separate media registration ACTION ITEM: reed-solomon/raptor on separate drafts. JL: Do we know if we are doing FEC before or after SRTP? VS: FEC on unencrypted media. RTP Payload Format for HTTP Adaptive Streaming ---------------------------------------------- presented by Rachel Huang, see draft-wei-payload-has-over-rtp-00.txt Varun Singh: I am not sure why there would be an issue with congestion control. About fragmentation the only thing I could suggest is using smaller chunks. For the manifests, the decision should be made by the existing technology. Roni Even: For the manifests it is about how to provide the information for the multicast groups. Magnus Westerlund: What is really missing the URI format. Colin Perkins: I thought what was proposed was simpler. Do you really need the manifest files? The answer is no. Use the SDP. VS: The thing that could be done is the fragmentation of the packets, the other things are out of scope. ACTION ITEM: Continue this discussion.